docker-mailserver: [BUG] Restarting the container changes the owner of folders in /var/mail to 5000

Sorry for popping up again 😃 but I have to report this too.

Miscellaneous first checks

  • I checked that all ports are open and not blocked by my ISP / hosting provider.
  • I know that SSL errors are likely the result of a wrong setup on the user side and not caused by DMS itself. I’m confident my setup is correct.

Affected Component(s)

Mail home folder permissions (observed in v10.1.2 and 10.2.0)

What happened and when does this occur?

When trying to use the mailserver, some permission error related to mail home directory is shown.

What did you expect to happen?

To not get the error

How do we replicate the issue?

Try the attached configuration with LDAP server.

DMS version

Observed in 10.1.2 and 10.2.0 (maybe also in other versions, but I did not test with other versions)

How much RAM is available to DMS explicitly?

less than 2GB

How many CPU cores are available?

less than 1 Core

Is DMS running in a virtualized environment?

… a virtual private server (VPS) (with virtual CPU cores)

What operating system is DMS running on?

Linux

What instruction set architecture is DMS running on?

x86_64 / AMD64

I/O - Persistent memory

What container orchestration tool are you using?

Docker Compose

Docker version

Docker version 20.10.8, build 3967b7d

Docker Compose version

docker-compose version 1.29.2, build 5becea4c

The output of uname -a

Linux srv02 5.4.0-84-generic #94-Ubuntu SMP Thu Aug 26 20:27:37 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Important environment variables

DMS_DEBUG=1

POSTMASTER_ADDRESS=postmaster@MYDOMAIN.com

SSL_TYPE=manual
SSL_CERT_PATH=/etc/ssl/pki/mail.MYDOMAIN.com.crt
SSL_KEY_PATH=/etc/ssl/pki/mail.MYDOMAIN.com.key

ENABLE_LDAP=1
LDAP_START_TLS=yes
LDAP_SERVER_HOST=dc1.internal.MYDOMAIN.com
LDAP_SEARCH_BASE=dc=internal,dc=MYDOMAIN,dc=com
LDAP_BIND_DN=cn=Administrator,cn=users,dc=internal,dc=MYDOMAIN,dc=com
LDAP_BIND_PW=Ch@ngeMe
# Specifies how ldap should be asked for users.
LDAP_QUERY_FILTER_USER=(&(objectclass=person)(mail=%s))
# Specifies how ldap should be asked for groups.
LDAP_QUERY_FILTER_GROUP=(|)
# Specifies how ldap should be asked for aliases.
LDAP_QUERY_FILTER_ALIAS=(|)
# Specifies how ldap should be asked for domains.
LDAP_QUERY_FILTER_DOMAIN=(mail=*@%s)

DOVECOT_TLS=yes
DOVECOT_USER_FILTER=(&(objectclass=person)(sAMAccountName=%n))
DOVECOT_USER_ATTRS==uid=%{ldap:uidNumber},=gid=5000,=home=/var/mail/%Ln,=mail=maildir:~/Maildir
DOVECOT_PASS_ATTRS=sAMAccountName=user,userPassword=password
DOVECOT_AUTH_BIND=yes

ENABLE_SASLAUTHD=1
SASLAUTHD_MECHANISMS=ldap
SASLAUTHD_LDAP_SERVER=dc1.internal.MYDOMAIN.com
SASLAUTHD_LDAP_BIND_DN=cn=Administrator,cn=users,dc=internal,dc=MYDOMAIN,dc=com
SASLAUTHD_LDAP_SEARCH_BASE=dc=internal,dc=MYDOMAIN,dc=com
SASLAUTHD_LDAP_FILTER=(&(sAMAccountName=%U)(objectClass=person))
SASLAUTHD_LDAP_START_TLS=yes
SASLAUTHD_LDAP_TLS_CHECK_PEER=yes
SASLAUTHD_LDAP_TLS_CACERT_FILE=/etc/ssl/self-signed-pki/pki/ca.crt

Relevant log output

Oct  3 18:17:40 mail postfix/master[2360]: daemon started -- version 3.4.14, configuration /etc/postfix
Oct  3 18:18:01 mail dovecot: imap-login: Login: user=<Administrator>, method=PLAIN, rip=85.127.7.5, lip=10.8.0.4, mpid=2396, TLS, session=<EFvwI3XNVttVfwe/>
Oct  3 18:18:01 mail dovecot: imap(Administrator)<2396><EFvwI3XNVttVfwe/>: Error: chdir(/var/mail/administrator/) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)

Oct  3 18:18:01 mail dovecot: imap(Administrator)<2396><EFvwI3XNVttVfwe/>: Error: stat(/var/mail/administrator/Maildir/tmp) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:18:01 mail dovecot: imap(Administrator)<2396><EFvwI3XNVttVfwe/>: Error: stat(/var/mail/administrator/Maildir/.Sent/tmp) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)

