Permission denied when getting mail

10 posts / 0 new
Last post
#1 Tue, 06/03/2008 - 06:08

Permission denied when getting mail

Hey, first off, I'll tell you my system.

Operating system: CentOS Linux 4.6 Webmin version: 1.420 Virtualmin version: 3.57.gpl (GPL) Running Dovecot 0.99.11

I'm not really sure if this has been going on since I set up the system some months back, or if I changed something at one point that caused it to mess up.

Here's the problem. If I set up a mail user under a virtual server in Virtualmin, I can't log in to dovecot through pop3 or imap to get the mail. It works for the main user account on the virtual server, but not for created users under it.

I looked in the maillog and this is what I get every time I try to retrieve mail for the created user "register" under the virtual server: dovecot: chdir(/home/mainuser/homes/register) failed with uid 501: Permission denied pop3-login: Login: register.mainuser [::ffff:] dovecot: child 16754 (pop3) returned error 89

I get the same error with imap, it just says imap instead.

I've tried messing around with permissions, giving the homes and register directories full 777 permissions and still permission is denied.

Has this issue been brought up before? Any known workarounds or fixes for it?

Thanks for any help.

Tue, 06/03/2008 - 08:05
ronald's picture

I'm not too sure but setting 777 won't do anything when the new user is trying to login with the wrong credentials (being login name and password)
that is at least where I would look to solve this

Tue, 06/03/2008 - 13:43 (Reply to #2)
ronald's picture

do you not have "yum update" as a daily cron?

Tue, 06/03/2008 - 14:04 (Reply to #3)
Joe's picture

There's another option for doing yum updates daily...most new distros have yum-updatesd. Enabling updates just requires editing /etc/yum/yum-updatesd.conf. Change:

do_update = no

To "yes", and restart the yum-updatesd service.


Check out the forum guidelines!

Tue, 06/03/2008 - 14:06 (Reply to #4)
Joe's picture

Of course, running yum update via cron means you don't have the (somewhat large) yum-updatesd running all the time! The daemon's primary purpose is to make sure desktop notification works, and since none of us are talking about desktop machines, this is irrelevant. ;-)


Check out the forum guidelines!

Tue, 06/03/2008 - 16:48 (Reply to #5)
ronald's picture

:) it also means you can set the cron at a time the server is less used. like when you're sleeping

Tue, 06/03/2008 - 08:19

I'm pretty sure the credentials are correct. If you look at the maillog it doesn't say it's not logging me in. It seems to have the problem with changing the directory.

I tried telnetting in:

telnet localhost 110
Connected to localhost.localdomain (
Escape character is '^]'.
+OK dovecot ready.
user register.collegia
pass ***
+OK Logged in.
Connection closed by foreign host.

And it kicks me out like that. It says I logged in, though.

I just recreated the user and put in the password, so I'm pretty sure that's all fine.

Thanks for your help and any other advice you might have.
I'm wondering if there's maybe something wrong with Virtualmin/Webmin working with CentOS 4 and Dovecot.

Tue, 06/03/2008 - 09:07 (Reply to #7)
Joe's picture

You need a newer Dovecot version. We provide a 1.0 package in our repositories...but I just noticed that I failed to include that in the GPL repository. I've just added it. You'll want to upgrade. If you aren't using our repository, you can either add it, or you can just grab the individual package from:


The other alternative is to configure Virtualmin to create home directories with 751 permissions (in the Webmin:System:Users and Groups module configuration), and change the permissions of all directories in /home to 751 instead of 750.

This is because old versions of Dovecot do not support secondary groups.


Check out the forum guidelines!

Tue, 06/03/2008 - 09:52

A simple "yum update" and everything's working now.
Thanks a lot for the quick reply and fix.

Wed, 09/09/2009 - 14:18 (Reply to #9)

I also fixed this issue by making sure that the domains home directory (/home/###) had 755 permissions. For some reason new domains were being created with drwxr-x--- permissions. Changing the individual user permissions under /home/domain/homes/### to 777 did not solve the problem.

Topic locked