I have a docker compose file with a bind volume. It basically mounts /media/user/drive/media to the container’s /mnt.
It works as expected when /media/user/drive/ is mounted and its media folder has the files I want the container to see.
However, as it’s a network drive, the container usually tries to start before it is mounted, so it would throw the error that /media/user/drive/media doesn’t exist. So I created an empty folder in /media/user/drive called media while the drive was not mounted so that at least the container starts with the volume /mnt being empty until the network drive gets mounted and all the files appear at /media/user/drive/media.
To my surprise, when the drive gets mounted, even though if I do ls /media/user/drive/media it lists the drive contents correctly, the container still sees /mnt empty.
How would I go about getting the drive files inside the docker container when it automatically starts?
The file handle of the directory changes when you mount the nfs on it, and docker is still looking at the old file handle.
It’d probably work if you mounted nfs to a folder inside that one, or moved your docker mount one level up.
Otherwise you’ll need to get your container to restart after the mount is attached. You could do this with a health check for the container that checks the files are there, and restart the container if they’re not. Or you could just fix your boot order and set nfs as a dependency for docker.
Thanks for your answer. I tried mounting it to a folder inside the one I’m using in the compose file but strangely it didn’t work. So I thought that the only way that wouldn’t need to delay docker start is to restart the container just after the drive has been mounted.
And that’s what I ended up doing as the drive mount is a systemd service and therefore I can use
ExecStartPostto restart the container. That way this doesn’t affect other containers and also lets this one start even if the drive has not been mounted which I want in case there’s no internet connection
How are you mounting the network drive? On my docker machine, network drive mounts are in /etc/fstab. I’ve not had an issue where docker starts before everything is mounted.
I mount it using rclone mount as a systemd service, just as they say in their guide
And is docker running via a systemd service also?
In that case, you can add an
After=line to the docker unit file, telling it to wait until after your mount service is running: https://stackoverflow.com/questions/21830670/start-systemd-service-after-specific-serviceYou can use
systemctl edit dockerto create an override file with this property: https://askubuntu.com/questions/659267/how-do-i-override-or-configure-systemd-services#659268Thanks for your suggestion. That’s what I first thought but there are some issues.
I have other containers that do not require this drive to be mounted. Main problem is that if for some reason the drive cannot be mounted (e.g. no internet connection), then docker would not start any of those containers.
That’s why I need a particular solution. While writing this it has come my mind that I’ve got a container which mounts / as a read-only volume in its /mnt and it seems to work fine there. Maybe if I set the volume to mount /media/user instead of the drive it would work?
Last suggestion: This document suggests that there may be an rclone volume plugin for docker, which could run the mount only when your specific container starts up: https://rclone.org/docker/
Nevermind, what I ended up doing is restarting the container just after the drive has been mounted. Which is easy because it’s a systemd service so I could use
ExecStartPost
If the container is running under a different user then you may have some permission issues.
Don’t think it has to do with permissions as if I manually start the container after the drive gets mounted then everything goes as expected and the container has the files at /mnt
Pop a script on the container to do a whoami and an ls -l on the folder
I managed to solve it by automatically restarting the container once the drive is mounted, as the mount is done by a systemd service. Guess there were no permission issues
