Docker-mailserver: 2.3 Issues Thread - master.lock: cannot open file: Permission denied

[strarsis]

The mail system starts up with docker-compose up -d - however,
port 25 and 587 refuse a connection while other (e.g. 143 (IMAP)) work.
The postfix service isn't running at all, in container in
'/var/log/mail/mail.err' (and '[...]mail.log') postfix logged an error:
postfix/master[1093]: fatal: open lock file /var/lib/postfix/master.lock: cannot open file: Permission denied
When this happens there should be at least an error logged to docker or startup cancelled.

[tomav]

Could you share your config and debug startup as stated here? Thank you.

[strarsis]

The problem was caused by having different ownerships than root for the mounted host directories.

The issue is that the mail container fails silently instead failing directly at startup with logging an error when postfix isn't able to start.

[tomav]

Want to add this check on startup?

[kiliant]

I just had this issue. Problem was that postfix couldn't start up somehow as ownership on mailstate/lib-postfix/ was root:root and not 105:108.

Is there another way of restoring permissions than to remove the mailstate folder?

[tomav]

This may be added in start-mailserver.sh because we already fix some permissions if needed.
Other (additional) option is to have a standalone helper script that can be run on demand.
Note that upgrade to ubuntu:16.04 may break user ids.

[zerpex]

Hi, I face the same issue since the last update, so I think it would be a really good idea to add a permission check at startup :)

regards

[Lordmau5]

Hey-ho!

I'll just pitch in with the same issue.

Had to downgrade to 2.3 to fix this, which is not optimal because there are some fixes in the latest build that I'd really like to have.

[tomav]

@kiliant any idea for adding this check?

[strarsis]

@tomav: One improvement would be already if Dovecot logs to container stdout/logs.
Using a process/service manager like supervisord or chaperone.d would allow proper exit in case of errors.

[tomav]

@strarsis: https://github.com/tomav/docker-mailserver/issues/434 We're open to PR

[kiliant]

@tomav an idea would be to integrate chown (or a permission check) in start-mailserver.sh. It is sufficient to chown from inside the container when the volume is mounted _rw_ (worked for me).

I would have to figure out what volume needs to be owned by what user and how to integrate that in the script. Can have a look at this if I have time, but maybe #586 has more prio.

[kortenkamp]

Just to put in a "me too" – I figured out that I have the same problem related to permissions in the mailstate volume. This is what fixed it for me: I attached to the mail image and change the owners in /var/mail-state as follows:

chown -R clamav lib-clamav
chown -R postfix lib-postfix
chown -R postgrey lib-postgrey
chown -R debian-spamd lib-spamassasin
chown -R postfix spool-postfix

No idea whether this is all and whether it is indeed correct, but at least I can send and receive mail again. Would be great to have this in the startup script to fix ownerships automatically.

[tomav]

@kortenkamp permissions seem to work for me. Don't forget to start postgrey if not running.

[techgourmet]

This did solve the problem.
Adding a permissions check/fix on startup could prevent this as said by @kortenkamp

[tomav]

There is also master.cf to change, because chroot had y as default value. It's now n.
This will avoid warnings regarding backward compatibility.

[tomav]

Here is the PR https://github.com/tomav/docker-mailserver/pull/612

[tomav]

:latest image available.

[thiesschneider]

I still cant send emails with this image. Do you have to use special envs?

thx!

[tomav]

What is the error in the logs when using :latest? It was a mess to reproduce so perhaps its not 100% fixed.

[thiesschneider]

I had the :2.3 tag.
I will try again with the latest tag and post the logs if it does not work.

edit: If I use the latest tag it is working!
Thx for everything

[tomav]

Thanks.

[tomav]

I'll update 2.3 tag once fix is confirmed.

[M-M-M-M]

Could you create a stable 2.4 tag with that fix? or a even 2.3.1?

For history: I have upgraded from 2.1 to 2.3 to get this same permission error.
Using latest tag on 2017-05-29 is resolving this issue.

[tomav]

@M-M-M-M thanks for confirming its working as expected.
I updated 2.3 tag (even if its not a good practice).
Currently building: https://hub.docker.com/r/tvial/docker-mailserver/builds/

[tomav]

Build available with :2.3 tag.

[M-M-M-M]

Thank you but using the same tag is causing issue with caches as the new 2.3 is not refreshed until you removed it manually before any rebuild. For instance, I had to perform a docker rmi 245b6fb89f3b before getting a "correct" rebuild.

[kiliant]

Have you tried docker pulling with the 2.3 tag?

[M-M-M-M]

Of course. But I had already pulled the 2.3 tag version before the fix was applied. So once fixed has been deployed to same 2.3 tag then a new pull request of 2.3 was looking first in my local cache rather than on hub and so not retrieving the fixed 2.3 version.

[ChromoX]

I'm having this same problem on a brand new 2.3 tag. Weird thing is that all file permissions look correct to me.

runuser -l postfix -c 'touch /var/lib/postfix/master.lock'
runuser: warning: cannot change directory to /var/spool/postfix: Permission denied

Permissions for /var/lib/postfix:

root@641dd1fff440:/var/lib/postfix# ls -lah
total 8.0K
drwxr-xr-x 2 postfix postfix 4.0K Aug 15 19:34 .
drwxrwxrwx 9 root    root    4.0K Aug 15 19:40 ..

Even weirder the permissions for the /var/spool/postfix directory look correct to me.

root@641dd1fff440:/var/spool/postfix# ls -lah
total 80K
drwxr-xr-x 20 postfix root     4.0K Aug 15 19:40 .
drwxrwxrwx  9 root    root     4.0K Aug 15 19:40 ..