1

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.

1

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.

1

I know this question is a bit old, but I think it's still relevant. Setting up NFS mounts can be tricky because it consists of several components, so there's more than one port that must be opened in the firewall. Also, Fedora uses firewalld, so there's no service called "iptables".

I'm assuming you have your exports defined correctly on the NFS server (TLDP documentation), which is another Fedora box. Don't forget to run exportfs -ra after editing /etc/exports. It might as well be your vm host running VirtualBox (to set up a file share between the host and the guest without having to install and maintain the guest additions package), it doesn't make a difference.

Trying to mount an NFS share on your "client", you might encounter a timeout:

# mount -v Share/
mount.nfs: timeout set for Tue May 22 15:40:52 2018
mount.nfs: trying text-based options 'vers=3,addr=192.168.56.1'
mount.nfs: prog 100003, trying vers=3, prot=6
^C

RPC needs to work (must be able to communicate) for NFS to work. In this case, it can't connect to the NFS server (192.168.56.1 is a default ip address of the VirtualBox host system, replace it with the ip of your NFS server):

# rpcinfo -p 192.168.56.1
rpcinfo: can't contact portmapper: RPC: Remote system error - No route to host

To stop the firewall from blocking NFS on the server (vm host or separate server), you should not disable it, effectively allowing everything. You need to identify the network interface through which the client connects. If it's not assigned to a firewall zone, pick one that's appropriate (probably not "public"). Then allow NFS in that zone.

Identify the network interface (the following commands are to be run on the server):

# ip address
...
6: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.1/24 brd 192.168.56.255 scope global vboxnet0
       valid_lft forever preferred_lft forever

In this example, the client connects to 192.168.56.1, so vboxnet0 is the correct interface on that host.

Identify the firewall zone this interface is assigned to.

# firewall-cmd --get-zone-of-interface vboxnet0

If that's "no zone", you'll need to pick one and assign it yourself. For example "internal", to make it obvious that NFS should not be allowed on external interfaces.

# firewall-cmd --add-interface=vboxnet0 --zone=internal

If you now list all the interfaces in the "internal" zone, "vboxnet0" should show up:

# firewall-cmd --list-interfaces --zone=internal
vboxnet0

Enable those "services" (i.e., open the ports) that are required by the NFS server.

# firewall-cmd --add-service nfs --zone internal
# firewall-cmd --add-service mountd  --zone internal
# firewall-cmd --add-service rpc-bind --zone internal

Double-check that those services are enabled for nics in the "internal" zone:

# firewall-cmd --list-services --zone internal
ssh mdns samba-client dhcpv6-client nfs ntp mountd rpc-bind

If this firewall on the server was blocking NFS, it should work now. Or maybe it doesn't because you have another firewall in the network. However, this is about Fedora and its firewalld.

Last but not least: All of the changes made by the commands listed above are temporary. Only the runtime configuration has been changed (because --permanent has not been used). If you've made a mistake, all your changes will be gone after restarting firewalld.

If you want to keep your changes, you need to save them to the permanent configuration (firewalld documentation):

# firewall-cmd --runtime-to-permanent
0

/etc/exports expects an IP address, optionally followed by a CIDR or old-style netmask.

So you need to change it to one of:

/dvr 192.168.0.0/255.255.0.0(rw)

or:

/dvr 192.168.0.0/16(rw)

(Hostnames can also be used, but that's not relevant here.)

  • thanks for the very fast response. We tried that as well without success. We also tried 255.255.255.0, with no success. After each change to /etc/exports, we did a "service nfs-server restart". Do we have to do anything else? – SomethingBetter Feb 25 '13 at 7:33
  • Just to be clear, it should be "/dvr 192.168.1.0/255.255.255.0(rw)", correct? This would make 192.168.1.0-192.168.1.255 to be available? – SomethingBetter Feb 25 '13 at 7:41
  • If that's the network you want to be accessible, then yes. – Michael Hampton Feb 25 '13 at 7:42
  • Hmm. still no go. Any more ideas? Just noticed that, running rpcinfo -p 192.168.1.110 on the linux machine results in "can't contact portmapper". However, on the linux guest, portmapper service seems to be running. – SomethingBetter Feb 25 '13 at 8:36
  • You have a network or firewall issue, then. – Michael Hampton Feb 25 '13 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.