-
Posts
10,397 -
Joined
-
Last visited
-
Days Won
20
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Everything posted by dlandon
-
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.
-
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.
-
UD Addon: SMB Unremounter: unmount offline shares and remount them
dlandon replied to mgutt's topic in User Customizations
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.
-
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.
-
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.
-
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.