5

I am using this tutorial to set up Postfix and Dovecot on a CentOS 7 web server. But when I try to send a test email using sudo echo "TEST" | mail -s "testmail" newuser@localhost && sudo tail -f /var/log/maillog, I get an error indicating that Dovecot does not have permissions to create the directory for storing the email. How do I go about setting up permissions for Dovecot and Postfix to be able to work properly in CentOS 7?

I am new to linux. I know about adduser, chmod, chown, octal permissions, and other commands, but I do not know how they all apply to this specific requirement, and I do not want to create ineffective things by experimenting without understanding.

Here is the most relevant part of the error message: 

Error: user import: Initialization failed: Namespace '':  
mkdir(/home/import/Maildir) failed:  
Permission denied (euid=1001(import) egid=1001(import)  
missing +w perm: /home/import, UNIX perms appear ok (ACL/MAC wrong?))

Here is the complete error message: 

Dec 30 19:03:42 mydomain postfix/pickup[8093]: A22E78221C13: uid=1000 from=<anotherusername>
Dec 30 19:03:42 mydomain postfix/cleanup[8121]: A22E78221C13: message-id=<[email protected]>
Dec 30 19:03:42 mydomain postfix/qmgr[8094]: A22E78221C13: from=<[email protected]>, size=463, nrcpt=1 (queue active)
Dec 30 19:03:42 mydomain dovecot: lda(newusername): Error: user newusername: Initialization failed: Namespace '': mkdir(/home/newusername/Maildir) failed: Permission denied (euid=1001(newusername) egid=1001(newusername) missing +w perm: /home/newusername, dir owned by 0:0 mode=0755)
Dec 30 19:03:42 mydomain dovecot: lda(newusername): Fatal: Invalid user settings. Refer to server log for more information.
Dec 30 19:03:42 mydomain postfix/local[8123]: A22E78221C13: to=<[email protected]>, orig_to=<newusername@localhost>, relay=local, delay=0.15, delays=0.06/0.02/0/0.07, dsn=4.3.0, status=deferred (temporary failure)

EDIT:

I then ran sudo chown -R newusername:newusername /home/newusername and then again repeated sudo echo "TEST" | sudo mail -s "testmail" newuser@localhost && sudo tail -f /var/log/maillog but still got the following error: 

Dec 30 20:42:29 mydomain postfix/qmgr[8094]: E0DF28221C14: from=<[email protected]>, size=463, nrcpt=1 (queue active)
Dec 30 20:42:29 mydomain dovecot: lda(newusername): Error: user newusername: Initialization failed: Namespace '': mkdir(/home/newusername/Maildir) failed: Permission denied (euid=1001(newusername) egid=1001(newusername) missing +w perm: /home/newusername, UNIX perms appear ok (ACL/MAC wrong?))
Dec 30 20:42:29 mydomain dovecot: lda(newusername): Fatal: Invalid user settings. Refer to server log for more information.
Dec 30 20:42:29 mydomain postfix/local[8531]: E0DF28221C14: to=<[email protected]>, orig_to=<newusername@localhost>, relay=local, delay=1101, delays=1101/0.02/0/0.06, dsn=4.3.0, status=deferred (temporary failure)
Dec 30 20:45:40 mydomain postfix/pickup[8529]: CF3CB80B33C4: uid=0 from=<root>
Dec 30 20:45:40 mydomain postfix/cleanup[8551]: CF3CB80B33C4: message-id=<[email protected]>
Dec 30 20:45:40 mydomain postfix/qmgr[8094]: CF3CB80B33C4: from=<[email protected]>, size=455, nrcpt=1 (queue active)
Dec 30 20:45:40 mydomain dovecot: lda(newusername): Error: user newusername: Initialization failed: Namespace '': mkdir(/home/newusername/Maildir) failed: Permission denied (euid=1001(newusername) egid=1001(newusername) missing +w perm: /home/newusername, UNIX perms appear ok (ACL/MAC wrong?))
Dec 30 20:45:40 mydomain dovecot: lda(newusername): Fatal: Invalid user settings. Refer to server log for more information.
Dec 30 20:45:40 mydomain postfix/local[8553]: CF3CB80B33C4: to=<[email protected]>, orig_to=<newusername@localhost>, relay=local, delay=0.15, delays=0.08/0.02/0/0.05, dsn=4.3.0, status=deferred (temporary failure)