Oct  3 18:18:01 mail dovecot: imap(Administrator)<2396><EFvwI3XNVttVfwe/>: Error: stat(/var/mail/administrator/Maildir) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:18:01 mail dovecot: imap(Administrator)<2396><EFvwI3XNVttVfwe/>: Error: mkdir(/var/mail/administrator/Maildir) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:18:01 mail dovecot: imap(Administrator)<2396><EFvwI3XNVttVfwe/>: Error: stat(/var/mail/administrator/Maildir/.Sent/tmp) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:18:01 mail dovecot: imap(Administrator)<2396><EFvwI3XNVttVfwe/>: Error: stat(/var/mail/administrator/Maildir/tmp) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:19:01 mail dovecot: imap-login: Login: user=<Administrator>, method=PLAIN, rip=85.127.7.5, lip=10.8.0.4, mpid=2428, TLS, session=<QJuCJ3XNndtVfwe/>
Oct  3 18:19:01 mail dovecot: imap(Administrator)<2428><QJuCJ3XNndtVfwe/>: Error: chdir(/var/mail/administrator/) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:19:01 mail dovecot: imap(Administrator)<2428><QJuCJ3XNndtVfwe/>: Error: stat(/var/mail/administrator/Maildir) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:19:01 mail dovecot: imap(Administrator)<2428><QJuCJ3XNndtVfwe/>: Error: mkdir(/var/mail/administrator/Maildir) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:19:01 mail dovecot: imap(Administrator)<2428><QJuCJ3XNndtVfwe/>: Error: stat(/var/mail/administrator/Maildir/tmp) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:19:01 mail dovecot: imap(Administrator)<2428><QJuCJ3XNndtVfwe/>: Error: stat(/var/mail/administrator/Maildir/.Sent/tmp) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:19:01 mail dovecot: imap(Administrator)<2428><QJuCJ3XNndtVfwe/>: Error: mkdir(/var/mail/administrator/Maildir) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:19:01 mail dovecot: imap(Administrator)<2428><QJuCJ3XNndtVfwe/>: Error: stat(/var/mail/administrator/Maildir/.Sent/tmp) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)
Oct  3 18:19:01 mail dovecot: imap(Administrator)<2396><EFvwI3XNVttVfwe/>: Connection closed (SELECT finished 59.933 secs ago) in=129 out=1026 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0
Oct  3 18:19:01 mail dovecot: imap(Administrator)<2428><QJuCJ3XNndtVfwe/>: Error: stat(/var/mail/administrator/Maildir/tmp) failed: Permission denied (euid=10001(<unknown>) egid=5000(docker) missing +x perm: /var/mail/administrator, dir owned by 5000:5000 mode=0700)

Other relevant information

Please do not miss the other information below the docker-compose.

1. Find the **Docker-Compose** file below:

version: '3.9'
services:
  mailserver:
    container_name: mailserver
    image: docker.io/mailserver/docker-mailserver:edge # TODO change the TAG to 10.2.0 when released.
    hostname: mail
    domainname: ${PUBLIC_DOMAIN_NAME}
    # dns: 1.1.1.1
    # To avoid conflicts with yaml base-60 float, DO NOT remove the quotation marks.
    # More information about the mailserver ports:
    # https://docker-mailserver.github.io/docker-mailserver/edge/config/security/understanding-the-ports/
    networks:
      - internal01
    ports:
      - "25:25"
      - "143:143"
      - "587:587"
      - "993:993"
    volumes:
      - mailserver-data:/var/mail/
      - mailserver-state:/var/mail-state/
      - mailserver-logs:/var/log/mail/
      - mailserver-config:/tmp/docker-mailserver/
      - /etc/localtime:/etc/localtime:ro
      - publicly-trusted-pki:/etc/ssl/pki/:ro
    restart: always
    stop_grace_period: 1m
    cap_add: [ "NET_ADMIN", "SYS_PTRACE" ]
    env_file:
      - mailserver/mailserver.env
    environment:
      # The following variables will be passed from the .env (if exist) to override the variables in mailserver.env.
      - DMS_DEBUG
      - POSTMASTER_ADDRESS
      - SSL_TYPE
      - SSL_CERT_PATH
      - SSL_KEY_PATH
      - ENABLE_LDAP
      - LDAP_START_TLS
      - LDAP_SERVER_HOST
      - LDAP_SEARCH_BASE
      - LDAP_BIND_DN
      - LDAP_BIND_PW
      - LDAP_QUERY_FILTER_USER
      - LDAP_QUERY_FILTER_GROUP
      - LDAP_QUERY_FILTER_ALIAS
      - LDAP_QUERY_FILTER_DOMAIN
      - DOVECOT_TLS
      - DOVECOT_USER_FILTER
      - DOVECOT_USER_ATTRS
      - DOVECOT_PASS_ATTRS
      - DOVECOT_AUTH_BIND
      - ENABLE_SASLAUTHD
      - SASLAUTHD_MECHANISMS
      - SASLAUTHD_LDAP_SERVER
      - SASLAUTHD_LDAP_BIND_DN
      - SASLAUTHD_LDAP_SEARCH_BASE
      - SASLAUTHD_LDAP_FILTER
      - SASLAUTHD_LDAP_START_TLS
      - SASLAUTHD_LDAP_TLS_CHECK_PEER
      - SASLAUTHD_LDAP_TLS_CACERT_FILE


