bruce_

Coming back to this. Removing the noserverino stanza from my /etc/fstab on the client brought back the stale file handles (as I was half-expecting it would), requiring a remount of the share to continue. I upgraded my Unraid to 6.12.10 and the same problems persisted. So it does not strictly align with client or server versions. I did stumble upon the answer though (at least to my deployment/scenario). I had an entry in my /etc/fstab line that specified SMBv3 (likely as a result of mitigating all the SMBv1/2 exploits such as Wannacry). I was using 'vers=3.0' to ensure the weaker dialects weren't in use. Upon removing this entry, it looks to have resolved the issue (with some additional spam in the client syslog about default SMB versions). So instead, I modified it to be 'vers=3.1.1' and life appears to be quite happy for now (only 20 minutes have elapsed so far; but I've been unable to recreate the original overflow problem that brought me here). I hope this helps somebody else with this issue. Edit: Apologies, the overflow problem does still exist. Almost like now it needs longer paths to trigger though. Will have to think more about this.

They are the linux kernel versions on the client device (that is mounting the Unraid SMB share). Sorry, I guess it could have been clearer.

Just wanted to add to this thread that I experienced the same error on an SMB linux client when using the 6.1.0-20 kernel (against Unraid v6.12.4 as the SMB server). From other advice, disabling cache on the share made no difference (I'm not willing to downgrade to SMBv1 as per other suggestions). Rolling back to 6.1.0-18 alleviated the issue. In order to function correctly in 6.1.0-20, I had to remove the 'noserverino' declaration in my fstab entry for the mount. It will be interesting to see how the behaviour goes vs the mover/inode changes that it was originally there to mitigate.