I have a nfs share which I can mount without issues but docker doesn't want a bar of it :/
If I don't include the nfs volumes it installs fine.
I've tried with the permissions on the nfs share set to "chmod 777" and "chown nobody:nobody".
I can connect to it from my mac and write to the nfs share.
> docker volume create --driver local \
--opt type=nfs4 \
--opt o=addr=192.168.1.48,rw \
--opt device=:/mnt/tank/virtualisation/database \
database
> docker volume inspect database
[
{
"CreatedAt": "2019-05-14T17:14:54+10:00",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/database/_data",
"Name": "database",
"Options": {
"device": ":/mnt/tank/virtualisation/database",
"o": "addr=192.168.1.48,rw",
"type": "nfs4"
},
"Scope": "local"
}
]
> docker run --name mysql -v database:/var/lib/mysql -v database:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=root -d percona:ps-8
docker: Error response from daemon: failed to copy file info for /var/lib/docker/volumes/database/_data: failed to chown /var/li
b/docker/volumes/database/_data: lchown /var/lib/docker/volumes/database/_data: operation not permitted.
System details.
Server (FreeNAS)
> showmount -e 192.168.1.48
Exports list on 192.168.1.48:
/mnt/tank/virtualisation/database Everyone
Debian 9.9 VM with docker
> docker version
Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:36:00 2019
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 01:59:36 2019
OS/Arch: linux/amd64
Experimental: false
I faced the same problem with a NFS share i need to mount as volume in an nginx container.
In my case adding no_root_squash as option for the NFS share solved the problem: this option causes root user/group of NFS client to be mapped to root user/group of the NFS server, as you can read e.g. here.
So, finally my /etc/exports looks like this:
/tank/honey-files 172.29.6.0/16(rw,sync,no_subtree_check,no_root_squash)
and I can mount it into a container creating a volume
docker volume create honey-files --driver local --opt type=nfs --opt o=addr=172.29.6.200 --opt device=:/tank/honey-files
and using it with docker run / docker service create:
docker run --name nginx --rm -v honey-files:/usr/share/nginx/html -p 30001:80 nginx:latest
docker service create --name nginx -p 30002:80 --mount 'src=honey-files,target=/usr/share/nginx/html' nginx:latest
The question is very old, but... I hope this answer can help you!
We had a similar issue with a volume mounted via NFS.
no_root_squash seems to do the trick (so, thanks for the suggestion above to Pietro Martinelli!), but there's definitely valid reasons from a security perspective not to do that.
We were able to circumvent this problem by adding the nocopy option to the volume mount, such as -v volume_name:/foo/bar:nocopy
This will, as the option suggests, avoid the Docker initialization (i.e. if there’s files at the volume location within the image, they will not be copied), but for the mentioned use case (and ours) this is a non-issue.
More background and other options can also be found here:
The problem only seems to happen if the NFS volume is entirely empty, so another workaround would be to simply create a dummy file on the volume.