The source user interpreted the failure as “Docker cannot install an image after a clean reinstall,” but the terminal output actually showed two separate issues. Running docker info without elevated access failed on the Docker socket, while running the Mosquitto container with Docker privileges successfully pulled eclipse-mosquitto:latest. The container then failed for a different reason: the bind mount tried to treat a host path and container path as incompatible file/directory types.
This distinction is critical. Reinstalling Debian, CasaOS, or Docker will not fix a bind mount that points at the wrong kind of filesystem object.
Issue 1: The Normal User Could Not Access the Docker Socket
The first docker info output said:
permission denied while trying to connect to the Docker daemon socket
unix:///var/run/docker.sockThat means the shell user did not have permission to talk to the Docker daemon directly. The same command worked with sudo, proving the daemon itself was reachable.
This is separate from the later Mosquitto startup error.
The Mosquitto Image Downloaded Successfully
Docker reported:
Status: Downloaded newer image for eclipse-mosquitto:latestSo the registry, image name, and Internet connection were not the immediate problem. The failure occurred only when Docker attempted to create the container filesystem and apply the bind mount.
The Real Error Was File-versus-Directory Mounting
The command tried to map:
/etc/mosquitto/mosquitto.conf
→ /mosquitto/config/mosquitto.confDocker then reported:
not a directory
Are you trying to mount a directory onto a file (or vice-versa)?That message should be taken literally. One side of the mapping was not the type the command expected.
Why -v Can Create the Wrong Type Automatically
Current Docker documentation explains an easy trap with -v/--volume: if the source path does not exist, Docker creates it automatically as a directory.
So if /etc/mosquitto/mosquitto.conf did not already exist as a real file, Docker could create a directory named mosquitto.conf. Mounting that directory onto the container's expected config file then produces the exact error seen in the source thread.
Use Docker's current bind-mount behavior to verify whether the source is a file or a directory before starting the container.
The Community Switched to Mapping Mosquitto Directories
A responder shared a Compose definition that mapped three persistent directories:
- host config directory →
/mosquitto/config - host data directory →
/mosquitto/data - host log directory →
/mosquitto/log
This avoids the fragile “single file that may not exist yet” mount and gives Mosquitto a normal persistent layout.
The Configuration File Still Has to Exist Inside the Config Directory
Mapping the directory does not create a valid Mosquitto configuration automatically. The responder told the user to place mosquitto.conf into the mapped config directory before starting the broker.
For a new deployment, create the config as a real file first, then mount its parent directory or use Docker's more explicit --mount syntax, which fails instead of silently creating a missing source directory.
CasaOS Custom Install Can Express the Same Layout Without a Raw docker run Command
The community walked the user through importing a Compose definition through CasaOS's custom-application workflow. The user later installed a Mosquitto package from a community app store and reported that it worked immediately.
That outcome confirms the Docker host itself was capable of running Mosquitto; the earlier problem was configuration rather than a failed CasaOS reinstall.
A Running Broker Still Needs MQTT Authentication and Listener Configuration
The source user then asked why Node-RED did not connect and whether Mosquitto would use the terminal username/password automatically. It does not. MQTT authentication is configured by Mosquitto itself through its configuration and password files.
Do not assume a green container status means the broker is ready for unauthenticated clients.
Timezone Was a Final Container-Configuration Detail
After installing a working community package, the user still needed to add the appropriate timezone environment value. That is an application/runtime detail, not evidence of another Docker installation failure.
Mosquitto Docker Error FAQ
Did Docker fail to download eclipse-mosquitto?
No. The source output shows the image was downloaded successfully.
Why did the container fail to start?
The bind mount had a file-versus-directory mismatch around mosquitto.conf.
Why can a missing host file become a directory with docker -v?
Docker's --volume behavior creates a missing host source as a directory, which can break a file-to-file bind mount.
Did reinstalling CasaOS fix the problem?
No. The user ultimately succeeded after using a correct application/container configuration.
