Unable to mount NFS share (from Scale 22.12.3)

[mcmxvi]

Hello world,

I've been pulling my hair out trying to get NFS shares to work on my Scale installation. Here is a brief rundown:

My TrueNAS Scale sits in a virtual machine on my Proxmox server with two ZFS pools (backup-pool, storage-pool). Both pools are passed through an LSI-controller. I'm trying to share a dataset from the storage-pool (/mnt/storage-pool/monitoring).

Without going into a long ramble, I can successfully mount NFS shares from my ParrotOS without any issues. I also tried setting up a dummy NFS share on TrueNAS CORE, which I was able to connect to without problems.

However, I'm completely lost as to why I cannot connect to the NFS share on my Scale server. Here's the situation:

• When I run 'showmount -e' from the client (LXC container on Proxmox) using the IP of my ParrotOS VM or TrueNAS CORE VM, the NFS share is immediately displayed. But when I do the same for my TrueNAS Scale VM, it takes about two minutes before the NFS shares appear.
• Running 'rcpinfo -p' on my ParrotOS and CORE VMs shows the expected result of NFS on port 2049. However, when I try the same for the Scale VM, I receive the message "RPC: Remote system error - Connection timed out."

I've gone through various NFS sharing discussions on the forum, read the TrueNAS website's help documents, and even used ChatGPT for troubleshooting, but to no avail.

If anyone has experienced a similar issue or can provide guidance on where to continue troubleshooting, I would greatly appreciate it. I can also share screenshots and command outputs if needed.

Thank you in advance for any helpful advice! Have a pleasant day!

 

[samarium]

If it is working eventually, then sounds like packet loss or maybe DNS. 2min is a long time.

Use tcpdump on TNS to confirm the packets are arriving and to see the responses leaving and correlate that with what you see on the originating VMs.

Check on all VMs that DNS forward and reverse resolution works for all addresses.

Check the rpcbind status and logs on TNS.

Maybe you mean on TNS that rpcinfo -p times out locally? Which would tend to imply rpcbind not running? I was assuming you were running rpcinfo -p tnsvm from the remotes t check.

If rpcbind isn't operational on TNS, then on the remotes try specifying port 2049 as part of the mount. Doesn't
Look like you have an option for specifying a port to show mount.

You have turned on the nfs server in TNS?

 

[mcmxvi]

If it is working eventually, then sounds like packet loss or maybe DNS. 2min is a long time.

Use tcpdump on TNS to confirm the packets are arriving and to see the responses leaving and correlate that with what you see on the originating VMs.

Check on all VMs that DNS forward and reverse resolution works for all addresses.

Check the rpcbind status and logs on TNS.

Maybe you mean on TNS that rpcinfo -p times out locally? Which would tend to imply rpcbind not running? I was assuming you were running rpcinfo -p tnsvm from the remotes t check.

If rpcbind isn't operational on TNS, then on the remotes try specifying port 2049 as part of the mount. Doesn't
Look like you have an option for specifying a port to show mount.

You have turned on the nfs server in TNS?

Yeah, running showmount -e from the LXC container to TNS eventually works, but it takes about 2 minutes to show the output. Interestingly, when I run showmount -e from my ParrotOS (VM) terminal, the output is instant. Though my LXC container and ParrotOS VM can't mount the NFS share from the TNS VM, they can see the output related to showmount.

I decided to try using TCPdump on TNS to investigate further. Pings are returned successfully, and I can see a few packages related to showmount coming from another client. However, there are no signs of any packages coming through while trying to mount a share from a client.

I checked the messages and syslogs, and after analyzing them with chatGPT, it seems that there are no issues with the NFS server or its services. The services appear to have started up successfully, and there are no error messages indicating any problems with NFS.

It's puzzling that both my TNS and TNC have vanilla installs with minimal customization. The only script I have on my TNS is the one that keeps me logged in, but apart from that, there haven't been any significant changes.

 

[mcmxvi]

So, just to go by the process of elimination, I spun up a new TNS VM and created an NFS share similar to the one I'm trying to connect to on my other TNS. The LXC container connects to it just fine.

I tried to go over most, if not all, the settings, and for the most part, they look identical. I disabled the "keep-alive-login-script" as well, but it made no difference.

I might just do a fresh install. Having a TNS with broken NFS sharing capabilities is not great going forward.

 

[samarium]

Try mount -t nfs4 like parrot did, even though you said -t nfs, it tried vers=4.2

I don't know why truenas is reporting port numbers as two byes in the address, took me a little while to understand that .8.1 is normally :2049

Still don't know why rpcinfo -p is getting lost.

Mount delay might be trying nfs vers=3 via portmapper, then eventually getting to trying vers=4.x directly without portmapper response.