Hello,

I am experiencing repeated “Stale file handle” errors when accessing Unraid shares from a Linux client over NFS.

ls: cannot access '/mnt/shared_documents': Stale file handle

Client:

• Kubuntu 24.04

• Kernel 6.14

• NFSv4.2

• Stable network (ping remains normal)

Unraid:

• Shares exported from /mnt/user

• Shares set to Primary Cache -> Secondary Array

• Default disk spin-down: 15 minutes

fstab entry:

10.0.20.100:/mnt/user/shared_documents /mnt/shared_documents nfs rw,_netdev,noatime,nfsvers=4.2,hard,noresvport,timeo=600,retrans=5 0 0

(Behaviour is the same for other shares mounted in the same way.)

Behaviour observed:

• After boot, the share works normally.

• If left idle long enough for the disk to spin down, the next access returns:
  “Stale file handle”

• Ping to the NAS remains normal.

• Remounting the share immediately restores access.

• This occurs even if no files were modified.

• The same behaviour was observed when using SMB instead of NFS.

#//10.0.20.100/shared_documents /mnt/shared_documents cifs username=XXX,password=XXX,vers=3.1.1,uid=1000,gid=1000,file_mode=0664,dir_mode=0775,iocharset=utf8,serverino,users,nofail,_netdev,sec=ntlmssp,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.idle-timeout=600 0 0

It appears the issue occurs specifically after disk spin-down, suggesting file handle invalidation when the underlying disk wakes while exporting via /mnt/user (FUSE layer).

Disabling spin-down appears to prevent the issue. I am also testing mounting the underlying /mnt/diskX path directly.

My aim is to retain spin-down (archival usage) while maintaining a stable mount from Linux.

Is this expected behaviour when exporting /mnt/user via NFS (and SMB) with spin-down enabled? Would mounting /mnt/diskX directly be the recommended approach for Linux clients?

Many thanks for any guidance.

Edited February 23Feb 23 by szim-stack

Stale files hanlçdes with NFS and FUSE is a common issue, especially if used with a pool, though I don't remember hearing of any issues specifically related to spindown.

If you really need NFS, I would recommend using exclusively with array-only shares, or better yet, exclusive shares (these can be with pools only)

I only tried NFS as I was having the same issue with SMB and was hoping NFS would be more stable on linux. I'm happy to switch back to SMB if there is something that could be done there that would allow me to keep the cache -> array setup.

Interestingly this is issue with two of my shares. However;

The smaller share (0.5Gb 87 files 31 subfolder) it happens rarely.

The larger one (320Gb, 6052 files, 1252 subfolders) happens all the time.

Incase this could be causing issues?

My Nas is one VLAN and my computers another. Both VLANs are configured in UniFi as:

• Internal networks

• In the same firewall zone (“Internal” zone)

• Inter-VLAN routing enabled

• No explicit deny rules between them

Then again my macbook via smb inter VLAN has no issues.

Edited February 23Feb 23 by szim-stack

SMB is fine with array + cache; NFS can have issues because it uses the inode.

NFS clients don’t just look up files by path. They remember the inode. So if the file gets moved to a different disk, or Unraid’s mover changes its physical location, the inode changes even if the name stays the same. The NFS client still points to the old inode, which is now invalid, so it results in the “Stale file handle”