eclipse
[Docker] Permission errors when loading passwordfile with bind-mounts (Mosquitto 2.0.21)
Dear Mosquitto team,
First of all, thank you for the excellent and reliable work on Mosquitto over the years. We would like to report an issue we encountered while setting up Mosquitto 2.0.21 inside a Docker container with bind-mounted configuration, data, and log folders.
Problem Summary: When using Mosquitto 2.0.21 inside Docker with volumes: mapped to local host folders (/opt/...), Mosquitto consistently fails to open the passwordfile if strict file permissions are applied (e.g., chmod 600 passwordfile).
This leads to container restart loops and continuous log errors such as:
Error: Unable to open pwfile "/mosquitto/config/passwordfile". Error opening password file "/mosquitto/config/passwordfile".
Only when loosening the permissions to chmod 644 (world-readable) can the container successfully start and load the configuration.
Environment Details:
Host OS: Ubuntu 22.04 LTS
Docker version: 24.0.5
Mosquitto image: eclipse-mosquitto:2
Mounting:
`volumes:
- /opt/domucore/docker/mqtt/config:/mosquitto/config:rw
- /opt/domucore/docker/mqtt/data:/mosquitto/data:rw
- /opt/domucore/docker/mqtt/log:/mosquitto/log:rw `
What we tried: Over three full days of testing, we carefully:
Set correct user ownership to UID:GID 1883:1883 (chown 1883:1883) on all relevant files (passwordfile, mosquitto.db, etc).
Set file permissions to strict security settings (chmod 600).
Verified that inside the container, ownerships and permissions appeared correct.
Adjusted directory permissions carefully (750 for directories, 600 for sensitive files).
Restarted containers cleanly each time (docker compose down and docker compose up -d --force-recreate).
Monitored and analyzed container logs in detail.
Created backups before each step to ensure safe rollback.
Findings:
When passwordfile is chmod 600, Mosquitto inside Docker is unable to open it.
When passwordfile is chmod 644, Mosquitto successfully starts, but warns that the file is too open.
Same pattern for mosquitto.db in /mosquitto/data/.
Chowning files to 1883:1883 inside the bind-mounted folders does not fully solve the access issue.
It seems that Mosquitto inside Docker cannot correctly map UID 1883 from host into the container context.
Hypothesis: We suspect this issue arises because Docker bind-mounts host filesystems directly without guaranteeing correct UID/GID mapping unless explicitly set. Mosquitto expects strict ownership and permission checks that are valid in a "native" installation but not always reliably enforced inside Docker containers with bind-mounts.
Possible Improvements / Suggestions:
Allow an optional, configurable "relaxed permission checking" mode for Docker deployments.
Improve documentation for best-practices when using Mosquitto in bind-mounted Docker setups.
Or, provide a Docker-specific official image variant with adjusted entrypoint scripts that validate permissions differently.
Conclusion: Currently, the only stable way to run Mosquitto in Docker with a bind-mounted configuration is by accepting chmod 644 on sensitive files, which generates warnings but allows operation.
We would highly appreciate your insight into:
Whether this behavior is intentional.
Whether future Mosquitto versions will adapt to Docker bind-mounted environments more flexibly.
Or if a specific recommended solution already exists.
Thank you very much for your attention and all your great work!
Thanks for the report, it's surprising behaviour to me and I'm afraid I've been unable to reproduce it so far. This is what I've done:
Contents of /home/roger/src/mqtt/dockertest/:
total 24
drwxrwxr-x 5 roger roger 4096 Apr 27 22:55 ./
drwxrwxr-x 96 roger roger 4096 Apr 27 22:40 ../
drwx------ 2 1883 1883 4096 Apr 27 22:46 config/
drwxr-xr-x 2 1883 1883 4096 Apr 27 22:40 data/
-rw-rw-r-- 1 roger roger 289 Apr 27 22:44 docker-compose.yml
drwxr-xr-x 2 1883 1883 4096 Apr 27 22:40 log/
docker-compose.yml:
services:
mosquitto:
image: eclipse-mosquitto:2
volumes:
- /home/roger/src/mqtt/dockertest/config:/mosquitto/config:rw
- /home/roger/src/mqtt/dockertest/data:/mosquitto/data:rw
- /home/roger/src/mqtt/dockertest/log:/mosquitto/log:rw
ports:
- 1883:1883
Contents of /home/roger/src/mqtt/dockertest/config/:
total 8
-rw-r--r-- 1 1883 1883 53 Apr 27 22:40 mosquitto.conf
-rw------- 1 1883 1883 119 Apr 27 22:48 pwfile
mosquitto.conf:
listener 1883
password_file /mosquitto/config/pwfile
pwfile (password is roger):
roger:$7$101$/fCo2QtiggmSx/E3$vixs2LrLXe4RCs/CIEGLmJgVfHnG1+MkhyNS02bfKCCp87buNrpA6kBibwY8Zbe2B6DWjIC90F1P57BYqS+kdQ==
I verified that the password file was loaded correctly.
Are there any obvious differences to what you did?
I "just" had a similar problem - apparently privileged:true causes a failure. While my config has existed for years, just recently it failed (maybe related to docker update?)
It seems I have the same problem. Fresh install of the docker image with the corresponding compose.yaml file:
services:
mosquitto:
container_name: mosquitto
image: eclipse-mosquitto:latest
network_mode: host
deploy:
resources:
limits:
memory: 300M #
# Volumes store your data between container upgrades
volumes:
- /volume1/docker/mosquitto/config:/mosquitto/config
- /volume1/docker/mosquitto/data:/mosquitto/data
- /volume1/docker/mosquitto/log:/mosquitto/log
When I have and empty Mosquitto.conf file, the containers starts (but will not work since no listeners are configured. When I fill in the corresponding relevant data within the .conf file I get a permission denied error.
Are there any obvious differences to what you did?
I replicated your setup:
docker logs mosquitto
chown: /mosquitto/config: Permission denied
chown: /mosquitto/data: Operation not permitted
chown: /mosquitto/data: Operation not permitted
chown: /mosquitto/log: Operation not permitted
chown: /mosquitto/log: Operation not permitted
1763019151: Error: Unable to open config file /mosquitto/config/mosquitto.conf.
@ralight Roger can you show us your result of id command, please?
I guess you are running as root while the rest of the world try to run it as regular user.
Thank you
