(Solved) Nfs share inside docker container

Hi there, hope that someone can help me with this issues which cost me a day or two right now.
I am pretty new to docker, but internet is your best friend.
I have proxmox setup with a docker host.
Installed Docker version 24.0.2, build cb74dfc

I have a synology (192.168.2.25) where i created an nfs share (volume1/nfsshare). I want this share to be available inside a docker container. As i found it must be possible. But i cannot seems to get it.

I tried several ways and commandlines, but the all end with:
docker: Error response from daemon: failed to mount local volume: mount :/volume1/nfsshare:/var/lib/docker/volumes/nfsshare/_data, data: addr=192.168.2.250: operation not permitted.

I tried it to setup with this:
docker volume create --driver local
–opt type=nfs
–opt o=addr=192.168.2.250,rw
–opt device=:/volume1/nfsshare
nfsshare

No errors, second i run:
docker run -d -it
–name debian-test
–mount source=nfsshare,target=/mnt
debian

The i get the operation not permitted, inside synology i tried different setups, specific IP of the docker host, wildcard, different squash, they al end with the same error.

So, is my information which i found wrong and is it not possible, or do i something wrong within my setup.
Find several forums, messageboards, al with the same issue, several solutions but these won’t work if i do the same. Did something with guid and uid, but also no luck.

Hope someone here can help and have the solutions, or otherwise i am bold within a couple of days :wink:

The right approach is to use a named volume backed by a nfs remote share.
I run it on DMS7.2 using a configuration like this:

The NFS Fileservice is configured to use NFSv4.1 (on DSM6.2 NFSv4 should be fine as well),

The NFS permissions on the syno share are like this:
Hostname or IP: 192.168.2.0/24 (cidr of the subnet where the docker hosts are)
Privilege: Read/Write
Squash: No mapping
Security: sys
Allow users to access mounted subfolders

This should allow creating a volume that is able to use the remote share

docker volume create --driver local
–opt type=nfs
–opt o=addr=192.168.2.250,nfsvers=4
–opt device=:/volume1/nfsshare
nfsshare

Note: you need to make sure the uid/gid of the share owner (more preferably a subfolder of the share) is aligned with the uid/gid that executes the main application inside a container.

Hi Metin,

Thank you for your reply. My DSM version is 6.2.4 (it’s an old one DS213j). But it has NFS version 4.
I made a new share with your settings. Made the volume. So far, so good.
I checked the ID on the synology.
UID is 1026, GID is 100.

I changed the PGID en PUID inside the ENV in de container run to match. Tried privileged mode and not. But sadly, the same error occurs.

I also checked the etc/exports on the synology and it gave:
/volume1/nfsshare 192.168.2.0/24(rw,sync,no_wdelay,crossmnt,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)
As you can see here is another uid, so i tried this number also in the ENV, but same result.

This is not necessary when a volume is used.

I already shared the configuration I use. In my last post, I left out every checkable option that is unchecked. It works like this since DSM 6.0 without any issues.

Update: my uid:gid is the same and my exports pretty much have the same configuration like yours:

192.168.0.0/24(rw,sync,no_wdelay,crossmnt,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

I could not stand it why it won’t work. I new the synology setup was correct and i don’t think it is inside the docker environment anymore. So after searching and searching i came accross a post that mentioned something about no nfs connection possible if a lxc container is unpriviliged. And guess what my lxc container is…

So i quickly setup an VM with ubuntu server, installed docker, make a volume, add a docker container with this volume. And bamm… it’s connected right away. So i will rebuild the application what i want with use of the nfs share and hope this works.

Kind regards for the replies anyway, it helped me pointing in which direction the issue was.