📝 Preliminary Checks
👀 What Happened?
On my FedoraCoreOS host, SELinux is enabled ("enforcing") by default, and I run into some issues with docker-mailserver on my setup, using named volumes (see config below). Initial startup is good, but when the container is recreated (e.g. docker compose up -d --force-recreate mail) it breaks (see logs below).
I understand this might be out of scope as it concerns SELinux, but would still like to check if this is not somehow an issue with the image, as it only affects 1 of the volumes (mail-state).
Workaround where it doesn't break:
- Disabling SELinux system wide (
sudo setenforce 0)
- Running the container privileged (
privileged: true in compose.yaml)
- Disabling SELinux for the container (
security_opt: - label:disable in compose.yaml)
Interestingly, adding bind option :z or :Z to the mounts (which is the suggested solution in many places) does not help; it looks like it's not used/allowed for named volumes (only bind mounts) which is why compose warns about that in some of its commands.
Other than disabling SELinux I don't have a solution for this. I can see the directories within mail-state are improperly labeled and I also cannot access them using docker exec. However, other volumes like mail-data also get some automatically created dirs, but they are labeled system_u:object_r:container_file_t:s0 and can be accessed without issues:
# ls -Z /var/mail /var/mail-state | cat
/var/mail:
system_u:object_r:container_file_t:s0 example.com
/var/mail-state:
system_u:object_r:container_file_t:s0:c1022,c1023 lib-dovecot
system_u:object_r:container_file_t:s0:c1022,c1023 lib-fail2ban
system_u:object_r:container_file_t:s0:c1022,c1023 lib-logrotate
system_u:object_r:container_file_t:s0:c1022,c1023 lib-postfix
system_u:object_r:container_file_t:s0:c1022,c1023 lib-redis
system_u:object_r:container_file_t:s0:c1022,c1023 lib-rspamd
system_u:object_r:container_file_t:s0:c1022,c1023 spool-postfix
Anything special about the way mail-state is initially provisioned that makes it behave in this way? Any clue why I don't have this issue with the other named volumes?
👟 Reproduction Steps
No response
🐋 DMS Version
v13.3.1
💻 Operating System and Architecture
FedoraCoreOS 39 x86_64
⚙️ Container configuration files
volumes:
# ...
letsencrypt:
name: letsencrypt
mail-data:
name: mail-data
mail-state:
name: mail-state
mail-logs:
name: mail-logs
mail-config:
name: mail-config
services:
# ...
mail:
container_name: mail
image: mailserver/docker-mailserver
hostname: ######
restart: always
cap_add:
- NET_ADMIN
ports:
- '25:25'
- '465:465'
- '587:587'
- '993:993'
volumes:
- mail-data:/var/mail
- mail-state:/var/mail-state
- mail-logs:/var/log/mail
- mail-config:/tmp/docker-mailserver
- letsencrypt:/etc/letsencrypt
environment:
ENABLE_RSPAMD: 1
ENABLE_FAIL2BAN: 1
ENABLE_CLAMAV: 0
ENABLE_OPENDMARC: 0
ENABLE_OPENDKIM: 0
ENABLE_POLICYD_SPF: 0
ENABLE_AMAVIS: 0
ENABLE_SPAMASSASSIN: 0
ENABLE_UPDATE_CHECK: 0
DOVECOT_MAILBOX_FORMAT: mdbox
SSL_TYPE: letsencrypt
SPOOF_PROTECTION: 1
MOVE_SPAM_TO_JUNK: 1
MARK_SPAM_AS_READ: 1
RSPAMD_LEARN: 1
TZ: Europe/Amsterdam
📜 Relevant log output
[ INF ] Welcome to docker-mailserver v13.3.1
[ INF ] Checking configuration
[ INF ] Configuring mail server
chown: cannot read directory '/var/mail-state/lib-rspamd': Permission denied
chown: cannot read directory '/var/mail-state/lib-redis': Permission denied
chown: cannot read directory '/var/mail-state/lib-logrotate': Permission denied
chown: cannot read directory '/var/mail-state/lib-postfix': Permission denied
chown: cannot read directory '/var/mail-state/spool-postfix': Permission denied
chown: changing ownership of '/var/mail-state/spool-postfix': Permission denied
chgrp: cannot access '/var/mail-state/spool-postfix/maildrop': Permission denied
chgrp: cannot access '/var/mail-state/spool-postfix/public': Permission denied
chmod: cannot access '/var/mail-state/spool-postfix/maildrop': Permission denied
chmod: cannot access '/var/mail-state/spool-postfix/public': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/dev': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/etc': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/lib': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/pid': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/usr': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/private/auth': Permission denied
[ INF ] Starting daemons
[ INF ] ###### is up and running
Feb 12 21:36:12 mail postfix[858]: fatal: chdir(/var/spool/postfix): Permission denied
Feb 12 21:36:17 mail postfix[983]: fatal: chdir(/var/spool/postfix): Permission denied
Feb 12 21:36:22 mail postfix[1086]: fatal: chdir(/var/spool/postfix): Permission denied
...
Improvements to this form?
No response
📝 Preliminary Checks
👀 What Happened?
On my FedoraCoreOS host, SELinux is enabled ("enforcing") by default, and I run into some issues with docker-mailserver on my setup, using named volumes (see config below). Initial startup is good, but when the container is recreated (e.g.
docker compose up -d --force-recreate mail) it breaks (see logs below).I understand this might be out of scope as it concerns SELinux, but would still like to check if this is not somehow an issue with the image, as it only affects 1 of the volumes (
mail-state).Workaround where it doesn't break:
sudo setenforce 0)privileged: truein compose.yaml)security_opt: - label:disablein compose.yaml)Interestingly, adding bind option
:zor:Zto the mounts (which is the suggested solution in many places) does not help; it looks like it's not used/allowed for named volumes (only bind mounts) which is why compose warns about that in some of its commands.Other than disabling SELinux I don't have a solution for this. I can see the directories within
mail-stateare improperly labeled and I also cannot access them using docker exec. However, other volumes likemail-dataalso get some automatically created dirs, but they are labeledsystem_u:object_r:container_file_t:s0and can be accessed without issues:# ls -Z /var/mail /var/mail-state | cat /var/mail: system_u:object_r:container_file_t:s0 example.com /var/mail-state: system_u:object_r:container_file_t:s0:c1022,c1023 lib-dovecot system_u:object_r:container_file_t:s0:c1022,c1023 lib-fail2ban system_u:object_r:container_file_t:s0:c1022,c1023 lib-logrotate system_u:object_r:container_file_t:s0:c1022,c1023 lib-postfix system_u:object_r:container_file_t:s0:c1022,c1023 lib-redis system_u:object_r:container_file_t:s0:c1022,c1023 lib-rspamd system_u:object_r:container_file_t:s0:c1022,c1023 spool-postfixAnything special about the way mail-state is initially provisioned that makes it behave in this way? Any clue why I don't have this issue with the other named volumes?
👟 Reproduction Steps
No response
🐋 DMS Version
v13.3.1
💻 Operating System and Architecture
FedoraCoreOS 39 x86_64
⚙️ Container configuration files
📜 Relevant log output
Improvements to this form?
No response