dlandon

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.

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.

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.

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