NiLon Posted March 11, 2021 Share Posted March 11, 2021 (edited) EDIT: As of 2023-02-26 few years active use this solution is confidently stable. Not a single stale and no problems encountered. The Issue and cause When SMB share is mounted to Linux you sometimes might encounter mount hanging and you get error stale file handle. Something in terms of: cannot access '/mnt/sharename': Stale file handle This is caused by file being stored into cache and then moved into another disk by the Mover. The file inode changes and client gets confused because of it. I suspect it could also happen when file moves from another disk inside array, but have not confirmed that and it would be fairly rare issue. Solutions gathered (only one required) Disabling the cache or mover are ways to solve this. However not very practical for many people as it takes away a feature. Disabling hardlinks also fix this problem from occuring. However it also disables hardlinks from whole system. Generally this isn't huge problem. Only certain apps require it and still kind of work with it disabled. Change SMB version to 1.0 at client side. This has some problems as well, such as exposing server to security problems coming with the 1.0 version. It also has some performance problems and lack of features compared to v3. Now for PROPER fix. Key is to add noserverino to mount flags. This forces client to generate its own inode codes rather than using server one. So far I have not noticed any problems by doing this. I can not replicate the issue with this method and I have hardlinks enabled (not required) and SMB v1 disabled (not required). How to replicate the issue Create a file to share that has cache enabled (not prefered). Browse into that directory inside the mount using /mnt/user path Enable the mover Witness the stale file handle error Ramblings Also I found many different variations for the full mount flags and here is what I use: //192.168.1.20/sharename /mnt/sharename cifs rw,_netdev,noserverino,uid=MYLOCALUSERNAME,gid=users,credentials=/etc/samba/credentials/MYLOCALUSERNAME,file_mode=0666,dir_mode=0777 0 0 Let's go thru the mount flags. I'm using these knowing that posix extensions are DISABLED. With them enabled, you might want to use different flags, especially about permissions. Feel free to change them as you like, the noserverino is the ONLY required one. rw - This is just in case and it enabled read/write access to mount. Might be default anyway. _netdev - Makes the system consider this as network device and it actually waits for networking to be enabled before mounting. noserverino - Client generated inodes (required for the fix) uid/gid - These are optional. It makes the mount appear as like its owned by certain uid. Inside the server nothing changes. I'm using these because files are owned by the nobody/users and I can't open files. There is also noperm flag etc. you could use. I just find uid and gid most practical. credentials - This is a file containing username and password for the share. This is just so that people can't see my password by reading /etc/fstab. For more reference how to set this up https://wiki.archlinux.org/index.php/samba#Storing_share_passwords file_mode/dir_mode - These are optional. These make files appear in share as 0666 and 0777 permissions, it does not actually change permissions at server side. Without these the file permissions are not "in sync" and appear wrong in the client side. Such as 0755 directory permissions while it is 0777 in server. Posix/Linux/Unix extensions (not related to stale file handle) Problem I have not been able to solve is how to enable Posix/Linux/Unix extensions. When I try to enable the extensions it errors out saying that server does not support them. Inside samba config in unraid there is unix extensions = No. However turning this Yes in many ways did not enable them. Why this matters? Well those extensions enable certain nice features that makes the share appear as proper linux drive. To confirm that unix extensions are not enabled: mount | grep "//" in the flags you see nounix flag. To enable unix extensions manually add unix to flags. However during mount you get an error and reading dmesg shows you that it reports server not supporting unix extensions. NFS For NFS I still have no real solution other than disabling hardlinks. Edited February 26, 2023 by NiLon updated the testing time 2 9 1 Quote Link to comment
Abnorm Posted March 13, 2021 Share Posted March 13, 2021 (edited) Foreword; not relevant to SMB I seem to get this issue now, never had it before. My setup is like this: I have a Debian VM running on my main unraid box, this has rar2fs installed. On this VM I mount my media shares via NFS3 first, then I point rar2fs to those shares which in turn mounts the unrared/fusefs files to seperate folders which in turn is shared via NFS3 to my secondary box. The secondary box mounts these shares with the unassigned devices-plugin with NFS3 which in turn are mapped in the plex docker for my media locations. When doing some troubleshooting I've found that the rar2fs/fusefs stuff works fine, no processes are crashing or whatnot. It seems that the initial NFS3 mount between the main unraid box and the VM goes stale. When that happens the unrared media is not available in plex (naturally). But there are only 2 folders this happens to, they are not the biggest, they're the smallest, which is bizzarre. This has worked perfectly before i upgraded to 6.9/6.9.1, so I wonder what actually has changed here that can be related. Turning of hardlinks did not work, allthough worth mentioning I have not rebooted the servers after disabling this. I will try that tomorrow just to make sure. PS: I've also tried changing allowed open files to an astronomical value without any difference. As this seems to be somewhat relevant to why you get stale file handles. Edited March 13, 2021 by Abnorm typos Quote Link to comment
TristinP Posted May 1, 2021 Share Posted May 1, 2021 How do I go about adding this to my mount options? Quote Link to comment
NiLon Posted May 5, 2021 Author Share Posted May 5, 2021 (edited) On 5/1/2021 at 4:15 AM, TristinP said: How do I go about adding this to my mount options? On 3/11/2021 at 9:10 PM, NiLon said: Also I found many different variations for the full mount flags and here is what I use: //192.168.1.20/sharename /mnt/sharename cifs rw,_netdev,noserverino,uid=MYLOCALUSERNAME,gid=users,credentials=/etc/samba/credentials/MYLOCALUSERNAME,file_mode=0666,dir_mode=0777 0 0 Let's go thru the mount flags. I'm using these knowing that posix extensions are DISABLED. With them enabled, you might want to use different flags, especially about permissions. Feel free to change them as you like, the noserverino is the ONLY required one. rw - This is just in case and it enabled read/write access to mount. Might be default anyway. _netdev - Makes the system consider this as network device and it actually waits for networking to be enabled before mounting. noserverino - Client generated inodes (required for the fix) uid/gid - These are optional. It makes the mount appear as like its owned by certain uid. Inside the server nothing changes. I'm using these because files are owned by the nobody/users and I can't open files. There is also noperm flag etc. you could use. I just find uid and gid most practical. credentials - This is a file containing username and password for the share. This is just so that people can't see my password by reading /etc/fstab. For more reference how to set this up https://wiki.archlinux.org/index.php/samba#Storing_share_passwords file_mode/dir_mode - These are optional. These make files appear in share as 0666 and 0777 permissions, it does not actually change permissions at server side. Without these the file permissions are not "in sync" and appear wrong in the client side. Such as 0755 directory permissions while it is 0777 in server. These are used by fstab in /etc/fstab If you are using some other mounting method then it might be little bit different. Clearly you need to change the IP and sharename etc. Once you have added the config line, you can mount with command: sudo mount -a Edited May 5, 2021 by NiLon Quote Link to comment
rama3124 Posted August 6, 2023 Share Posted August 6, 2023 Sorry, really new to unraid so still don't understand how to add these flags. I'm receiving the stale file handle on my duplicacy container. Do I add the handles to the fstab file in the container or on the unraid server? Quote Link to comment
NiLon Posted August 7, 2023 Author Share Posted August 7, 2023 4 hours ago, rama3124 said: Sorry, really new to unraid so still don't understand how to add these flags. I'm receiving the stale file handle on my duplicacy container. Do I add the handles to the fstab file in the container or on the unraid server? The flags will go client side. We are fixing confused client by telling not to trust server and rather keep their own record. Client being whatever connects into SMB server (-> Unraid). Think it as a compatibility mode for server that is doing very weird thinks with file links. Inside the container would sound correct if it works as SMB client. I'm not sure why local container would use SMB access rather than direct mount. This to me suggests that inside the container might not be the correct answer, but rather the Duplicacy client maybe? More knowledge of the Duplicacy setup would be required. Also do consider Unraid just as a Linux server with fancy front controller. The fix would work equally well on any Linux SMB server or TrueNAS etc. Quote Link to comment
tnthalftime Posted August 20, 2023 Share Posted August 20, 2023 Thank you very much you saved me a lot of headaches 👍 Adding noserverino to my client mount flags worked flawlessly. I haven't had another Stale file handle error since then. Quote Link to comment
ghostserverd Posted October 26, 2023 Share Posted October 26, 2023 Does anyone have thoughts on how to add this to an autofs mount? For instance, I have this line in auto.unraid /share/media_server -fstype=cifs,rw,soft,noserverino,uid=1000,gid=1000,file_mode=0644,dir_mode=0755,credentials=/share/.cifs ://192.168.1.64/media_server and the actual mount lines look like this /etc/auto.unraid on /share/media_server type autofs (rw,relatime,fd=6,pgrp=736,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=28845) //192.168.1.64/media_server on /share/media_server type cifs (rw,relatime,vers=3.1.1,cache=strict,username=<user>,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.1.64,file_mode=0644,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) which seems to be missing the noserverino flag even though it's in the mount definition. Quote Link to comment
Derek_ Posted January 21 Share Posted January 21 (edited) I'm not sure when this issue popped up for me. It's been quite a while. At least 6 months, i'm confident somewhat longer. I was running Arch, and the install was 5 years old - and it was my first long-term Linux distro. I put it down to "i've been mucking around for so long, that maybe i need a clean install". I decided to give Nobara a go, and i changed from AutoFS to systemd for my mounting. At first it seemed ok, but then it started to happen again. It seems to happen when i make numerous changes rapidly, or i copy large files (the file still copied, but i can't navigate to it). Anyway, i've been looking around and it seems this issue happens on lots of different Linux system. But i've never seen a Windows client have this problem - has anyone else? I also had unRAID for a few years before i encountered this. I wonder what's done it. @NiLon As i'm hoping you'll appreciate, i avoid running commands (or changing settings) i don't understand without a little looking around. I can't find much on this `noserverino` option. It looks like you've been using it for about 2 years (3-ish now), so i'll give it a go and will report back. I'm writing here so i don't forget Thank you VERY much for your original post, and your follow-up some 2 years later. Truly appreciated. Wish me luck @ghostserverd I gave up on autofs. I had it set up on Arch and i found it very complicated compared to systemd, and even before i had these issues, i found it a little flaky. Here's some good reading that convinced me to try systemd: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_file_systems/index#proc_using-systemd-automount-to-mount-a-file-system-on-demand-with-etc-fstab_mounting-file-systems-on-demand https://blog.tomecek.net/post/automount-with-systemd/ https://www.techtarget.com/searchdatacenter/tip/Mount-file-system-Linux-systemds-way The TL;DR is to add `x-systemd.automount` to your fstab entry! Edited January 21 by Derek_ Quote Link to comment
Recommended Posts
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.