volumes:
  mailserver-data:
  mailserver-state:
  mailserver-logs:
  mailserver-config:

internal01 network and the volume of the public key are defined in another docker-compose.yml file. But this should not be an issue.

Make sure the container does not validate the CA in the ldap.conf file, as is seems that there is an issue here (the certificate seems to be refused even if it is valid). In simple words, execute the following on the host and this will do the job:

docker exec mailserver sh -c 'echo "TLS_REQCERT   never" > /etc/ldap/ldap.conf'

Then of course restart the container.

Just to let you know: the related info in my active directory for the user Administrator looks like this: uidNumber: 10001 mail=administrator@MYDOMAIN.com

The output of ls -lan shows:

root@mail:/var/mail# ls -lan
total 16
drwxrwsr-x 3 5000 5000 4096 Oct  3 19:23 .
drwxr-xr-x 1    0    0 4096 Oct  3 19:22 ..
drwx--S--- 3 5000 5000 4096 Oct  3 19:23 administrator

What level of experience do you have with Docker and mail servers?

Trust me, I’m a (computer) engineer! [expert]

Code of conduct

Improvements to this form?

No response

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 1
  • Comments: 40 (36 by maintainers)

Most upvoted comments

I am limited with my linux knowledge

  • The issue AFAIK is related to proper Linux file/dir permissions management of /var/mail, which mounting your own volume to strips away.
  • We shouldn’t need to enforce recursively deep static change, that can be deferred to a setup ... CLI helper.
  • I have a modern issue for tracking / discussing a way forward (that you’ve already chimed in) here: https://github.com/docker-mailserver/docker-mailserver/issues/3557#issuecomment-1741708401
  • I will get around to it when I can, I only have so much volunteer time available and I try to balance that (sometimes it’s biased to effort required / priorities).
    • Presently I actively participate in triage / troubleshooting on DMS and PR reviews.
    • My current DMS task is to rewrite documentation for the LDAP refactoring I’ve been doing, and this is a very tedious task that I also set a high bar for myself to write well for users. As such I do get bored of it and go on detours elsewhere, documentation tasks slow my contributions down quite a bit.
    • Once that’s resolved I have some stale PRs to revive, and after that I will wrap up the test suite revision.
    • The issue here itself is researched and understood fairly well, I’d just like more confidence from tests before bundling it with all the other bigger changes in v13. In the meantime, feel free to share confirmation on what changes work for you.

Thanks for the replies guys, and I realize I came across rudely so I apologize for that. I did some more research and I think my issue might be because I am running DMS on a synology NAS and using the synology LDAP server. I did a complete wipe of the data files and rebuilt the container and volumes and the error stopped appearing. I don’t know if that means its fixed forever, but I did see this is a known issue with synology DSM. I am limited with my linux knowledge, I am more a powershell guy than bash but I will check out the unit test you posted.

@andrew-techwellington we have lots of people complaining about this; what we need though, are people forking, adjusting and merging new code. This may sound harsh, but @MohammedNoureldin is correct in pointing out that we have a PR, but we need more help. That’s how FOSS works…

LDAP is not going away anytime soon. @polarathene has been continuously pushing out PRs to improve our LDAP code.

@MohammedNoureldin so executing

chown -R 10001:10001 /var/mail/administrator

should do the trick in this case, right?


I can image doing the following: Default permission level is drwxr-xr-x (755). Running

find /var/mail/ -maxdepth 1 -type d -not -iname "*\.*" -exec chmod -R 755 {} \;

which should set the correct permissions for all directories that do not follow our naming convention (i.e. LDAP directories). @MohammedNoureldin can you try that?

UPDATE: Just notices that

https://github.com/docker-mailserver/docker-mailserver/blob/cd7677b6f020099a85ae35739cdd7a485491bc92/target/scripts/check-for-changes.sh#L217-L220

will create some problems too and should be ā€œfixedā€ accordingly.


