1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

qmail - Not_allowed_to_perform_deliveries_as_root

Discussion in 'Plesk for Linux - 8.x and Older' started by brooks, Apr 5, 2006.

  1. brooks

    brooks Guest

    After the upgrade to 8 (CentOS 3.6) qmail won't deliver mail to any of the local (root, postmaster, etc.) aliases. The log shows:

    Apr 5 20:32:58 ds qmail: 1144294378.640047 starting delivery 48: msg 3342534 to local postmaster@host.domain.com
    Apr 5 20:32:58 ds qmail: 1144294378.640097 status: local 1/10 remote 0/20
    Apr 5 20:32:58 ds qmail: 1144294378.642317 delivery 48: deferral: Not_allowed_to_perform_deliveries_as_root./

    I started looking at a mail delivery problem with drweb, which by default is set to reject messages that cause a license exception. Drweb allows for 14 users (without a license upgrade) but if some of those 14 users have aliases attached to them it (in theory) causes the license violation which in turn causes a mesage to be generated to "postmaster". To fix that issue all you need to do is change the /etc/drweb/drweb_qmail.conf file from:

    LicenseLimit = reject


    LicenseLimit = pass

    One thing always seems to lead to another...

    I've see some other posts about drweb dropping mail but nothing specific about the above mentioned problem. Anyone else seeing similar issues?

    Although these forums are a good place to communicate they really lack the structure we need to catagorize and discuss the many issues we (unfortunately) see with a new release.
  2. threads

    threads Guest

    Did not see this one earlier ... If you try and search for the "Not_allowed....." string, this forum search does not find it!

    We seem to have the same issue on RedHat FC3 / Plesk 8

    I have been trawling qmail forums all over the place and finally found someone who thought he knew the issue. It seems like qmail takes the UIDs of the various users it requires at compile time so that it does not have to do lookups. Since all Plesk 8 machines should be set up in the same way, this is not problem - until they compile it on a machine where the UID for the "alias" user is zero. From then on, any part of qmail that tries to do anything with aliases fails...

    Sending messages back to "postmaster" will probably use the alias feature... they stop.
    Sending messages to mailman stops...

    I have sent off a few emails to various people to see if we can get a solution - just have to wait and see I guess!

  3. brooks

    brooks Guest

    After waiting for a couple of days for SWSoft support to get back to me I finally decided to dive into this myself. With source code and strace I was able to track the problem down. This is what I sent to SWSoft support who have passed it on to engineering:


    I think I've found the problem. I believe the order of the "conf-users"
    file was changed by someone prior to building the qmail RPM under CentOS.
    The order should be:


    But, it appears that's not the case given the output of qmail-showctl:

    user ids: 0, 2021, 2020, 2022, 2023, 2520, 2521, 2522.

    On a pre-8 Plesk box the output of qmail-showctl is:

    user ids: 2021, 2020, 2022, 0, 2023, 2520, 2521, 2522.

    Also, if you look at the following strace you'll see that qmail-lspawn
    is not pulling the "alias" user from the password file, but instead is
    using the "root" user, thus causing the failure.

    [pid 31380] open("/etc/passwd", O_RDONLY) = 3
    [pid 31380] fcntl64(3, F_GETFD) = 0
    [pid 31380] fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
    [pid 31380] fstat64(3, {st_mode=S_IFREG|0644, st_size=3100, ...}) = 0
    1, 0) = 0xb75e2000
    [pid 31380] read(3, "root:x:0:0:root:/root:/bin/bash\nbin:x:1:1:bin (deleted the rest of the passwd file output)...
    [pid 31380] close(3) = 0
    [pid 31380] munmap(0xb75e2000, 4096) = 0
    [pid 31380] write(1, "root\0000\0000\0/root\0-\0root\0", 22 <unfinished ...>
    [pid 31379] <... read resumed> "root\0000\0000\0/root\0-\0root\0", 128) = 22
    [pid 31380] <... write resumed> ) = 22
    [pid 31379] read(5, <unfinished ...>
    [pid 31380] exit_group(0) = ?
    Process 31380 detached
    [pid 31379] <... read resumed> "", 128) = 0
    [pid 31379] close(5) = 0
    [pid 31379] waitpid(31380, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 31380
    [pid 31379] fcntl64(2, F_GETFL) = 0x800 (flags O_RDONLY|O_NONBLOCK)
    [pid 31379] close(0) = 0
    [pid 31379] fcntl64(2, F_DUPFD, 0) = 0
    [pid 31379] close(2) = 0
    [pid 31379] fcntl64(4, F_GETFL) = 0x1 (flags O_WRONLY)
    [pid 31379] close(1) = 0
    [pid 31379] fcntl64(4, F_DUPFD, 1) = 1
    [pid 31379] close(4) = 0
    [pid 31379] fcntl64(1, F_GETFL) = 0x1 (flags O_WRONLY)
    [pid 31379] close(2) = -1 EBADF (Bad file descriptor)
    [pid 31379] fcntl64(1, F_DUPFD, 2) = 2
    [pid 31379] setgroups32(1, [0]) = 0
    [pid 31379] setgid32(0) = 0
    [pid 31379] setuid32(0) = 0
    [pid 31379] getuid32() = 0
    [pid 31379] exit_group(113) = ?
    Process 31379 detached
    <... select resumed> ) = ? ERESTARTNOHAND (To be restarted)
    --- SIGCHLD (Child exited) @ 0 (0) ---
    waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 113}], WNOHANG) = 31379
    close(4) = 0
    waitpid(-1, 0xbfffa3dc, WNOHANG) = -1 ECHILD (No child processes)
    sigreturn() = ? (mask now [])
    rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
    rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
    select(4, [0 3], NULL, NULL, NULL) = 1 (in [3])
    rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
    read(3, "", 128) = 0
    write(1, "\0\0ZNot allowed to perform deliveries as root.\n\0", 47) = 47

    On a working system you instead see:

    [pid 11999] open("/etc/passwd", O_RDONLY) = 3
    [pid 11999] fcntl64(3, F_GETFD) = 0
    [pid 11999] fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
    [pid 11999] fstat64(3, {st_mode=S_IFREG|0644, st_size=3730, ...}) = 0
    1, 0) = 0xb75e9000
    [pid 11999] read(3, "root:x:0:0:root:/root:/bin/bash\nbin:x:1:1:bin:/bin: / (deleted the rest of the passwd file output)...

    [pid 11999] close(3) = 0
    [pid 11999] munmap(0xb75e9000, 4096) = 0
    [pid 11999] write(1, "alias\0002021\0002020\0/var/qmail/alias\0-\0postmaster\0",
    46 <unfinished ...>
    [pid 11998] <... read resumed> "alias\0002021\0002020\0/var/qmail/alias\0-\0post
    master\0", 128) = 46
    [pid 11999] <... write resumed> ) = 46
    [pid 11998] read(5, <unfinished ...>
    [pid 11999] exit_group(0) = ?

    It looks like we'll need to get qmail rebuilt ASAP for the CentOS (3.6) release of Plesk 8 and possibly others. Please let me know when we can expect to see a new RPM, this is a fairly critical bug as no mail to any of the "system maintenance" addresses is working.


    If only SWSoft would release the source RPM we could easily fix this bug, rebuild the RPM, and get on with more important things. Lving in an open source world (of which Plesk is built on) with no way to effect change, except to fire off an email to support, is to say the least, frustrating.
  4. aveldhoven

    aveldhoven Guest

    If anyone has a resolution to this problem, please let me know, as I'm still trying to figure out what to do.

    In the meantime, I replaced user "root" in every vital thing I could imagine.

    Like crontabs, Logwatch etc, I just entered a otheremailadres, now I do receive the emails BUT STILL IT IS NOT WORKING ALRIGHT !!!
  5. brooks

    brooks Guest

    Without souce the only solution is (sadly) to wait for a patch from SWSoft. Installing the qmail RPM from the 7.5.4 might work as a temporary work-around but I'd recommend first testing it on a non-production server.

    [netgate@ds tmp]$ rpm -q psa-qmail-1.03 --whatrequires
    no package requires psa-qmail-1.03
  6. brooks

    brooks Guest

    Here's a temporary solution (unitl SWSoft releases a patch).

    First make a backup copy of /var/qmail/bin/qmail-getpw (this solution has only minimal testing so you may need to back it out).

    cp /var/qmail/bin/qmail-getpw /var/qmail/bin/qmail-getpw.bad

    From a server running the same OS but with version 7.5.4 of Plesk copy the /var/qmail/bin/qmail-getpw binary to the server running Plesk 8.

    Delivery to aliases defined in /var/qmail/alias will now work. To test it do this:

    Create the following file:

    To: root@my_hostname
    From: me@mydomain.net
    Subject: Test



    Replacing "my_hostname:" with the name of your server.

    Then do:

    cat file | /var/qmail|/bin/qmail-inject

    You should receive the above message to the destination address defined by the "root" alias.

    If anyone needs the 7.5.4/CentOS 3.6 version of the "qmail-getpw" file let me know and I'll be happy to send it to you.
  7. aveldhoven

    aveldhoven Guest


    GREAT !!
    Works like a charm...

    Only is SWSOFT reads this forum...

    Anyways.... thanx alot, got my queue almost back to empty now, and im receiving root mails again
  8. threads

    threads Guest

    I have also noted that in order to get mailman working again, you need to grab hold of the mm_wrapper program.

    The way I did it was:

    Grab hold of an older qmail....rpm

    (make sure you are somewhere like /root and NOT in the actual root)
    And things started springing into life for my FC3 installation :)

  9. aveldhoven

    aveldhoven Guest

    Thanx !

    This also worked for me.
    The only thing to mention is that you have to check if the user popuser belongs to group 110 not to group 101, this was also the case why it didnt work for me.
  10. judouk

    judouk Guest

    It seems that every time I log into my Plesk server, I have updates to do. However, I'm still using 8.0 (not 8.0.1 or anything).

    And.....to my surprise, I still cannot receive emails sent to root (like logwatch for example).

    I notice that brooks opened a ticket with support, which subsequently got pushed over to engineering - but where is the fix.

    Come on SWSOFT - this is a problem
  11. brooks

    brooks Guest

    I did hear back from them yesterday. They informed me that the problem has been fixed and will be released in an upcoming update.

    I couldn't agree with you more about how long it takes them to get a patch out, especially to what looks like a simple fix (recompile with the correct settings). I guess they see this as an annoyance bug, but to anyone responsible for the health of a server it's a lot more than an annoyance.

    Sadly, at least from my perspective, Plesk has become more about interface design and less about providing innovative features (if you call awstats innovative). Features that give providers and end users choice (stats, webmail, etc.) and providers the tools they need (reporting, communications, resource management, etc.) seem to never make it into the product. Instead we end up with yet another level (view really) in the interface. But, I've digressed (time to get back on track).

    The good news is that a fix is "in the mail".
  12. judouk

    judouk Guest

    In the mail....hmmm, I wonder if this will be US ground........
  13. NightStorm

    NightStorm Guest

    If they're sending it through Plesk mail, we may never get it. ;)
  14. pangeles

    pangeles Guest

    Webmail/Qmail Fix? Patch ETA

    So they are sending a fix sometime in the near future? Everyone in my group is wigging out due to the lack of email...

    Any timeline from SWsoft regarding this elusive patch?
  15. hedererjs

    hedererjs Guest

    "cpio -i --no-absolute-filenames < qmail.cpio"

    => this doesn't work for me. I've got a lot of "No such file or directory"
  16. hedererjs

    hedererjs Guest

    I tried "cp /var/qmail/bin/qmail-getpw /var/qmail/bin/qmail-getpw.bad"

    and all mails in queue were rejected!
  17. Tischi

    Tischi Guest

    You need the old qmail-getpw from plesk 7.x
    Can somebody upload it?
  18. hedererjs

    hedererjs Guest

    my ISP gave me the one from 7.5.4 on FC3 and it rejected every message

    if you've got another version => hedererjs at free.fr (corrected)
  19. hedererjs

    hedererjs Guest

    It seems that it's all in order back!!!!


    I deleted /opt/drweb/spool in which there were tons of files generated during my server overflow and it gave my queue a new life!!

    and with my current psa-qmail version
  20. Tischi

    Tischi Guest

    my spool directorys are all empty :p