dlandon

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.

Take a look at this and verify your NFS Rules on Unraid and the mount parameters on the NFS client are set appropriately:

Post diagnostics.

Post diagnostics.

Post your diagnostics so I can look into it. I can't reproduce your issue. I suggest you remove and reinstall the plugin.

Share both using SMB and do it with a Windows or Mac computer.

I've never tried entering the destination manually. The file manager may not like that.

/mnt/remotes/192.168.1.1_copy/