dlandon

it's a known problem and an Unraid update will be available soon to fix this.

Either one, but the "Auto" settng is best so UD will negotiate the server version.

The real answer is to update UD. Then you won't have to change the UD setting.

Anyone having issues with remote NFS shares not mounting because of the "protocol not supported" problem, update UD and a patch will be applied to overecome an issue with an NFS setting we enabled that causes this issue. UD reverts that setting so these errors do not occur. It isn't an issue with Unraid to Unraid connections with NFS, it seems to only affect other server devices that don't behave the same way as Unraid.

Anyone having issues with remote NFS shares not mounting because of the "protocol not supported" problem, update UD and is a patch will be applied to overecome an issue with an NFS setting we enabled that causes this issue. UD reverts that setting so these errors do not occur. It isn't an issue with Unraid to Unraid connections with NFS, it seems to only affect other server devices that don't behave the same way as Unraid.

If that doesn't work, post back here. I have another suggestion.

When mounting NFS remote shares, UD uses a setting to request the server for the latest version of the protocol available. You can force UD to use NFSv4 settings when mounting NFS shares by setting the "NFS Version to use when Mounting Remote Shares:" to NFSv4. This disables the NFS request for version feature. There have been some changes in the latest Kernel in 6.12.9 that have probably caused this change in the way this works.

Let's get your server permissions sorted out then come back to the SMB issues on a Mac. We have made some changes for better Mac support, and I will show you a much better way to apply your customizations to Mac SMB access.

You have macOS Interoperability enabled and a lot of extra settings in your smb-extra.conf related to fruit and some other added entries. You have talked about using PCs to access your SMB shares. Are you using Mac computers also? Trying to unscramble all the additional settings in your smb-extra.conf would be a real chore. My suggestion is to remove all those entries, go back to more bare metal Unraid and then come back for support if you still have the same issues. Getting back to a standard SMB configuration will help us better support you. If you really have to have all those additional settings, get back to standard settings, monitor your file and folder permissions, and then add things back a little at a time and continue to monitor as you go. See if one of those settings is causing issues. You have also enabled multi channel. You should do all that through the Unraid UI so SMB is set up correctly. The smb-extra.conf lines are all global entries and it's easy to mess things up. I don't recommend using the 'veto files' statement. There is a fair amount of overhead to handle that and you can enable the hide dot files setting to hide them.

That happens once in a while and I have not been able to figure it out.

Click on the double arrows in the upper right of the UD page. It should initiate udev to refresh the disk status. This happens with nvme drives at times.

UD is not able to accomodate this. You should look into setting up an fstab where you can specify the autofs.

Post a new diagnostics.

Yes, it is related to listing files and directories. I occurs with the File Manager in the UD UI and in the cli.

Looks to be someone's attempt to prevent a buffer overflow intentionally or unintentionally. I suspect one of the parameters being passed in to the function causes the failure - like the buff_start or end_of_buffer pointers are incorrect. Good find. Thank you.

There is an issue with CIFS mounts (remote shares) in 6.12.9 that causes this issue. For the moment downgrade to 6.12.8 until we come up with a solution. Since this appears to be related to Samba (CIFS mounts) or the Kernel, it will have to be fixed with an Unraid release. I haven't been able to address the issue with anything related to how UD mounts remote shares.

I've put some time into troubleshooting UD to see if there is something in the way UD is mounting remote shares. There doesn't seem to be anything that UD does or can do to cause this problem. I'm not one to play the blame game, but as we get into this I believe we are going to find it's related to a change in Samba or a Kernel change causing this. In our beta testing for one of the recent releases, we found an issue with CIFS mounts where 'df' would not report size, used, and free space on a CIFS mount point. When UD sees a CIFS mount with zero space, it disables the mount so UI browsing and other operations could not be performed. UD assumes there is a problem with the mount. It ended up being related to a 'stat' change in the Kernel failing on the CIFS mount. As has been said, this is related to remote mounts through UD. It does not affect the NAS file sharing functionality through SMB. I understand that this is an important functionality for many users and for the moment, downgrading to 6.12.8 is the answer. We will release a new version of Unraid as soon as we have an answer.

