Nfs – How to mount an NFS share in a VM guest

nfsvirtual-machinesvirtualbox

We have a machine with Win7-x64 installed. On this machine, with VirtualBox, we're running a guest Fedora-x64. We've defined an NFS share on this Fedora instance. Here is the entry in /etc/exports:

/dvr 192.168.0.0/192.168.255.255(rw)

The ip address of the windows machine is, 192.168.1.100, the ip address of the Fedora guest is 192.168.1.110. The networking mode of the VM is set to be bridged networking.

Now, from another linux box, when we ping the Fedora guest (192.168.1.110), we get responses just fine. However, when we try to mount the nfs share, we get a "no route to host" error. The command we use is:

mount -t nfs 192.168.1.110:/dvr /mnt/test

Just to make sure there are no iptables issues, on the fedora guest, we did:

service iptables stop

and re-tried to mount, to no avail.

Any ideas what might be wrong in our setup? All these machines are connected to each other through a hub. A linksys router is configured as a DHCP server, from which all the machines grab an ip address.

Thanks.

Best Answer

Fedora uses firewalld as the firewall these days. Stopping iptables directly is not the correct way to stop the firewall. Try systemctl stop firewalld.service instead.

You have started the NFS service on the Fedora VM haven't you?

You'd do that by running systemctl start nfs.service on the VM.

If you've changed the /etc/exports file since starting the nfsd, then you need to either systemctl restart nfs.service or re-export filesystems with the exportfs -a command.

Related Solutions

Linux – Mount to NFS export of autofs mount shows empty contents

I think you have a cart before the horse problem here in that when you export a file system using NFS it locks on to the source direcotory. You are trying to not even have that source directory available at that time and only put something there via a mount later.

This will not work, because once you give NFS a handle on something to share, it will always share that thing, even if it ends up underneath a layer of mounts.

Let's say you setup a directory with a file 'frog' and export it with nfs:

[server] $ mkdir /mnt/test && touch /mnt/test/frog
[server] $ echo '/mnt/test *(ro)' >> /etc/exports
[server] $ exportfs -a

Then you mount it on a client somewhere, you will see the file frog as expected:

[client] $ mkdir /mnt/test
[client] $ mount -t nfs server:/mnt/test /mnt/test
[client] $ ls $/mnt/test
frog

Now let's say you mount something else on top of that folder on the server:

[server] $ mkdir /mnt/test2 && touch /mnt/test2/fish
[server] $ mount -o bind /mnt/test2 /mnt/test
[server] $ ls /mnt/test
fish

Spiffy. But what is nfs serving up?

[client] $ ls /mnt/test
frog

You can't even get to that file frog on the server because it's got a different thing mounted on top of it, but NFS is serving up that under layer!

To make a long story short, if you want to export your file systems via NFS you will need to have them mounted up properly at the time NFS starts up and exports them and they will need to stick around. Exporting file systems that are themselves mounted using autofs will never work quite right. You will need to permanently mount those ISOs in order to export them via NFS.

NFS client unable to mount shares from otherwise responsive server

I ran out of time to troubleshoot and ended up restarting the services after killing off some other hung mount attempts that the Devs had also fired off.

Restarting portmap and the Debian nfs service got this working again AFTER killing off the stuck client mount attempts. The NFS service restarted the rpc.statd, rpc.idmapd, and rpc.mountd processes.

Stacktraces were no longer being generated for new mount requests after the old mount attempts were killed.

Best Answer

Related Solutions

Linux – Mount to NFS export of autofs mount shows empty contents

NFS client unable to mount shares from otherwise responsive server

Related Topic