ANSWER:

This problem was due to SELinux. I resolved the problem by sudo nano /etc/sysconfig/selinux and then setting SELINUX=disabled. This is acceptable during development. A more complete solution will be to set up an SELinux rule allowing postfix and dovecot to function before this goes into production.

Note: Seven-Hundred-and-Forty-Two suggestion that I check SELinux status, so I am marking his as the correct answer.

CodeMed
  • 5,079
  • 45
  • 100
  • 147
  • Seems you're missing a sudo in `sudo echo "TEST" | mail -s "testmail" newuser@localhost && sudo tail -f /var/log/maillog`. Try: `echo "TEST" | sudo mail -s "testmail" newuser@localhost && sudo tail -f /var/log/maillog` – Outurnate Dec 31 '14 at 01:39

2 Answers2

2

The key is here: failed: Permission denied (euid=1001(newusername) egid=1001(newusername) missing +w perm: /home/newusername, dir owned by 0:0 mode=0755

Dovecot is trying to write to /home/newusername/{whatever your maildir is} as newusername:newusername, however, the directory is owned by user 0:0 (root). Because the permission mode is 755, only the owner has +w permissions

Also, ensure that if you are using SELinux that your ACLs allow dovecot to write to your maildir

Outurnate
  • 1,179
  • 9
  • 19
  • What do you mean, when no user is logged in? Dovecot runs in a separate process as the dovecot user. Dovecot is writing as user 1001 (newusername) which doesn't have write access to your maildir, because root owns it. – Outurnate Dec 31 '14 at 01:14
  • No worries. Run `chown -R newusername:newusername /home/newusername` as root. This will change the owner of the newusername's home directory to newusername, recursively – Outurnate Dec 31 '14 at 01:19
  • Can you add the output of `dovecot -n`? – Outurnate Dec 31 '14 at 01:35
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/19870/discussion-between-seven-hundred-and-forty-two-and-codemed). – Outurnate Dec 31 '14 at 01:47
  • Done. For the benefit of future users, can you elaborate on what was necessary to allow dovecot to function? – Outurnate Dec 31 '14 at 22:18
  • I just posted the steps for resolving the error at the end of my OP. Thank you again. – CodeMed Dec 31 '14 at 22:22
0

I have ran into the same issue. The parent also mentioned it got it working by disabling selinux. Thank you for the tip. Disabling SEL was not option for me.

So, if you don't want to disable selinux, try:

  • check the SELinux context of the "problem" directory:
ls -Z /home/newusername
drwx------. centos       centos       unconfined_u:object_r:user_home_dir_t:s0 centos
drwx------. newusername  newusername  unconfined_u:object_r:home_root_t:s0 newusername
  • it should show the user_home_dir_t as context
  • it should not be the home_root_t selinux context.

Observation: If you create the homedir as root, it will pick-up the root context, and then every object created by the user will have the root context.

  • to fix this run:
restorecon -vR /home/newuserhome
  • check the SELinux context again, you should have now:
ls -Z /home/newusername
drwx------. centos       centos       unconfined_u:object_r:user_home_dir_t:s0 centos
drwx------. newusername  newusername  unconfined_u:object_r:user_home_dir_t:s0 newusername
  • test: try to create a file or a dir inside newuserhome and check SEL context
  • if the new file still does not show proper context run:
semanage fcontext -a -e /home /home/newusername
restorecon -vR /home/newuserhome

Hopefully it should have the proper context now for "normal" home-directories and allow access.

ionescu77
  • 101
  • 3