I’m investigating a very strange issue I’m having.
I obtain a Let’s encrypt certificate using Caddy, then use it for mosquitto. This work, until it’s time to renew. Caddy fails to renew the certificate because it no longer owns the file!
I’m running Mosquitton in Docker, mounting the certificate directory into the container as /mosquitto/certificates. At first I thought Docker is doing something fishy with mounted directories, but if I use any other image except eclipse-mosquitto then it doesn’t happen.
It would be quite a strange bug, but the only explanation I have at the moment is that Mosquitto itself is somehow messing with file ownership when it starts up. Is that possible?
This behavior of the startup script of the docker container is not a bug, but a feature. The mosquitto executable is performing a so called “privilege drop” and change it’s effective userid to the userid 1883 , if it’s started as root user. This is default behavior of most kind of daemon executables. If you start a docker container by default the internal user inside the container will be root (mapped by the docker containerd to some generic user on the host side).
To ensure the mosquitto is still able to read all it’s config files (and even more able to write his data files) he will change the file owership of the /mosquitto folder containing the config folder (and recursively all sub folders) to the userid 1883 (the mosquitto user).
One way to avoid this change of ownership would be to configure docker to start the container with the userid=1883. This way the startup script would no longer try to modify the ownership. But in this case you have to make sure userid=1883 is able to read the config folder and has write permission on the data folder.