Yeah, now to track down why it's happening. What fun!

I am able to reproduce the issue. It appears when you remote mount a share from a server that is not another Unraid.

What is the NAS? Another Unraid server?

Ok. But if you want Unraid to mount them, you'll probably need to add all or part of this to the rules: anongid=100,anonuid=99,all_squash

It's not UD. The remote shares unmounted fine. It's the dockers taking a long time to stop: Mar 27 12:19:06 Apollo root: stopping dockerd ... Mar 27 12:19:07 Apollo root: ... Waiting to die. Mar 27 12:19:08 Apollo root: ... Waiting to die. Mar 27 12:19:09 Apollo root: ... Waiting to die. Mar 27 12:19:10 Apollo root: ... Waiting to die. Mar 27 12:19:11 Apollo root: ... Waiting to die. Mar 27 12:19:12 Apollo emhttpd: shcmd (94): umount --lazy /var/lib/docker Mar 27 12:19:12 Apollo unassigned.devices: Unmounting All Devices... Mar 27 12:21:02 Apollo sshd[1168]: Connection from 192.168.2.35 port 17590 on 192.168.2.40 port 22 rdomain "" Mar 27 12:21:02 Apollo sshd[29211]: Connection closed by 192.168.2.35 port 17480 Mar 27 12:21:02 Apollo sshd[29211]: Close session: user root from 192.168.2.35 port 17480 id 0 Mar 27 12:21:02 Apollo sshd[29211]: pam_unix(sshd:session): session closed for user root Mar 27 12:21:02 Apollo sshd[29211]: Transferred: sent 154472, received 4672 bytes Mar 27 12:21:02 Apollo sshd[29211]: Closing connection to 192.168.2.35 port 17480 Mar 27 12:21:02 Apollo elogind-daemon[1528]: Removed session c4. Mar 27 12:21:02 Apollo sshd[1170]: Connection from 192.168.2.35 port 17591 on 192.168.2.40 port 22 rdomain "" Mar 27 12:21:02 Apollo sshd[1172]: Connection from 192.168.2.35 port 17592 on 192.168.2.40 port 22 rdomain "" Mar 27 12:21:02 Apollo sshd[1168]: Postponed keyboard-interactive for root from 192.168.2.35 port 17590 ssh2 [preauth] Mar 27 12:21:02 Apollo sshd[1168]: Postponed keyboard-interactive/pam for root from 192.168.2.35 port 17590 ssh2 [preauth] Mar 27 12:21:02 Apollo sshd[1168]: Accepted keyboard-interactive/pam for root from 192.168.2.35 port 17590 ssh2 Mar 27 12:21:02 Apollo sshd[1168]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Mar 27 12:21:02 Apollo elogind-daemon[1528]: New session c5 of user root. Mar 27 12:21:02 Apollo sshd[1170]: Postponed keyboard-interactive for root from 192.168.2.35 port 17591 ssh2 [preauth] Mar 27 12:21:02 Apollo sshd[1170]: Postponed keyboard-interactive/pam for root from 192.168.2.35 port 17591 ssh2 [preauth] Mar 27 12:21:02 Apollo sshd[1170]: Accepted keyboard-interactive/pam for root from 192.168.2.35 port 17591 ssh2 Mar 27 12:21:02 Apollo sshd[1170]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Mar 27 12:21:03 Apollo elogind-daemon[1528]: New session c6 of user root. Mar 27 12:21:03 Apollo sshd[1172]: Postponed keyboard-interactive for root from 192.168.2.35 port 17592 ssh2 [preauth] Mar 27 12:21:03 Apollo sshd[1172]: Postponed keyboard-interactive/pam for root from 192.168.2.35 port 17592 ssh2 [preauth] Mar 27 12:21:03 Apollo sshd[1172]: Accepted keyboard-interactive/pam for root from 192.168.2.35 port 17592 ssh2 Mar 27 12:21:03 Apollo sshd[1172]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Mar 27 12:21:03 Apollo elogind-daemon[1528]: New session c7 of user root. Mar 27 12:21:03 Apollo sshd[1168]: Starting session: subsystem 'sftp' for root from 192.168.2.35 port 17590 id 0 Mar 27 12:21:03 Apollo sshd[1170]: Starting session: subsystem 'sftp' for root from 192.168.2.35 port 17591 id 0 Mar 27 12:21:03 Apollo sshd[1172]: Starting session: subsystem 'sftp' for root from 192.168.2.35 port 17592 id 0 Mar 27 12:21:03 Apollo sshd[1172]: Connection closed by 192.168.2.35 port 17592 Mar 27 12:21:03 Apollo sshd[1172]: Close session: user root from 192.168.2.35 port 17592 id 0 Mar 27 12:21:03 Apollo sshd[1172]: pam_unix(sshd:session): session closed for user root Mar 27 12:21:03 Apollo sshd[1172]: Transferred: sent 3656, received 3232 bytes Mar 27 12:21:03 Apollo sshd[1172]: Closing connection to 192.168.2.35 port 17592 Mar 27 12:21:03 Apollo elogind-daemon[1528]: Removed session c7. Mar 27 12:21:03 Apollo sshd[1170]: Connection closed by 192.168.2.35 port 17591 Mar 27 12:21:03 Apollo sshd[1170]: Close session: user root from 192.168.2.35 port 17591 id 0 Mar 27 12:21:03 Apollo sshd[1170]: pam_unix(sshd:session): session closed for user root Mar 27 12:21:03 Apollo sshd[1170]: Transferred: sent 3656, received 3232 bytes Mar 27 12:21:03 Apollo sshd[1170]: Closing connection to 192.168.2.35 port 17591 Mar 27 12:21:03 Apollo elogind-daemon[1528]: Removed session c6. Mar 27 12:21:51 Apollo kernel: CIFS: VFS: \\10.0.0.2 has not responded in 180 seconds. Reconnecting... Mar 27 12:21:51 Apollo kernel: CIFS: VFS: \\10.0.0.2\Dropbox Close cancelled mid failed rc:-11 Mar 27 12:21:51 Apollo kernel: CIFS: VFS: \\10.0.0.2\Dropbox Close cancelled mid failed rc:-11 Mar 27 12:21:51 Apollo kernel: CIFS: VFS: \\10.0.0.2\Dropbox Close cancelled mid failed rc:-11 Mar 27 12:22:22 Apollo unassigned.devices: Unmounting Remote SMB/NFS Share '//10.0.0.2/Dropbox'... Mar 27 12:22:22 Apollo unassigned.devices: Unmount cmd: /sbin/umount -t cifs -f '/mnt/remotes/Dropbox' 2>&1 Mar 27 12:22:22 Apollo unassigned.devices: Successfully unmounted '//10.0.0.2/Dropbox' Mar 27 12:22:43 Apollo unassigned.devices: Unmounting Remote SMB/NFS Share '//10.0.0.2/Dropbox/Pictures'... Mar 27 12:22:43 Apollo unassigned.devices: Unmount cmd: /sbin/umount -t cifs -f '/mnt/remotes/Pictures' 2>&1 Mar 27 12:22:43 Apollo unassigned.devices: Successfully unmounted '//10.0.0.2/Dropbox/Pictures' I think your shutdown timer is set properly to handle this.

The mount points you are trying to mount remotely are not Unraid shares and you are setting the export rules manually for those shares. This is an Unraid share entry in the exports file: "/mnt/user/isos" -fsid=105,async,no_subtree_check *(rw,sec=sys,insecure,anongid=100,anonuid=99,all_squash) I suggest you take a look at this entry and compare to your entries and see if changes are needed. I suspect a permissions issue that UD is having trouble with. Check if 'all_squash' makes a difference. As a test, share a normal Unraid share with NFS and try to mount that and see how it goes. I fully understand that you can mount those with other systems. The issue is that the UD NFS client is probably more restrictive about permissions.

Check the date and time. Probably.

That indicates that the port is open. Show a screen shot of the UD page showing the remote shares.