I've been trying to get NFS to play nice with unRAID for a while, and I'm really not sure where to go from here. All the shares I'm sharing are user shares with `Cache: Yes`.

 

I'm sharing the shares from my unRAID box to 3 Kubernetes nodes, mounted with autoFS. This is a sample output of nfsstat to show it's using the correct version:

/mnt/autofs/media from 192.168.10.120:/mnt/user/media
 Flags: rw,relatime,vers=4.2,rsize=8192,wsize=8192,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.10.171,local_lock=none,addr=192.168.10.120

 

I've also set my `fuse_remember` tunable to -1, which in theory should solve the stale file handle issues, but it doesn't.

 

If I ever add files to this share, once the mover runs, I'm going to experience the stale file handle error on my nodes. Applications (containers) continue to work, but if they're restarted, they'll fail to start with the stale file mount error. As usual, the fix is to unmount and remount, which involves stopping all the applications that are using the share.

 

Is there any advice on possible other fixes? Anything flags I should add to the mount?

Edited October 22, 20232 yr by lp0101

NFSv4 generally solves the stle file handle issue.  Ths stale file handle was much more of an problem with NFSv3.  It almost looks like your mount is NFSv3.  Use the 'mount; commnd and see what version of NFS is being negotiated with Unraid.  The mount command will show the NFS version actually mounted.

 

You should only set a few options and let everything else default.  UD uses these NFS options:

soft,relatime,retrans=4,timeo=300

 

I would try without the 'vers=4.2' and let the mount negotiate the NFS version.  It should negotiate the highest version supported by the Unraid server.

2 hours ago, dlandon said:

NFSv4 generally solves the stle file handle issue.  Ths stale file handle was much more of an problem with NFSv3.  It almost looks like your mount is NFSv3.  Use the 'mount; commnd and see what version of NFS is being negotiated with Unraid.  The mount command will show the NFS version actually mounted.

 

You should only set a few options and let everything else default.  UD uses these NFS options:

soft,relatime,retrans=4,timeo=300

 

I would try without the 'vers=4.2' and let the mount negotiate the NFS version.  It should negotiate the highest version supported by the Unraid server.

Output of `mount -v`:

 

Quote

 mount -v | grep autofs/media
192.168.10.120:/mnt/user/media on /mnt/autofs/media type nfs4 (rw,relatime,vers=4.2,rsize=8192,wsize=8192,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.10.171,local_lock=none,addr=192.168.10.120)

 

Looks like it's NFSv4

 

I've tried as well without setting the flag, same behaviour - this was when mounting with fstab instead of autofs. For completion's sake, this is the autofs config I'm using to mount it:

Quote

media -fstype=nfs4,rw,soft,intr,rsize=8192,wsize=8192 192.168.10.120:/mnt/user/media

 

Edited October 22, 20232 yr by lp0101

At this point you have several options:

• Try turning off 'Tunable (support Hard Links):' in Settings->Global Share Settings.
• Don't use cache on the Unraid share.  The issue comes from the files being moved by the mover.
• Look further into the client.  This is rarely coming up now that NFSv4 has been enabled in Unraid and it may be something with your client.
• Post dignostics for further help.

22 minutes ago, dlandon said:

At this point you have several options:

• Try turning off 'Tunable (support Hard Links):' in Settings->Global Share Settings.
• Don't use cache on the Unraid share.  The issue comes from the files being moved by the mover.
• Look further into the client.  This is rarely coming up now that NFSv4 has been enabled in Unraid and it may be something with your client.
• Post dignostics for further help.

Unfortunately I use hardlinks pretty extensively, so 1 isn't an option.

2 isn't great either, I do frequent 1+gb/s transfers on this share

I don't think it's 3 - I have the same issue across multiple machines with multiple linux OS's. Right now, all 3 are Ubuntu 22.04 machines, but still.

Diagnostics attached.

barad-dur-diagnostics-20231022-1710.zip

Your log is very hard to read because you have mover logging turned on.  I don't see any stale file handles in the Unraid log.  I assume you see them in the client log.

 

My recommendations:

• Turn off mover logging.  It's filling your log making it unreadable.
• Update all your plugins.  Many are out of date.
• Remove NerdPack and install NerdTools.  NerdPack is not compatible with 6.11.
• Update to 6.12.4.
• Post new diagnostics if you see stale file handles.

I ended up solving this finally.

 

The solution was the turn of SMB on the affected shares. It looks like having both SMB and NFS for some reason lead to the errors.

On 2/6/2024 at 1:19 PM, lp0101 said:

I ended up solving this finally.

 

The solution was the turn of SMB on the affected shares. It looks like having both SMB and NFS for some reason lead to the errors.

I'm just coming to bump this and try to add some SEO to the post (and to thank you @lp0101 !!!! You're a life saver!)

 

I'm running Unraid with a remote Plex server.  I was receiving a stale file handle error on my Plex server, and I was unable to read anything from the directories of my unraid shares.

 

I started with nfs using fstab.  I then went to nfs using autofs.  I searched everywhere and tried a few options.  I heard it was the mover.  I heard that disabling hard links was the answer.  But your post here was the key--utilizing both NFS and SMB simultaneously on an unraid share will result in stale file handle errors on your remote server that mounts the share using NFS.  Disabling the SMB will resolve the issue.

Edited March 14, 20242 yr by m0rphl1ng

Take a look at this and verify your NFS Rules on Unraid and the mount parameters on the NFS client are set appropriately: