I'm still getting used to Docker and manage my containers through a graphical interface. I'm trying to deploy Maintainerr with this configuration:
services:
maintainerr:
image: ghcr.io/maintainerr/maintainerr:latest
user: 1000:1000
volumes:
- type: bind
source: /mnt/maintainerr
target: /opt/data
environment:
- TZ=Europe/Brussels
ports:
- 6246:6246
restart: unless-stopped
However, the container logs show `mkdir: can't create directory '/opt/data/ui': Permission denied`. I then changed the mount to `/mnt/maintainerr:/data`, which allows the container to start, but no files appear in `/mnt/maintainerr`. After restarting or changing the stack, my settings are gone.
How can I configure the mount correctly so Maintainerr writes its persistent data to the host folder?
3 Answers
This is a bind mount, not an automatically created named volume. Docker is mounting the existing host directory directly into `/opt/data`; it won’t redirect the application to another location just because you choose a different container path. The documented target is the one Maintainerr expects, so keep `/opt/data` and resolve the host-folder ownership problem rather than changing the target to `/data/.
You can also use a named Docker volume if you don’t specifically need the files stored at `/mnt/maintainerr`:
volumes:
maintainerr-data:
services:
maintainerr:
image: ghcr.io/maintainerr/maintainerr:latest
user: 1000:1000
volumes:
- maintainerr-data:/opt/data
That gives Maintainerr persistent storage managed by Docker. If you want to browse or back up the files easily from the host, the bind mount is fine—just ensure `/mnt/maintainerr` is writable by UID 1000.
The container’s internal data path is `/opt/data`, not `/data`. The path on the left is the host folder, while the path on the right is where the application sees it inside the container. Mapping `/mnt/maintainerr:/data` creates a mount that Maintainerr probably never uses, so its real data remains inside the container and disappears when the container is recreated.
Use `/mnt/maintainerr:/opt/data`, then fix the permissions on the host directory. Since the container runs as UID/GID `1000:1000`, the host folder needs to be writable by that user, for example with `chown -R 1000:1000 /mnt/maintainerr` and suitable write permissions. Also make sure the directory exists before starting the stack.
That makes sense. I was treating the target path as another host folder instead of the path used by the application inside the container. I’ll create the directory and assign it to UID/GID 1000.