Unable to connect to nfs share from docker host

[Shivang44]

I'm very new to nfs so I may be doing this wrong, but here is my run command:

docker run \ -e NFS_EXPORT_0='/nfs/share 192.168.1.111(rw,no_subtree_check)' \ -v /home/shivang/share:/nfs/share \ --cap-add SYS_ADMIN \ -p 2049:2049 \ erichough/nfs-server

Essentially, I created a 'share' folder that I want to use as the nfs share. 192.168.1.111 is my local IP. The docker container seems to start up correctly ("READY AND WAITING FOR CONNECTIONS ON PORT 2049")

But attempting to mount the nfs share from my host gives me the error:

mount.nfs: access denied by server while mounting 172.17.0.2:/nfs/share

I tried exec'ing onto the container and pinging my host's ip (192.168.1.111) and it works, so I'm sure that the container can see my host, it just denies it for some reason. Am I configuring this wrong? Any help would be appreciated!

[ehough]

You're close! In Docker's bridge networking, your container will never see the 192.168.0.0/24 address space; instead it will only see addresses in the 172.17.0.0/16 (by default) range. Since your export only allows mounts from 192.168.1.111, the server will essentially never permit a mount.

If you really want to use IP-based authorization, you have two choices. Your first option would be to change the allowed IPs to 172.17.0.0/16 (or event just *). e.g.

docker run                                                         \
   -e NFS_EXPORT_0='/nfs/share 172.17.0.0/16(rw,no_subtree_check)' \
   -v /home/shivang/share:/nfs/share                               \ 
  --cap-add SYS_ADMIN                                              \ 
  -p 2049:2049                                                     \ 
  erichough/nfs-server

The second option would be to use --network host to ditch the bridge network entirely.

IMHO, if user authentication/authorization is a requirement, you should instead activate Kerberos. It's a pain to set up, but it's quite effective once in place.

If you still have trouble mounting, please post the output of mount -v -o nfsvers=4 ... and we should be able to figure it out.

[ehough]

Checking in. Were you able to get things working?

[Shivang44]

Hey thanks for checking in! Your explanation makes sense, but unfortunately we decided to just use the nfs-server-provisioner helm chart that provisions a nfs-server for us in our kubernetes cluster so we don't have to think about it haha. Thanks so much for checking in and responding so quickly! Hopefully your comment above can help somebody else.

[monsterooo]

Hi @ehough .

Does --network host support mac system?

I started a service

docker run                                  \
  -v `pwd`/shared:/shared                   \
  -v `pwd`/exports.txt:/etc/exports:ro      \
  -v /lib/modules:/lib/modules:ro           \
  --cap-add SYS_ADMIN                       \
  --cap-add SYS_MODULE                      \
  --network=host                            \
  -e NFS_LOG_LEVEL=DEBUG                    \
  --name nsf-demo                           \
  erichough/nfs-server

==================================================================
      SETTING UP ...
==================================================================
----> log level set to DEBUG
----> will use 2 rpc.nfsd server thread(s) (1 thread per CPU)
----> /etc/exports is bind-mounted
----> kernel module nfs is loaded
----> kernel module nfsd is loaded
----> setup complete

==================================================================
      STARTING SERVICES ...
==================================================================
----> mounting rpc_pipefs filesystem onto /var/lib/nfs/rpc_pipefs
mount: mount('rpc_pipefs','/var/lib/nfs/rpc_pipefs','rpc_pipefs',0x00008000,'(null)'):0
----> mounting nfsd filesystem onto /proc/fs/nfsd
mount: mount('nfsd','/proc/fs/nfsd','nfsd',0x00008000,'(null)'):0
----> starting rpcbind
----> starting exportfs
exporting *:/shared
----> starting rpc.mountd on port 32767
----> starting rpc.statd on port 32765 (outgoing from port 32766)
----> starting rpc.nfsd on port 2049 with 2 server thread(s)
rpc.nfsd: knfsd is currently down
rpc.nfsd: Writing version string to kernel: -2 +3 +4 +4.1 +4.2
rpc.nfsd: Created AF_INET TCP socket.
rpc.nfsd: Created AF_INET UDP socket.
rpc.nfsd: Created AF_INET6 TCP socket.
rpc.nfsd: Created AF_INET6 UDP socket.
----> all services started normally

==================================================================
      SERVER STARTUP COMPLETE
==================================================================
----> list of enabled NFS protocol versions: 4.2, 4.1, 4, 3
----> list of container exports:
---->   /shared *(rw,sync,wdelay,hide,nocrossmnt,insecure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,no_pnfs,fsid=0,anonuid=65534,anongid=65534,sec=sys,rw,insecure,no_root_squash,no_all_squash)
----> list of container ports that should be exposed:
---->   111 (TCP and UDP)
---->   2049 (TCP and UDP)
---->   32765 (TCP and UDP)
---->   32767 (TCP and UDP)

==================================================================
      READY AND WAITING FOR NFS CLIENT CONNECTIONS
==================================================================
Statd service already running!

But my connection fails on mac system  

showmount -e 192.168.3.39
showmount: Cannot retrieve info from host: 192.168.3.39: RPC failed:: RPC: Unable to send; errno = Bad file descriptor

Thank you for your time

[ehough]

Hello @monsterooo,

Does --network host support mac system?

You should be able to mount from a mac without any trouble. Looks like the reason that the mount failed is that you simply forgot to open up the appropriate ports on the container. Check out step 4 "Expose the server ports" in the README.

If you still having trouble after opening up the ports, please open a new issue and we'll dig a little deeper to figure out what's going on.

[wyujie]

Hi, my host has 2 IPs: 172.17.0.16 and 192.168.0.2 I can mount with: mount -t nfs 172.17.0.16:/shares ./shares But fail with: mount -t nfs 192.168.0.2:/shares. ./shares

I cannot use --net host for some reason, is there any other solution?