Docker Community Forums

Share and learn in the Docker community.

How to configure Docker container to ignore missing NFS volume?

General Discussions
#1

I have a Docker volume that I have created from an NFS mount to a device which comes on and off the network at regular intervals:

docker volume create --driver local --opt type=nfs --opt o=addr=192.168.2.237,rw,soft,timeo=10,bg --opt device=:/media raspberryPi

In my mount options, I have intentionally specified a soft mount such that if the mount is not available, an error will return to the process running within the container and the application will handle the I/O error.

In theory, my setup works fine IFF the container is started when the NFS mount is present.

[eric@docker1 tmp]$ docker run --rm -it -v raspberryPi:/pi ubuntu bash
root@f8fd958740da:/# ls /pi
lost+found  x  y

If remove the device from the network, the NFS access fails from within the container (as expected):

root@f8fd958740da:/# ls /pi
ls: cannot access '/pi': Stale file handle

If I re-attach the device to the network, then the resource becomes available again, and everything continues to work.

The problem arises, however, if the NFS volume is NOT present at container start time. If it isn’t present, then the container fails to launch altogether:

[eric@docker1 tmp]$ docker run --rm -it -v raspberryPi:/pi ubuntu bash
docker: Error response from daemon: error while mounting volume '/var/lib/docker/volumes/raspberryPi/_data': error while mounting volume with options: type='nfs' device=':/media/movies' o='addr=192.168.2.237,rw,soft,timeo=10': operation not supported.

Is there anyway I can configure docker to “ignore” the volume mount error and continue to mount it none-the-less? I tried using a background mount in the options, but that did not help. Essentially, I would like the container to launch with a mount configured to /pi even though the mount isn’t currently accessible.

Thanks,

Eric

#2

I am not aware that volumes would actualy support that. Normaly you would want a stale or non reachable nfs share to fail your container, and restart it until the nfs share is reachable again.

Though, I remember a thread from years ago, where someone wanted optional mounted volumes.

He ended up mounting the remote share (in your case: 192.168.2.237:/media/movies) to a folder like /mnt/raspberryPi/media

Then use a bind -v /mnt/raspberryPi:/pi:rshared to mount the parent folder of the folder the nfs share is mounted into, and use a mount propagation that allows the container to notice when the share is mounted/unmount.

#3

That’s my fallback as well, but the only problem with that approach is that I don’t think the container will be able to identify if the NFS mount fails. I didn’t test it out yet, but I would expect that if the NFS mount fails, the bind mount would simply allow the container to write to the host’s file system instead.

Thanks,

Eric

#4

The :rshared setting at the and is crucial to “not hide” when a source is mounted/unmounted to a target folder that is a subfolder of the folder used as volume-bind.

The volume-bind used to mount the host folder into the container will have the same behavior, regardless wether inside the container or on the host itself.