In addition, why does /var/mail and /var/mail-state have 777 permissions? Can someone tell me @docker-mailserver/maintainers? This seems too open to me and not needed. Shouldn’t 755 suffice too?

Hi @Encephala

Do mean the solution I proposed? I fixed it as shown. However, I did not have enough time to check the unit tests. That is why my PR did not get merged. Do you have time to fix them? It would be great if we can fix it together.

I would not put this on low priority. This corrupts the whole permissions for LDAP users, which is really a bad thing. So if not high, this is at least a medium priority issue, IMHO.

This is an issue that has been around since the initial release of the image. Either we don’t have that many LDAP users, or many of them aren’t affected by it in a way that matters to them as the interest in seeing this issue addressed appears to be low (unless we have silent watchers that don’t chime in or add a šŸ‘ to the issue.

I understand it’s a problem, but for me and perhaps other contributors that don’t use LDAP, it’s lower priority than other tasks to allocate our time towards. Especially since it requires setting up a reproduction LDAP environment and understanding LDAP config a bit to investigate and resolve.

Thus it’s more likely to be resolved sooner by someone who is motivated to fix it, such as an actual LDAP user who may consider it a higher priority.


Regarding the PR, I had contributed a commit with a fix or partial fix IIRC, but that code has been shifted since the v10.3.0 release, so the change needs to be re-applied to the new helper script location where both setup-stack.sh and check-for-changes.sh now share the same ownership change line.

I have good experience with LDAP, for me the Docs of LDAP are fine

I would like the docs to use an example for the FQDN example.com, we normalized most pages to use that FQDN in this PR.

  • LDAP Authentication page - Uses ldap.example.org and example.org? Should be ldap.example.com and example.com? Unclear if hostname: mail conflicts with that, if so, ldap.example.org should be mail.example.com instead (as in if ldap part should match hostname: mail).
  • [Forward-Only Mail-Server with LDAP] page - Likewise, same concern with example.org FQDN/domain (which has some instances that the value is split with dc=) and other cases of ldap beyond ldap.example.org, and if cn=mailserver has anything to do with hostname/FQDN/domain//etc/hosts or network in general.
  • The Environment docs page LDAP section - There is usage such as mail.example.com, dc=domain,dc=com, dc=mydomain,dc=local, mail (a bit vague if it’s about hostname: mail or something else).

It would be great if those could be made consistent across all 3 examples, at least for the FQDN values used to align with our mail.example.com placeholder usage.


For me this makes totally sense that every user has only permissions on his own folder. Using a hard coded value in LDAP config to use uid=5000 is not the optimal solution I would say, IMHO.

Thanks for opening the PR, I looked into that and don’t see any major concerns approving it.

@polarathene I have good experience with LDAP, for me the Docs of LDAP are fine (I will make another review on them in the next few days and adapt them if needed).

I am pretty sure here that the solution is just to not change the permissions recursively. For me this makes totally sense that every user has only permissions on his own folder. Using a hard coded value in LDAP config to use uid=5000 is not the optimal solution I would say, IMHO.

Hi @polarathene,

the 10000 is just the ID of one specific user (so it is just an example), every user in LDAP directory will have a different ID, 10001, 10002, etc. That is to say, the owner must never be changed inside /var/mail.

I created a pull request https://github.com/docker-mailserver/docker-mailserver/pull/2256, hopefully changing the owners recursively was not intended.

I really didn’t use it myself, so my experience is rather limited 😃 Usually, I’ve only ever seen this variable being used in more complicated setups, and if you haven’t thought about networking because your setup may require it, you are most likely not in the need to use the variable:) Basically, best try to avoid it if you don’t need it šŸ˜„

Please stop investigating this issue in the meanwhile, I am not sure how and why, but the error is not reproduceable for me at the moment. Let us keep this issue open for the next few days until I know why the issue does not happen anymore (of course even after removing and recreating the container and cleaning the dependent volumes). I need to check what I changed in my docker-compose file.

Anyway, even before the error being not reproduceable anymore, I can confirm that the correct permissions for the mail folder should be 2770 at least (at the moment it is 2775, which should not harm). The owner at the moment is 5000:5000 which is totally fine.

Can I just ask ask a side-question, what PERMIT_DOCKER exactly does? In case of LDAP server (don’t know if LDAP can change it), what value should it take? Somehow I don’t understand its documentation and what it exactly does. I just did not want to open a new issue as a question for this, but if you think it is needed, I will. Thank you!

Tomorrow (technically it is today, it is 2:36 am) I will have a limited access to my computer, so I will be slower in testing.

We’re potentially missing fine-grained permission here. I will have a look later.

This issue should however not affect the release of v10.2.0 as it is most likely not a regression.