dlandon

It appears the disk was not unmounted properly because the luks device was not closed. When you try to remount the disk, the luks disk is cleaned up with a close and the next attempt (manually) will succeed. Be sure to unmount the device before removing it with the device script or manually and confirm the disk successfully unmounted. If it is busy and didn't unmount, that will create this situation.

UD used to add the local tld to the tag. Yes, based on what you've said this should have come up last year from an update to UD. Caps don't matter. I thought you said somewhere that your local tld was blank.

Post your diagnostics.

Post your diagnostics.

Post your diagnostics and I'll look into it.

There a few tennents I need to mention: UD does not make any changes to config files unless user initiated. No changes in the latest version of UD would have caused this. Changes were made to UD last year to clean up server names entered by users that caused issues in the tags. A server name entered such as "SERVER.LOCAL" would cause issues in the tag. The ".LOCAL" was removed from the server name in the tag, but left in the "ip" field of the config file so the lookup of the server name would be successful. Changes were made then to indicate an invalid configuration, so a user could tell there was a problem and take action to correct. Part of the reason for the change to indicate an invalid configuration was that users were modifying the config file to try to address a problem with name resolution that has been corrected in UD. Back then the invalid configuration came up a lot when that message was added. These are the ways the invalid configuration can occur: Updating from a very old version of UD to the latest version. Restoring an older samba_mount.cfg file with the incorrect tags. Incorrect user modifications to the samba_mount.cfg file. Since you did not post a diagnostics, I (incorrectly) assumed you updated from an older version of UD because that is normally how this happens. Just as a heads up, the "Local TLD" when blank defaults to "LOCAL". In your case, you should set it to "KNET". Appologies if I offended you, but I am not fond of posts that encourage manually editing config files as mistakes made can create user problems and support issues to be addressed.

Post diagnostics.

This is the way Unraid works. It does a forced shutdown after a set amount of time that can be configured. The issue that we run into (this is what happened to UD), is several Linux commands will hang and never fail or time out. Some examples are 'stat', 'df', 'lsof', and 'fuser' when a mount point is unresponsive. A forced shutdown cannot happen when one of these Lnux commands is hung. The only answer, which is what I had to do, is to time out the command hanging UDF so it would eventually fail and not hang. The best we can do is to continue to find and fix these issues. There has been a lot of time invested in UD to prevent this kind of issue when a remote server goes offline and is not responsive. It's an incredible challenge to handle all the different cases from the varied remote servers users connect with.

All that UD change does is to include '/mnt/remotes/' as a destination in the File Manager so files can be copied or moved to a UD remote share. The issue with the '.LOCAL' in the device name was fixed a long time ago and you would have seen the issue months ago if you were keeping UD up to date.

The problem you are running into came up a year ago and has been addressed. The '.LOCAL' being added to the device designation was changed a long time ago. It is now taken from the 'Local TLD' on the 'Local Management Access' page. You should update your plugins a bit more often.

That doesn't make sense since there were no changes in the latest update to cause that to happen, but I'll look into it.

Not intentionally. I'll issue an update.

I would suggest you update to a stable version of Unraid.

UD release to address the following: NFS export file not updating after a share edit. Shutdown hanging when a remote share is offline.

Update the Recycle Bin plugin and see if the issue is resolved.

Post diagnostics.

There will be a fix for this in the next release of UD.

Yes, unmount failed because of mount being busy, but still sorting some other issues I found with shutdown.

I can't reproduce the problem. There are several choices here: Turn off Home Assistant and get me a cleaner log. Or better choice, install the "Enhanced Log Viewer" plugin and go to Settings->Enhanced Syslog Settings then click on the "Syslog Filter" tab and filter those log messages. Use these strings: "Starting session", "Close session". I'll work on it some more and see if I can get it to fail. I have a few ideas.

Your log is filled with these entries: Feb 11 04:44:13 F9-NAS sshd-session[2405263]: Starting session: command for root from 192.168.1.2 port 42290 id 0 Feb 11 04:44:13 F9-NAS sshd-session[2405263]: Close session: user root from 192.168.1.2 port 42290 id 0 Feb 11 04:44:13 F9-NAS sshd-session[2405263]: Starting session: command for root from 192.168.1.2 port 42290 id 0 Feb 11 04:44:13 F9-NAS sshd-session[2405263]: Close session: user root from 192.168.1.2 port 42290 id 0 Feb 11 04:44:13 F9-NAS sshd-session[2405263]: Starting session: command for root from 192.168.1.2 port 42290 id 0 Feb 11 04:44:13 F9-NAS sshd-session[2405263]: Close session: user root from 192.168.1.2 port 42290 id 0 Feb 11 04:44:13 F9-NAS sshd-session[2405263]: Starting session: command for root from 192.168.1.2 port 42290 id 0 Feb 11 04:44:13 F9-NAS sshd-session[2405263]: Close session: user root from 192.168.1.2 port 42290 id 0 Making the log impossible to read. Can you fix that and then provide a new diagnostics after you have the NFS problem?

Post your diagnostics.

That message comes from a log rotate file that has the wrong file permissions. It is harmless. It just means the log rotate didn't work. There will be a fix shortly.

Post diagnostics when you have the issue. You might have to open a terminal before shutting down so you can gather the diagnostics when it is hanging. UD does an unmount on shutdown to insure that the devices get unmounted.

The disk you have mounted with UD has a large number of datasets - looks like 33. That disk would be better off being a Pool disk and not a UD disk. UD does not handle ZFS disks like Unraid.

Reserved.