[Dovecot] Permission denied after dist-upgrade
Hello,
after I have done a dist-upgrade to Squeeze, I got some nasty problem with my dovecot. When I try to establish a connection via IMAP, it doesn't react and writes the following into my logfile:
2011-02-16 15:23:49 imap-login: Info: Login: user=thomas@XXX, method=PLAIN, rip=84.130.16.134, lip=XX.XXX.XX.XXX, TLS 2011-02-16 14:23:49 dovecot: Fatal: chdir(/home/vmail/XXX/thomas/) failed: Permission denied (euid=5000(<unknown>) egid=5000(<unknown>) stat() failed: No such file or directory) 2011-02-16 15:23:49 dovecot: Error: child 14493 (imap) returned error 89 (Fatal failure)
dovecot -n: # 1.2.15: /etc/dovecot/dovecot.conf # OS: Linux 2.6.26-2-xen-amd64 x86_64 Debian 6.0 ext3 log_path: /home/vmail/dovecot-info.log log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s ssl_ca_file: /etc/ssl/certs/sub.class1.server.ca.pem login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login mail_privileged_group: vmail mail_uid: vmail mail_gid: vmail mail_location: maildir:/home/vmail/%d/%n/ mbox_write_locks: fcntl dotlock mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 namespace: type: private separator: . prefix: INBOX. inbox: yes list: yes subscriptions: yes lda: log_path: /home/vmail/dovecot-deliver.log postmaster_address: postmaster@XXX auth_socket_path: /var/run/dovecot/auth-master global_script_path: /home/vmail/globalsieverc auth default: mechanisms: plain login passdb: driver: pam passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: passwd userdb: driver: static args: uid=vmail gid=vmail home=/home/vmail/%d/%n allow_all_users=yes socket: type: listen client: path: /var/run/dovecot/auth-client mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail
I tried to change privileges for /home/vmail/, didn't work. What makes me wonder is the <unknown>-label after euid=5000. Anyone an idea how to fix that problem?
Thomas
On 02/16/11 16:42, Thomas Skowron wrote:
Hello,
after I have done a dist-upgrade to Squeeze, I got some nasty problem with my dovecot. When I try to establish a connection via IMAP, it doesn't react and writes the following into my logfile:
2011-02-16 15:23:49 imap-login: Info: Login: user=thomas@XXX, method=PLAIN, rip=84.130.16.134, lip=XX.XXX.XX.XXX, TLS 2011-02-16 14:23:49 dovecot: Fatal: chdir(/home/vmail/XXX/thomas/) failed: Permission denied (euid=5000(<unknown>) egid=5000(<unknown>) stat() failed: No such file or directory) 2011-02-16 15:23:49 dovecot: Error: child 14493 (imap) returned error 89 (Fatal failure)
master: path: /var/run/dovecot/auth-master mode: 384 user: vmail
Hello,
I think your user "vmail" (uid=5000, gid=5000) got lost along the line somewhere ....
Cheers Jan
-- MAX-PLANCK-INSTITUT fuer Radioastronomie Jan Behrend - Rechenzentrum
Auf dem Huegel 69, D-53121 Bonn Tel: +49 (228) 525 359, Fax: +49 (228) 525 229 jbehrend@mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de
Am 16.02.2011 um 16:48 schrieb Jan Behrend:
I think your user "vmail" (uid=5000, gid=5000) got lost along the line somewhere ....
Well, I believe it didn't, /etc/passwd contains
vmail:x:5000:5000::/home/vmail:/bin/sh
I already have deleted the user and created vmail again, but still... it doesn't work.
On 16.2.2011, at 17.42, Thomas Skowron wrote:
2011-02-16 14:23:49 dovecot: Fatal: chdir(/home/vmail/XXX/thomas/) failed: Permission denied (euid=5000(<unknown>) egid=5000(<unknown>) stat() failed: No such file or directory)
Weirdness 1: So there's <unknown> even though 5000 uid and gid exists?
Weirdness 2: stat() fails with ENOENT.
Do you have SELinux or something enabled?
Am 16.02.2011 um 17:01 schrieb Timo Sirainen:
Weirdness 1: So there's <unknown> even though 5000 uid and gid exists?
Weirdness 2: stat() fails with ENOENT.
Do you have SELinux or something enabled?
Well, it exists, but I got absolutely no idea why that happens. I haven't even typed in uid 5000 within the config file - it contains only the username 'vmail'. So dovecot is able to translate vmail to uid 5000, but not uid 5000 to user vmail.
SELinux has never been enabled.
Am 16.02.2011 um 17:01 schrieb Timo Sirainen:
Weirdness 1: So there's <unknown> even though 5000 uid and gid exists?
Weirdness 2: stat() fails with ENOENT.
Do you have SELinux or something enabled?
Well, it exists, but I got absolutely no idea why that happens. I haven't even typed in uid 5000 within the config file - it contains only the username 'vmail'. So dovecot is able to translate vmail to uid 5000, but not uid 5000 to user vmail.
SELinux has never been enabled.
On 16.2.2011, at 18.30, Thomas Skowron wrote:
Am 16.02.2011 um 17:01 schrieb Timo Sirainen:
Weirdness 1: So there's <unknown> even though 5000 uid and gid exists?
Weirdness 2: stat() fails with ENOENT.
Do you have SELinux or something enabled?
Well, it exists, but I got absolutely no idea why that happens. I haven't even typed in uid 5000 within the config file - it contains only the username 'vmail'. So dovecot is able to translate vmail to uid 5000, but not uid 5000 to user vmail.
SELinux has never been enabled.
Another thing I thought of was chrooting, but I don't see any chrooting in your config.
Maybe you could find out something interesting by starting Dovecot with "strace -f -o log dovecot".
Another thing I thought of was chrooting, but I don't see any chrooting in your config.
Maybe you could find out something interesting by starting Dovecot with "strace -f -o log dovecot".
15311 setresgid(-1, 5000, -1) = 0 15311 setresuid(-1, 5000, -1) = 0 15311 alarm(30) = 0 15311 chdir("/home/vmail/XXX/thomas") = -1 EACCES (Permission denied) 15311 alarm(0) = 30 15311 geteuid() = 5000 15311 geteuid() = 5000 15311 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) 15311 getegid() = 5000 15311 getegid() = 5000 15311 open("/etc/group", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) 15311 stat("/home/vmail/XXX/thomas", 0x7fffd3a4c4a0) = -1 EACCES (Permission denied) 15311 stat("/home/vmail/XXX", 0x7fffd3a4c4a0) = -1 EACCES (Permission denied) 15311 stat("/home/vmail", 0x7fffd3a4c4a0) = -1 EACCES (Permission denied) 15311 stat("/home", 0x7fffd3a4c4a0) = -1 EACCES (Permission denied) 15311 stat("", 0x7fffd3a4c4a0) = -1 ENOENT (No such file or directory) 15311 time(NULL) = 1297888629 15311 stat("/etc/localtime", 0x7fffd3a4c100) = -1 EACCES (Permission denied) 15311 open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)
Is setresgid(-1,5000,-1) correct? I mean: -1!?
On 16.2.2011, at 22.49, Thomas Skowron wrote:
Another thing I thought of was chrooting, but I don't see any chrooting in your config.
Maybe you could find out something interesting by starting Dovecot with "strace -f -o log dovecot".
15311 setresgid(-1, 5000, -1) = 0 15311 setresuid(-1, 5000, -1) = 0
So it changes uid and gid to 5000.
15311 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) 15311 open("/etc/group", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) 15311 stat("/home", 0x7fffd3a4c4a0) = -1 EACCES (Permission denied) 15311 stat("/etc/localtime", 0x7fffd3a4c100) = -1 EACCES (Permission denied)
But that doesn't have permissions to do anything. If it's not because of filesystem permissions or SELinux/Apparmor, I don't know what it could be.
Is setresgid(-1,5000,-1) correct? I mean: -1!?
Yes. -1 means it's not changed.
Thomas Skowron put forth on 2/16/2011 2:49 PM:
Another thing I thought of was chrooting, but I don't see any chrooting in your config.
Maybe you could find out something interesting by starting Dovecot with "strace -f -o log dovecot".
15311 setresgid(-1, 5000, -1) = 0 15311 setresuid(-1, 5000, -1) = 0 15311 alarm(30) = 0 15311 chdir("/home/vmail/XXX/thomas") = -1 EACCES (Permission denied) 15311 alarm(0) = 30 15311 geteuid() = 5000 15311 geteuid() = 5000 15311 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) 15311 getegid() = 5000 15311 getegid() = 5000 15311 open("/etc/group", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) 15311 stat("/home/vmail/XXX/thomas", 0x7fffd3a4c4a0) = -1 EACCES (Permission denied) 15311 stat("/home/vmail/XXX", 0x7fffd3a4c4a0) = -1 EACCES (Permission denied) 15311 stat("/home/vmail", 0x7fffd3a4c4a0) = -1 EACCES (Permission denied) 15311 stat("/home", 0x7fffd3a4c4a0) = -1 EACCES (Permission denied) 15311 stat("", 0x7fffd3a4c4a0) = -1 ENOENT (No such file or directory) 15311 time(NULL) = 1297888629 15311 stat("/etc/localtime", 0x7fffd3a4c100) = -1 EACCES (Permission denied) 15311 open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)
Is setresgid(-1,5000,-1) correct? I mean: -1!?
Have you done a full system reboot since the dist upgrade? If not, IIRC, glibc hasn't been replaced yet and the old version is still running. There are probably other libs that can't be replaced until a full restart as well. Do a full reboot if you haven't already. Then, if it's still not working...
What is the output of
~# aptitude -v show dovecot-imapd dovecot-common
and
~# la /usr/lib/dovecot/
Do you have any pam or mysql errors in syslog with a similar time stamp to the dovecot errors? Were you running 1.0.15 Lenny before the Squeeze upgrade or one of the 1.2.x Lenny backport versions?
If you didn't change filesystem permissions or dovecot config parms, then it seems logical that you have a component mismatch after the upgrade, or something along those lines, that is causing permissions problems. Check to make sure all of your dovecot components are of the same version. If you're still running a backport version of dovecot, try installing the Squeeze version. There could be a mismatch between apps and lib versions.
I've not upgraded my servers to Squeeze yet, and I'm running the Lenny backport Dovecot 1.2.15. I'm curious to discover the source of your problem so I can avoid it.
-- Stan
Okay, guys. I am an idiot.
What I did now was apt-get update upgrade and volià: it works. Sorry for taking your time.
Am 17.02.2011 um 05:32 schrieb Stan Hoeppner:
Have you done a full system reboot since the dist upgrade? If not, IIRC, glibc hasn't been replaced yet and the old version is still running. There are probably other libs that can't be replaced until a full restart as well. Do a full reboot if you haven't already. Then, if it's still not working...
Damn it. It worked for like 10 minutes and then crashed again. I can't even explain why it worked for a short time at all. I believe I did like about 20 reboots in the last days, so libs should be loaded.
~# aptitude -v show dovecot-imapd dovecot-common
What I did is purging the packages dovecot (including imapd and common), deleting everything that has to do with that and created every config from scratch. I created a new user (new uid, new home), but the error still appears.
One thing I can't understand:
15311 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
Everyone can read /etc/passwd. Everyone, but not dovecot. Drives me crazy.
dovecot-imapd and dovecot-common are both version 1:1.2.15-4. So that should be fine.
~# la /usr/lib/dovecot/
I believe you meant ls -la /usr/lib/dovecot
drwxr-xr-x 3 root root 4096 17. Feb 22:42 . drwxr-xr-x 57 root root 36864 17. Feb 23:35 .. -rwxr-xr-x 1 root root 114536 25. Jan 00:29 authtest -rwxr-xr-x 1 root root 61904 25. Jan 00:29 checkpassword-reply -rwxr-xr-x 1 root root 814736 25. Jan 00:29 convert-tool -rwxr-xr-x 1 root root 962032 25. Jan 00:29 deliver -rwxr-xr-x 1 root root 212736 25. Jan 00:29 dict -rwxr-xr-x 1 root root 401376 25. Jan 00:29 dovecot-auth -rwxr-xr-x 1 root root 929624 25. Jan 00:29 expire-tool -rwxr-xr-x 1 root root 347 25. Jan 00:29 expire-tool.sh -rwxr-xr-x 1 root root 62216 25. Jan 00:29 gdbhelper -rwxr-xr-x 1 root root 319968 25. Jan 00:29 idxview -rwxr-xr-x 1 root root 1018992 25. Jan 00:29 imap -rwxr-xr-x 1 root root 213896 25. Jan 00:29 imap-login -rwxr-xr-x 1 root root 97864 25. Jan 00:29 imap-utf7 -rwxr-xr-x 1 root root 65096 25. Jan 00:29 listview -rwxr-xr-x 1 root root 65504 25. Jan 00:29 logview -rwxr-xr-x 1 root root 90096 25. Jan 00:29 maildirlock -rwxr-xr-x 1 root root 916200 25. Jan 00:29 managesieve -rwxr-xr-x 1 root root 209872 25. Jan 00:29 managesieve-login drwxr-xr-x 6 root root 4096 17. Feb 22:42 modules -rwxr-xr-x 1 root root 939792 25. Jan 00:29 pop3 -rwxr-xr-x 1 root root 199112 25. Jan 00:29 pop3-login -rwxr-xr-x 1 root root 89856 25. Jan 00:29 rawlog -rwxr-xr-x 1 root root 65544 25. Jan 00:29 ssl-build-param -rwxr-xr-x 1 root root 65096 25. Jan 00:29 threadview
Do you have any pam or mysql errors in syslog with a similar time stamp to the dovecot errors? Were you running 1.0.15 Lenny before the Squeeze upgrade or one of the 1.2.x Lenny backport versions?
I was using 1.0.15 before. No backport. pam errors: none mysql errors: none It even seems to recognize if the password is correct. If I type in the wrong password it tells me auth failed, but when it's the right one, it crashes.
If you didn't change filesystem permissions or dovecot config parms, then it seems logical that you have a component mismatch after the upgrade, or something along those lines, that is causing permissions problems. Check to make sure all of your dovecot components are of the same version. If you're still running a backport version of dovecot, try installing the Squeeze version. There could be a mismatch between apps and lib versions.
Versions seem to be okay. The only thing that has been updated on the server is the kernel (2.6.26-2-xen-amd64). Could this be possibly a problem?
Thomas Skowron put forth on 2/17/2011 6:19 PM:
Versions seem to be okay. The only thing that has been updated on the server is the kernel (2.6.26-2-xen-amd64). Could this be possibly a problem?
Squeeze is built against kernel 2.6.32-5. Although it is unlikely that the old 2.6.26 kernel is related to this problem I guess it's possible. Regardless you should upgrade the kernel to the amd64 squeeze kernel.
Why are you running a Xen kernel? That would suggest you're running multiple virtual machines. Are you? Is this Dovecot server inside a virtual machine? If so, why are you reporting to us the kernel version of the hypervisor instead of the guest OS?
I'm confused. I'm guessing that's because you're more confused. A standard distribution upgrade shouldn't be causing these problems. I'm guessing something else is amiss here.
-- Stan
have you tried to start dovecot as root via sudo to check if some files permissions are wrong or if some files are missing ?
Le 18/02/2011 03:05, Stan Hoeppner a écrit :
Thomas Skowron put forth on 2/17/2011 6:19 PM:
Versions seem to be okay. The only thing that has been updated on the server is the kernel (2.6.26-2-xen-amd64). Could this be possibly a problem?
Squeeze is built against kernel 2.6.32-5. Although it is unlikely that the old 2.6.26 kernel is related to this problem I guess it's possible. Regardless you should upgrade the kernel to the amd64 squeeze kernel.
Why are you running a Xen kernel? That would suggest you're running multiple virtual machines. Are you? Is this Dovecot server inside a virtual machine? If so, why are you reporting to us the kernel version of the hypervisor instead of the guest OS?
I'm confused. I'm guessing that's because you're more confused. A standard distribution upgrade shouldn't be causing these problems. I'm guessing something else is amiss here.
Am 18.02.2011 um 03:05 schrieb Stan Hoeppner stan@hardwarefreak.com:
Thomas Skowron put forth on 2/17/2011 6:19 PM:
Versions seem to be okay. The only thing that has been updated on the server is the kernel (2.6.26-2-xen-amd64). Could this be possibly a problem?
Squeeze is built against kernel 2.6.32-5. Although it is unlikely that the old 2.6.26 kernel is related to this problem I guess it's possible. Regardless you should upgrade the kernel to the amd64 squeeze kernel.
Why are you running a Xen kernel? That would suggest you're running multiple virtual machines. Are you? Is this Dovecot server inside a virtual machine? If so, why are you reporting to us the kernel version of the hypervisor instead of the guest OS?
I am on a virtual machine (it's a virtual dedicated server). I have performed a standard dist upgrade, but my provider isn't giving me the possibility to upgrade the kernel. It's a mess. Why Xen? No idea. That's simply what uname -a says me.
Well, I assume I got to ask my provider for any information.
Thomas Skowron put forth on 2/18/2011 3:27 AM:
Am 18.02.2011 um 03:05 schrieb Stan Hoeppner stan@hardwarefreak.com:
Thomas Skowron put forth on 2/17/2011 6:19 PM:
Versions seem to be okay. The only thing that has been updated on the server is the kernel (2.6.26-2-xen-amd64). Could this be possibly a problem?
Squeeze is built against kernel 2.6.32-5. Although it is unlikely that the old 2.6.26 kernel is related to this problem I guess it's possible. Regardless you should upgrade the kernel to the amd64 squeeze kernel.
Why are you running a Xen kernel? That would suggest you're running multiple virtual machines. Are you? Is this Dovecot server inside a virtual machine? If so, why are you reporting to us the kernel version of the hypervisor instead of the guest OS?
I am on a virtual machine (it's a virtual dedicated server). I have performed a standard dist upgrade, but my provider isn't giving me the possibility to upgrade the kernel. It's a mess. Why Xen? No idea. That's simply what uname -a says me.
Well, I assume I got to ask my provider for any information.
Ahh, the wonderful world of cheap VPS. If this is a "dedicated" server, how are they preventing you from replacing the kernel image? You have root access don't you? Then there should be nothing stopping you from updating the kernel. If they can physically prevent you from doing so then this is certainly NOT a dedicated server platform, but a hybrid VPS hosting platform.
As your problems are very unlikely caused by Dovecot, but by the Squeeze upgrade, I'd suggest you take this up on the Debian users list. Someone there may be able to give you more insight.
BTW, does your VPS provider support Squeeze? Did you ask them before upgrading? It would appear they don't yet support Squeeze...
Good luck.
-- Stan
On Wed, 16 Feb 2011 16:42:34 +0100, Thomas Skowron thskowron@googlemail.com wrote:
after I have done a dist-upgrade to Squeeze, I got some nasty problem with my dovecot. When I try to establish a connection via IMAP, it doesn't react and writes the following into my logfile:
We also have systems based in Debian (Squeeze).
After all what has been said it sure looks like a chroot problem.
Could you post the (exact) contents of the following command: grep 'vmail\|5000' /etc/passwd /etc/group /etc/dovecot/dovecot.conf
As in Squeeze Postfix runs chrooted, I wonder, did you re-configured the postfix chroot (see /var/spool/postfix/) and put there all what you need to avoid chroot problemas while combining Dovecot +Postfix + MySQL?
Finally, are shure that your VPS provider isn't encapsulating in chroot jails either your private configs in /etc/ or your stuff in /home/ ?
M.
Mark Alan put forth on 2/18/2011 6:48 AM:
On Wed, 16 Feb 2011 16:42:34 +0100, Thomas Skowron thskowron@googlemail.com wrote:
after I have done a dist-upgrade to Squeeze, I got some nasty problem with my dovecot. When I try to establish a connection via IMAP, it doesn't react and writes the following into my logfile:
We also have systems based in Debian (Squeeze).
After all what has been said it sure looks like a chroot problem.
Could you post the (exact) contents of the following command: grep 'vmail\|5000' /etc/passwd /etc/group /etc/dovecot/dovecot.conf
As in Squeeze Postfix runs chrooted, I wonder, did you re-configured the postfix chroot (see /var/spool/postfix/) and put there all what you need to avoid chroot problemas while combining Dovecot +Postfix + MySQL?
Finally, are shure that your VPS provider isn't encapsulating in chroot jails either your private configs in /etc/ or your stuff in /home/ ?
Very good points. I hadn't considered that the provider may be monkeying with the guest chroot config, though this makes perfect sense it a cheap "virtual" hosting environment. However, if that's the case, I wouldn't think they'd have allowed him to upgrade the OS as there would be multiple customers sharing the same guest instance. If not, why would the provider monkey with jails in the guest?
-- Stan
participants (6)
-
Frank Bonnet
-
Jan Behrend
-
Mark Alan
-
Stan Hoeppner
-
Thomas Skowron
-
Timo Sirainen