dlandon

No. UD mounts them at /mnt/disks/ and not /mnt/remotes. You should not map the docker container to /mnt/remotes/. Based on what you are saying, your best bet is to mount the disks with UD and then map them to your docker container at /mnt/disks/. Don't mount them in the docker container.

Those disks don't seem to be mounted in your docker container.

Did you have the disks mounted with UD and the docker container at the same time? If so, the disk may be corrupted and need to re-formatted. Check the disk in the docker container and see what it shows. You can use the Linux 'df' command in a cli.

It looks like you might have had the disks set as Passed Through: Jun 20 11:32:47 REPOSITORY unassigned.devices: Disk with serial 'easystore_25FB_38434A5744453645', mountpoint 'Deluge' is set as passed through. Jun 20 11:32:47 REPOSITORY unassigned.devices: Disk with serial 'EFRX-68L0BN1_1', mountpoint 'Deluge2' is set as passed through. You can't have a disk mounted with UD and have a docker container also mount it. Disk corruption will occur. You can access the disks with a docker container in one of two ways. Mount with UD and access it at /mnt/disks/. Don't mount it in the docker container. Set as Passed Through in UD and mount it in the docker container. Don't mount it in UD. It will not be available at /mnt/disks/. The mount point will be local in the docker container.

Only remote shares are mounted at /mnt/remotes/. Did you map your Docker container to /mnt/disks/ or /mnt/remotes/? Are you referring to local or remote disk drives? UD mounts devices and doesn't do any reading or writing except to mount the drive. I don't know how it could wipe out the data on your devices. I need more information. Post diagnostics on your next post and let me know which devices have the issue. Also post a screen shot of UD.

To set the share name, click on the mount point when the disk is not mounted and change it to whatever you want. When you mount the disk, this will be the mount point and the share name.

You use the source: In this case: /usr/local/sbin/rc.unassigned mount '//HANDYMAN/Work' Be sure to add quotes around the source.

This would work fine.

Auto mount is meant to start remote shares only when the array is started. I don't think it is a good idea to try to mount them every hour. If you unmounted a remote share manually, it would re-mount the next hour. This is not a good way to do things. After you set a share to auto mount while the array is started, you should mount it manually.

What kind of issues are you having?

Just found something in UD. Upgrade and see if the issue is resolved.

That's correct. All it does is issue the standby command the to the UD device.

My suggestion is to remove the UD and UD+ plugins, delete the /flash/config/plugins/unassigned.devices/ folder, and then re-install UD and UD+ plugins.

Are your unassigned devices showing up?

Post diagnostics.

Mounting remote shares with UD using SMB does not cause the stale file handles. It has had a fix to prevent that issue. NFS stale file handles cannot be prevented unless the hard links and/or cache for the share is disabled. This is not an Unraid issue, it is the nature of NFS. There is a possibility that NFSv4 can provide a fix for the stale handles. It uses virtual file handles that might prevent the stale file handle problem. There isn't enough information available to know if it will fix the issue, and I can't do any testing until Unraid provides NFSv4 support. I recommend that you use UD and mount all your remote shares with SMB to prevent the stale file handle problem.

Just restart the docker and zoneminder will update to 1.36.

Let me see if I can reproduce the issue.

It didn't mount. This is off the wall, but change the 'USB_DISK' mount point to another name. Also, try the disk in another computer to see if it mounts. Why are you mounting a USB stick with ntfs? Reformat it to vfat. Windows will able to read it.

There is an issue with one of your disks because it has a duplicate UUID. You can fix this in UD settings by creating a new UUID. May 30 22:31:45 Tower unassigned.devices: Adding disk '/dev/sdy1'... May 30 22:31:45 Tower unassigned.devices: Mount drive command: /sbin/mount -t xfs -o rw,noatime,nodiratime '/dev/sdy1' '/mnt/disks/WDC_WD80EMAZ-00WJTA0_1SJL8HJZ' May 30 22:31:55 Tower kernel: XFS (sdy1): Filesystem has duplicate UUID e406c996-a5c7-450c-bde9-bc2f889ce9df - can't mount May 30 22:31:55 Tower emhttpd: read SMART /dev/sdy May 30 22:31:56 Tower unassigned.devices: Mount of '/dev/sdy1' failed: 'mount: /mnt/disks/WDC_WD80EMAZ-00WJTA0_1SJL8HJZ: wrong fs type, bad option, bad superblock on /dev/sdy1, missing codepage or helper program, or other error. ' Your thumb drives don't show any indication of errors. It's almost as if they mounted, but UD doesn't pick that up. Post the output from the following command: mount

Boot in safe mode and install UD and see if it clears up, If it does, another plugin is interfering. I not, post diagnostics before you reboot,

No change was made to that. You have an issue with your system. Try rebooting.

Post diagnostics.

Tips and Tweaks does not change any configuration, it only makes changes to some Linux settings and NICs. I find it hard to believe that it "wrecked" your setup. Sounds more like a flash drive issue. As for the losing network access, some NIC settings have the potential to do that. The Flow Control settings are more for Intel NICs than others. There is a 'Default' setting that does not make any changes to the NICs flow control. This is the default setting when installing the plugin. Sounds like you did not install the latest version and use the defaults. Tips and Tweaks writes nothing on the flash drive except it's own configuration file. It doesn't make any other changes to flash files. Do you maintain backups for a situation as this?

I've update the plugin with the following changes: Add modify file activity. Don't show directory access in the log. The log becomes unmanageable with all the directory entries and doesn't provide any additional information. Settable option to log events by disk or share. The share logging should help identify who is accessing files based on the share being used.