- Solved
- Minor
It's been well documented that NFS v3 and UnRaid never play nicely and throw Stale File Handle errors when the mover initiates with cache:yes/prefer selected. On 6.11.x this was relatively trivial to remedy by manually forcing vers=4.2 on the client side. With 6.12-rc2 this doesn't seem to be enough anymore. I've noticed that when the mover initiates (similar to pre 6.12 w/ NFS vers=3) the nfs client throws a stale file handle error which requires unmounting and remounting of the export. Is there a mount option or export option I'm missing to prevent these from occuring or is this the same issue just being exposed now in 6.12-rc2?
"backups" share NFS settings
10.253.0.2(rw,no_root_squash)
systemd Mount on Remote Box
[Unit]
Description=Mount NFS Share
DefaultDependencies=no
Conflicts=umount.target
After=systemd-networkd-wait-online.service
Wants=systemd-networkd-wait-online.service
Before=umount.target
[Mount]
What=10.253.0.1:/mnt/user/backups
Where=/nfs/backups
Type=nfs
Options=vers=4.2,rsize=1048576,wsize=1048576
[Install]
WantedBy=multi-user.target
As a stop-gap I'm running a systemd timer on the remote box to exec this shell script every 30s.
#!/bin/bash
for directory in $(df 2>&1 | grep '10.253.0' | awk '{print ""$6"" }' | tr -d \:)
do
status=`stat $directory 2>&1 | grep -i "stale"`
if [ "${status}" != "" ]; then
folder=$(echo "$directory" | rev | cut -d"/" -f1 | rev)
umount -l "$directory"
systemctl start nfs-$folder.mount
/root/discord_notify.sh "SFH Detected" "The mount point $folder experienced a stale file handle and was remounted"
fi
done
-
1
