I’ve got my application sources mounted over NFS from a file server in $HOME/app.
When I start a container with
mount nfs-server:/path/to/app $HOME/app
docker run -v $HOME/app:/app myimage
I end up with empty /app inside the container. When I copy the $HOME/app to a local filesystem I can mount it inside the container just fine. Why is that happening? And is there any workaround other than putting the app directly into the image (that’s inconvenient for development).
I have never mounted a NFS fileshare into a container as you did. What I have done was doing the nfs mounting right from within the container. For that to work, I had to provide the " --privileged=true" option to the “docker run” command. I wonder if that will help
This doesn’t really help as then I would need to handle the NFS mounting inside the container, ie have the NFS tools installed, run it when container starts, handle failures, etc. Much better would be the ability to mount a remote filesystem as a volume from outside of the container.
Even something like docker run -v nfs-server:/path-to-app:/app would be good enough.
My 2 questions are:
Why docker doesn’t work with a volume mounted from NFS?
How can I work around it (other then mounting the share from inside the container)? Is this something planned for the new versions?
I’m trying with docker 1.8.3 and I’m seeing the behavior where volumes exposed from host server NFS mounts don’t really work inside the container, which is the artifactory container from JFrog. But, trying with Ubuntu latest yields success.
So, the issue appears depending on the container setup. (But I’m not sure how, yet.)
@tgoeke it seems I have here the same kind of issue with artifactory container using volume being NFS mount on the host. In my case artifactory is really long to startup. Most of the case it did not finish starting up after several days… Did you find a solution ?
I’m currently evaluating Docker and I might be wrong but I surmise this depends on your Docker network configuration. Using the default (docker0) bridge implies masquerading, aka. NAT (from the container point of view). And NFS abhors NAT.
I’m experiencing the same problem with Docker 1.11.1. Restarting the Docker daemon apparently solve the problem, however this workaround does NOT work when the mount and the restarted are applied automatically in a boot cloud-init script (Amazon EC2 instance).
Is this a Docker bug or an expected behaviour? Is there any way to solve this issue?
I believe https://github.com/SvenDowideit/docker-volumes-nfs was an example for writing volume drivers. Does anyone know if there is a generic volume driver for NFS? or is using -v still the only none vendor specific method?