dlandon

Try using the IP address instead of the server name.

Post diagnostics zip file.

New release of UD. Highlights: I've done a lot to clean up the UI and added some error processing for robustness. This will provide more user feedback when there are issues. I fixed some things that have been bothering me for a long time. You'll notice some switch options removed that did not apply. For example, automount pertains to disk and not individual partitions. This is more noticeable with disks with multiple partitions. There were also some issues with partition scripts all using the same script. I've added an option in UD settings to keep from spinning down disks. When set to not spin down, UD will not set the spin down timer when a disk is mounted or unmounted. Added some icons to the help text to make it clearer. Shred and delete temp files used for credentials immediately after use. These files are used to pass credentials to some Linux commands. This keeps sensitive data from being shown in the log when the commands are shown in the log.

Looks like it is showing twice. Remove the historical device and see if that doesn't help.

If you think that is the issue, set a start time delay on your docker.

This is why UD is slow responding and times out. It is not an issue with UD. It's very hard to help you with a log snippet without line breaks that makes it impossible to read. The complete diagnostics provides a lot more information to help with your issue, such as the disk SMART report. This is the best I can do to help based on the little information you have provided. You probably have a disk or USB port issue. Try the following: Run file system check. Check SMART report for disk issues. Change USB ports.

Post diagnostics.

Yes.

You can't mount a passed through disk with UD. You are mounting the disk with UD and then checking the 'Pass Thru'. That's not how it works. You mark the disk as 'Pass Thru' and don't mount it with UD. UD won't let you mount it if it is marked 'Pass Thru'. When UD mounts the disk and your VM is using it as a passed through disk, it will get corrupted.

Probably.

You can have more than one UD drive. Post the diagnostics zip file.

I know, and I don't like it.

In the latest release of UD, I've added a 'Share' switch to the remote mounts (SMB and NFS). This allows you to mount a remote share and not have it shared again on Unraid. I'm not sure why you'd want to do this other than having a local mount point for the remote share. If it were me, I'd access the remote share through SMB or NFS directly and not through a local mount point. CIFS mounts really struggle when there are networking issues.

Fixed in latest release.

All UD devices are unmounted when the array is stopped. Leaving devices mounted would prevent a clean array shutdown.

No. That's what UD does. If you just want a local mount point, you should do it through a User Script.

UD can only mount Luks encrypted disks.

Post a screen shot of the drive on the UD page.

I can't offer any support for ES. Check the ES link on the first post for support.

The latest system plugin update needs to have the max version changed: PACKAGE DESCRIPTION: Package dynamix.system.temp.txz installed. Package dynamix.system.temp upgraded with new package /boot/config/plugins/dynamix.system.temp/dynamix.system.temp.txz. plugin: skipping: sensors-detect - Unraid version too high, requires at most version 6.7.2 plugin: skipping: sensors-detect - Unraid version too high, requires at most version 6.7.2

I didn't see the logging as a problem necessarily with the check_mk app, it just loads the log with useless info and makes it hard to browse. Does it really need to scan that often? 3-4 secs? Wouldn't every five or ten minutes be enough? I did a quick test with an ata docking station on my test server. Hot plugging a drive and then removing it without mounting it causes the log entries you are seeing. I've not seen this issue on a USB disk though. I'd say it's not a problem.

Your log is loaded with this: May 9 08:35:32 server xinetd[7472]: START: check_mk pid=19280 from=10.1.1.21 May 9 08:35:35 server rpcbind[19937]: connect from 127.0.0.1 to getport/addr(mountd) May 9 08:35:35 server xinetd[7472]: EXIT: check_mk status=0 pid=19280 duration=3(sec) May 9 08:37:32 server xinetd[7472]: START: check_mk pid=23909 from=10.1.1.21 May 9 08:37:35 server rpcbind[24568]: connect from 127.0.0.1 to getport/addr(mountd) May 9 08:37:35 server xinetd[7472]: EXIT: check_mk status=0 pid=23909 duration=3(sec) May 9 08:39:32 server xinetd[7472]: START: check_mk pid=28608 from=10.1.1.21 May 9 08:39:36 server rpcbind[29220]: connect from 127.0.0.1 to getport/addr(mountd) May 9 08:39:36 server webGUI: Successful login user root from 10.30.1.2 May 9 08:39:36 server xinetd[7472]: EXIT: check_mk status=0 pid=28608 duration=4(sec) You need to get the check_mk application under control and stop the excessive logging. I can't scan your log for anything meaningful with all that useless logging. sdh was not connected when you produced the diagnostics. I'd leave the disk attached for a minute or two to let the cache flush before disconnecting the device. I'll take a look at doing a sync before a device is unmounted and see if this can help.

Post diagnostics,

Each docker will have it's own settings.

Please don't post the same issue in multiple forums. From the nginx.conf file: ssl_protocols TLSv1.3 TLSv1.2;