NFS access in VM


I have a nfs server in a Raspberry Pi4 streaming media to my laptops - that’s ok.

I needed to get that same nfs access to a qemu/kvm VM running tumbleweed on a host that can access it. However, I can’t get it to work in the VM. My host and nfs server are in the network while the VM on the host is in the network.

My nfs server settings are -

rpi4:~ # cat /etc/exports
# See the exports(5) manpage for a description of the syntax of this file.
# This file contains a list of all directories that are to be exported to 
# other computers via NFS (Network File System).
# This file used by rpc.nfsd and rpc.mountd. See their manpages for details
# on how make changes in this file effective.
/export/Media/4TB    *(ro,root_squash,sync,no_subtree_check)

I use autofs to mount the nfs files -

chris@localhost:/nfs/music2> cat /etc/auto.nfs 
/nfs/music2 -ro,soft,sync,fstype=nfs4

And I can see them via the showmount command -

chris@localhost:/nfs> sudo showmount -e
[sudo] password for root: 
Export list for
/export/Media/4TB *

Trouble is I can’t get access. The VM’s folder gets ‘weird’ with lots of ‘?’.

chris@localhost:/nfs> ls -al
ls: cannot access 'music2': No such file or directory
total 0
drwxr-xr-x 1 root  root   22 Sep  8 15:07 .
drwxr-xr-x 1 root  root  148 Sep  6 09:56 ..
drwxr-xr-x 1 chris users   0 Sep  7 14:02 Music
d????????? ? ?     ?       ?            ? music2

I read that I needed to change the ‘root_squash’ in the nfs server exports file to ‘no_root_squash’ but that didn’t help.

Anyone see where I’m going wrong? Can VMs access nfs shares?


Show full output as root on your NFS client of

mount -v /mnt

Pick ant suitable unused directory as mount point.

localhost:~ # mount -v /mnt/Music
mount.nfs: timeout set for Fri Sep  9 12:43:08 2022
mount.nfs: trying text-based options 'vers=4.2,addr=,clientaddr='
mount.nfs: mount(2): Operation not permitted
mount.nfs: trying text-based options 'addr='
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying prog 100005 vers 3 prot UDP port 20048
mount.nfs: mount(2): Permission denied
mount.nfs: Operation not permitted
localhost:~ #

Is the network in your VM bridge or NAT?

I think NAT, so switch to bridge.

It was NAT but I changed to bridge network and it works now, VM is now in the network.

Odd, I would have thought specifying * in the /etc/exports file on the nfs server would have allowed the network. No matter, I have what I need.


I guess it is allowing, but the request never arrives because there is no route between both networks.

I always thought that since the host and guest VM use the same NIC all NAT traffic would just pass through without needing routing.

But then networking has always been my Achilles Heel :slight_smile:

And I do not know much about VM, but when you have two different networks there must be a route from one to the other (and v.v.). I only pointed you to this because you seemed to concentrate on one possible cause of the problem only, thus ignoring the possibility that it is somewhere else. Very human, but one of the benefits of a forum like this is that it can offer you fresh insights from people not focused to one path to a solution.

If you read the original post, you will see that connectivity was present:

The problem here was NAT on VM host server. By default NFS server will reject connections from “insecure” ports (less than 1024). But NAT by default is using these insecure ports when mapping client address/port. So to NFS server these requests appear to come from insecure ports and are rejected. You will see exactly the same failure when trying from client in the same LAN

mount -o noresvport ...

To allow mount in this case just add “insecure” option to /etc/exports.

Of course NFSv4 has additional issues. The “clientaddr” mentioned in verbose output is used by NFS server to contact NFS client to break lease. This will not work unless there is reverse port mapping on NAT gateway and client is set to use known fixed port. This does not matter for single client, but may cause data corruption in case of multiple clients.