dlandon

Post diagnostics.

It's not a design issue; it's a technical limitation. The Root Share is mounted as bind mount and exclusive shares are not available because the bind mount does not allow symlinks.

This issue is in 6.12.9, but there was a change made that will be in 6.12.8 to enable client negotiation of 4.X. Boot in 6.12.8 and see if this helps your situation.

I think you are running into an issue with 6.12.9 where a changed setting in nfsmounts is causing problems. It is to be solved in 6.12.10 due out soon.

Who is the client? From the client that I assumed was Unraid.

We need more information to be able to help. Post diagnostics.

When i click on it, it sits on the Unraid wave and appears to be hung.

Go to Settings->CA Settings and it will turn itself off.

Artificial Intelligence. If you aren't using it, do. It will do wonders for your coding. You can get a free ChatGPT account.

Just as a clarificaton. When AI is asked about which approach is better, the response is: "It depends on the size of the file /var/log/file.activity.log and the frequency of the script execution. If the file is relatively small and the script is not executed frequently, directly grepping the file would likely be more efficient and result in lower disk I/O. This is because reading the file directly with grep avoids the overhead of piping the output of cat into grep. However, if the file is large or the script is executed frequently, it may be more efficient to use a combination of cat and grep as you have done, especially if you're only interested in specific lines matching a pattern. This can help avoid repeatedly scanning the entire file with grep, potentially reducing overall disk I/O." The line of code in question is executed for every disk device and the log can get large (it is limited to 20,000 lines though), so based on the AI response, it appears the " useless use of cat" may not be useless after all. Maybe before criticizing the code, you need to understand it better?

Fixed.

There's a problem. GIve me a minute to fix.

Update released.

I have a fix for this. I just haven't released it yet. Different styles. If you think you can do a better job, you are free to fork this project and do it yourself.

Yes. Fix: Apply a patch to revert an NFS setting causing "protocol not supported" issue.

I found an issue with NFS that is resolved with the latest release of UD that I believe will solve the NFS mounting issue.

NFS does not use credentials. It uses Linux permissions. There is an issue with UD and 6.12.9 Unraid. Update UD and see if you can get your NFS shares to mount.

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.