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
Recommended Comments
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.