Solved Unable to connect to Ubuntu Linux hosted NFS share from FreeBSD VM guest

I have a NFS share exported from a Ubuntu Linux system, with the /exports looking as follows:
Code:
/nfs/directory 192.168.21.239(rw,sync,no_subtree_check)
then confirm the export is being shared with showmount -e 192.168.21.2 from the FreeBSD VM guest and finally try to mount with mount -vvv -t nfs 192.168.21.2:/nfs/directory /mnt I get the error:
Code:
[tcp] 192.168.21.2:/nfs/directory: RPCPROG_NFS: RPC: Remote system error - Connection refused
I have confirmed from an Ubuntu Linux guest, which configured to have the same IP, that the shares are in fact working.
 
Note that NFSv3 uses RPC (port 111) to have the server create a random connection back to the client. It's similar to active FTP creating a random data connection on port 20. NFSv4 is much easier, it only uses port 2049 to connect to the server, there is no randomized connection going back to the client. It also doesn't require RPC (rpcbind(8)) on port 111.
 
Note that NFSv3 uses RPC (port 111) to have the server create a random connection back to the client. It's similar to active FTP creating a random data connection on port 20. NFSv4 is much easier, it only uses port 2049 to connect to the server, there is no randomized connection going back to the client. It also doesn't require RPC (rpcbind(8)) on port 111.
For what I know Ubuntu Linux by default makes a NFSv3 and NFSv4 share by default as my configuration is now.
Thus I tried mount NFSv4 like in https://www.server-world.info/en/note?os=FreeBSD_14&p=nfs&f=2 but got the exact same error.
 
Connection refused typically means there's nothing running on that port. It received a RST after sending the SYN packet. If it's a firewall you often get a time-out, i.e. no response at all because the firewall dropped the packet. Double check to see if you have the correct IP address, I've done this in the past too, accidentally tried to connect to the host's IP instead of a VM or the jail (which ran on a different IP address).

And the primary tool to diagnose network related issues is tcpdump(1). It helps immensely to see the actual packets going back and forth.
 
Connection refused typically means there's nothing running on that port. It received a RST after sending the SYN packet. If it's a firewall you often get a time-out, i.e. no response at all because the firewall dropped the packet. Double check to see if you have the correct IP address, I've done this in the past too, accidentally tried to connect to the host's IP instead of a VM or the jail (which ran on a different IP address).

And the primary tool to diagnose network related issues is tcpdump(1). It helps immensely to see the actual packets going back and forth.
Right, NFSv4 working fine after correcting the IP address of the host in the command.
Thanks.
 
Back
Top