dlandon

I found it. Fixed in the next release.

Post diagnostics.

Yes, but some USB disks won't spin down.

This was posted some time ago - sorry for the slow solution. I have released a new version of UD that should solve this problem. When a remote SMB share is first mounted now, the protocol (vers=) is not specified. I'm finding that a lot of remote shares will mount this way and the server will determine the most secure SMB version. If that fails, the SMB protocol is specified and another mount attempted in the following order - SMB3, SMB2, then SMB1 (if netbios is enabled). Please update and try again.

New release of UD: Change mount point icons to something more meaningful. A pencil icon will show when the mount point can be changed. A file folder icon will show when the mount point can be used to browse the device. The mounting of remote SMB shares has been changed to first trying to mount the remote share without the protocol (vers=) being specified. If that fails the mount protocol is specified in the following order - SMB3, SMB2, and then SMB1 (if netbios is enabled). Encrypted disks will show the file system when mounted.

Click on the + icon to show the partitions, then click on the check mark to check the file system. See if that doesn't fix the file system.

Go to the UD settings and you can change the UUID for that drive so it is not a duplicate.

I see this in the log: Nov 16 13:14:06 unraid-server1 unassigned.devices: Mounting 'Auto Mount' Remote Shares... ... Nov 16 13:19:36 unraid-server1 unassigned.devices: Cannot 'Auto Mount' Remote Shares. Network not available! The startup check for the network to be available before auto mounting remote shares is taking over 5 minutes to determine the network is not available. There is an issue on the network available script that causes this lengthy time, and because it is in an Unraid startup event, the Unraid GUI will not be available until it completes the network check. I have a fix applied, but it is not released yet. When you reboot Unraid, the GUI will eventually come up after the 5 minute delay caused by this issue.

Suggestions: Change this: /boot/config/plugins/unassigned.devices/samba_mount.cfg To this: /tmp/unassigned.devices/config/samba_mount.cfg A copy of the unassigned devices configurations are moved to the /tmp file system when Unraid is started and updated whenever a change is made in UD. It is also copied back to the flash when a change is made so the flash is kept current. The idea is to cut down on the flash file accesses which are slower than ram. Also add -fl (force, lazy unmount) to the umount command. The unmount will be forced and will immediately return. And some criticism: It almost appears that you are blaming UD for the issues with commands like 'lsof'. 'lsof', and 'df' both will hang badly when a a CIFS share is off-line. What you are running into is what I found with these commands. If a CIFS share goes off-line, you can type 'df' it will indefinitely hang and not time out. To get around this, UD only queries the remote shares when a user is on the UD page. Nothing is done in the background. The commands will also time out so UD does not appear to hang. I am not a fan of mounting and unmounting a remote share like this. It seems a bit brute force and prone to problems, when a much cleaner approach would be to keep the remote server on-line. Unfortunately this depends on a solid, reliable network. You have said you like the remote shares with a local mount point for backups and I guess I get that, but you are running into the disadvantages of CIFS mounts. You are probably pushing it a bit farther than is practical. You apparently have made changes to UnassignedDevices.php. Because of this, I can offer no support to anyone using your script.

You aren't doing anything wrong. The age date that the recycle bin uses is the last access time (atime in Linux) which is set when the file is deleted and sent to the .Recycle.Bin folder, not the last modified time (mtime in Linux). If anything changes the atime of the file in the .Recycle.Bin, that will affect the age date of that file. The deleted files log is found on the 'Deleted Files' tab of the Recycle Bin. This log is derived from the '/var/log/samba/log.smbd' file. That file is lost on reboot because it is kept in the ram file system, so you won't be able to see the deleted files after a reboot.

When I make changes/enhancements to UD I have to take into consideration the application to the wider community. It appears you have a unique need and have come up with a solution for your situation. At this time, I don't feel it appropriate to add an automatic unmount/re-mount of remote shares. We've discussed some of the technical issues. I do continually look for better ways to handle CIFS shares. CIFS mounts depend on a reliable network connection and when the remote server goes off-line, the Linux commands to query things like used and free space will hard hang. 'df' is the worst. That's why the commands are timed out by UD. Every remote server also seems to do things differently and it's quite a challenge to keep up with every server's quirks. Some older NAS devices are still using SMBv1, which has known security issues.

Post a screen shot of the UD page when it is working. Also post your diagnostics.

You said you could see Dockers. What webpage does not show? Just UD? Do you get a blank screen?

Post another diagnostics.

The unmount of a CIFS mount is supposed to be forced when the server is off-line. Looking into the code, I see a logic error that I will correct. I'll spend a little time testing before including it in UD.

CIFS does not work the same as a hard drive unmount. Unmounting a remote share that is off-line is messy and shouldn't be done. The best bet is to get the remote server back on-line. I'll take a look at some options. Unmounting a remote share that is off-line is not a good idea for several reasons. CIFS will do a recovery once the remote server is back on line. Unmounting a remote share when the remote server is off-line will pull the rug out from under any application using that share and is a really bad idea. What would be the criteria for unmounting the share? There are so many different servers I don't know where to even start on the time to wait to unmount, and whether or not the remote server would handle it properly.

You have a lot of remote mounted shares. Is it really necessary to do things that way? What would this do? If the remote server is not reachable, increasing the delay will only slow down things further. The reason for the timeouts is to keep some commands like 'df' from completely hanging the Unraid server. If it can't complete in 10 seconds, it probably won't happen at all. I've given this a lot of thought because of other users having the same issues. Unmounting the remote share whenever the remote server is off-line will create more problems than it solves. CIFS does not work as cleanly as you might think when it comes to unmounting and re-mounting a share when the remote server is off-line. Conclusion: - Keep the remote server online and available, or only mount the remote shares when actually needed.

Go to UD settings and set "Force all SMB remote shares to SMB v1?" and see if it will mount then.

Can you post a screen shot so we can see what you are talking about.

Post diagnostics. There is another issue.

The password is encrypted. Be careful of special characters in the credentials. It would be best to stay from them.

You are getting a permission denied error: Nov 15 23:27:32 Muwahhid unassigned.devices: Mount of '//MUWAHHID-R-540/e' failed. Error message: 'mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) '. Several versions ago the passwords were encrypted and not stored in plain text. Remove the remote shares and then recreate them. They should then mount fine.

Click off the Auto Mount switch on the remote share. Reboot the server. Then you can delete the remote shares.

Looks like your remote server is off-line: Nov 15 16:45:16 saberaid unassigned.devices: Unmounting Remote SMB/NFS Share '//SABERVAULT/SaberVault2'... Nov 15 16:45:16 saberaid unassigned.devices: Unmounting '//SABERVAULT/SaberVault2'... Nov 15 16:45:16 saberaid unassigned.devices: Unmount cmd: /sbin/umount -t cifs '//SABERVAULT/SaberVault2' 2>&1 Nov 15 16:45:26 saberaid unassigned.devices: Error: shell_exec(/sbin/umount -t cifs '//SABERVAULT/SaberVault2' 2>&1) took longer than 10s! Nov 15 16:45:26 saberaid unassigned.devices: Unmount of '//SABERVAULT/SaberVault2' failed. Error message: command timed out If you turned off the remote server, turn it back on and then unmount and delete the remote shares.

Post diagnostics.