Alright, another one. Getting show-stopping stale file handles.

 

Situation:

As soon as the mover activates, I am no longer able to browse to the mount point in my shell, nor access any files within.

 

Facts:

1. Server is Unraid v7.0.1. Also experience the same behaviour on v7.0.0.
2. Client is Fedora Linux 41 (Server Edition) fully up to date as of 26 Feb 2025.
3. I have followed @dlandon's best practices for NFS in Unraid and continue to experience the issue.
4. SMB is disabled entirely within Unraid
5. Storage is:
   1. 1x Cache SSD (4TB) in a pool of 1 disk formatted as btrfs
   2. 1x Parity 18TB HDD
   3. 3x Data HDDs (various sizes)
   4. Mover is configured to move from Cache to Array
6. Hard Links are essential to my workflow.
7. SSD cache is very strongly preferred for my workflow.
8. I have tried adjusting the fuse_remember tunable to be either 330, 0, or -1 all with no impact.

 

Output & Diagnostics:

The following output comes from the client after the issue begins occurring:

$ ls /mnt/array
ls: cannot open directory '/mnt/array': Stale file handle

$ cat /etc/fstab | grep /mnt/array
192.168.31.3:/mnt/user/array              /mnt/array              nfs     _netdev,hard,relatime,rsize=1048576,wsize=1048576        0 0

$ mount -v | grep /mnt/array
192.168.31.3:/mnt/user/array on /mnt/array type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.31.4,local_lock=none,addr=192.168.31.3,_netdev)

$ journalctl -xe
Feb 26 18:23:02 host.exmaple.com kernel: NFS: server 192.168.31.3 error: fileid changed
                                         fsid 0:40: expected fileid 0x901000000000085, got 0x28000000000101

 

Call for help:

Is there any way to actually make this set up work?

 

Thank you all for your help

unraid-diagnostics-20250226-1834.zip

Why is your eth0 driver "virtio_net"?

Settings for eth0:
	Supported ports: [  ]
	Supported link modes:   Not reported
	Supported pause frame use: No
	Supports auto-negotiation: No
	Supported FEC modes: Not reported
	Advertised link modes:  Not reported
	Advertised pause frame use: No
	Advertised auto-negotiation: No
	Advertised FEC modes: Not reported
	Speed: Unknown!
	Duplex: Unknown! (255)
	Auto-negotiation: off
	Port: Other
	PHYAD: 0
	Transceiver: internal
	Link detected: yes

driver: virtio_net

 

What is your client side mount command?

1 hour ago, dlandon said:

Why is your eth0 driver "virtio_net"?

Looks like he is virtualizing Unraid.

8 minutes ago, JorgeB said:

Looks like he is virtualizing Unraid.

Yes.  That's what I am seeing.

5 hours ago, dlandon said:

What is your client side mount command?

I’m letting them mount via fstab on boot / with mount command. The line is shared above.

3 hours ago, dlandon said:

Yes.  That's what I am seeing.

Yes that’s a key detail too. Unraid is running on Proxmox with the CPU’s SATA controller being passed through.

On 2/26/2025 at 1:47 PM, adrian.mace.au said:

Yes that’s a key detail too. Unraid is running on Proxmox with the CPU’s SATA controller being passed through.

It's difficult for us to help since LT does not support virtualizing Unraid.

10 hours ago, dlandon said:

It's difficult for us to help since LT does not support virtualizing Unraid.

 

Do you have a reason to believe this issue being caused by the virtualisation of Unraid?

7 minutes ago, adrian.mace.au said:

 

Do you have a reason to believe this issue being caused by the virtualisation of Unraid?

Not necessarily, but if you follow the best practices, you should not be experiencing the stale file handles.  There may be other users here with Proxmox experience that might be able to offer some suggestions.

To "circle back", this issue is still happening with 7.1.0-rc1 and Fedora Server 41 updated to 13 Apr 2025.

Using the mover with NFS shares can always result in stale file handler, this is because NFS doesn't look for the files by path, it just remembers the inode, and if a file that is being shared with NFS was on a pool initially and then moved to the array, the inode will change, and you can get the stale file handle error.

 

For best results with NFS, I would recommend using an array only share, if that doesn't have good performance for your use case, then you could use it with a zfs raidz pool for example.

On 4/13/2025 at 8:29 PM, JorgeB said:

Using the mover with NFS shares can always result in stale file handler, this is because NFS doesn't look for the files by path, it just remembers the inode, and if a file that is being shared with NFS was on a pool initially and then moved to the array, the inode will change, and you can get the stale file handle error.

 

For best results with NFS, I would recommend using an array only share, if that doesn't have good performance for your use case, then you could use it with a zfs raidz pool for example.

Hi Jorge,

What exactly would be best practice in this situation then? Use SMB?

The cache obviously speeds things up dramatically. Is there a best of both worlds solution?

Thanks in advance for your advice.

2 hours ago, trus0und said:

Use SMB?

If that's a possibility it would be my recommendation.