dlandon

UD will use the same mount point for the disk when it is reformatted. You can change the mount point. The issue is the UUID. Go to the UD settings and change the UUID.

sdam is currently showing a duplicate UUID. You'll need to go to UD settings and change the UUID so it will mount.

Post your diagnostics. Where are you getting the /dev/sdam designation? Are you using a port expander or drive bay?

Please show a screen shot.

Post diagnostics.

When the "Mount Disks with 'discard' option?" is set to yes an encrypted disk will be mounted with the discard option. The --allow-discards is used with the luksOpen command. Some of the confusion is that the use of discard on encrypted disks has changed and the posts reflect the discussion of those changes. I will review the first post write up and adjust as necessary to clear up any confusion. The UUID issue is because the disk is encrypted and UD is not determining that the disk is formatted XFS when creating a list of disks where the UUID can be changed. I will have to look into this.

What it means is that UD needs to not mount the the disk because it is being passed through. This is the normal way a UD disk is handled when UD is not to mount it. I think it makes sense. You seem to imply that if UD marks it as passed through, that UD manages passing it through to a VM automatically. UD doesn't do that, it only makes it available because UD won't mount it.

Post diagnostics.

The best way to handle this is to use the same passphrase as the array.

UD will not try to mount a passed through disk. You still have to do the steps to pass it to the VM.

As per above. UD is checking to see if the disk is spinning. The command is timing out because there are issues with your disk system, which is where you need to spend your time.

It could be something like a power supply problem, cabling, or a failing controller. I don't think it is a disk issue. It's something common to several disks. UD checks a spinning disk for disk temperatures. Preclear checks disks in the background. You'd need to post on the preclear forum for more information.

Get the new template from CA and read the instructions on how to set shared memory. It has changed.

Your disks are having problems: Dec 13 01:13:14 Juno kernel: sd 8:0:1:0: [sdw] tag#6846 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:13:14 Juno kernel: sd 8:0:1:0: [sdw] tag#6846 CDB: opcode=0x88 88 00 00 00 00 05 74 ff ff 80 00 00 00 08 00 00 Dec 13 01:13:14 Juno kernel: print_req_error: I/O error, dev sdw, sector 23437770624 Dec 13 01:13:14 Juno rc.diskinfo[9245]: SIGHUP received, forcing refresh of disks info. Dec 13 01:13:14 Juno kernel: sd 7:0:10:0: [sdp] tag#1601 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:13:14 Juno kernel: sd 7:0:10:0: [sdp] tag#1601 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f ff 80 00 00 00 08 00 00 Dec 13 01:13:14 Juno kernel: print_req_error: I/O error, dev sdp, sector 19532873600 Dec 13 01:13:15 Juno kernel: sd 9:0:0:0: [sdx] tag#472 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:13:15 Juno kernel: sd 9:0:0:0: [sdx] tag#472 CDB: opcode=0x88 88 00 00 00 00 02 ba a0 f4 00 00 00 00 08 00 00 Dec 13 01:13:15 Juno kernel: print_req_error: I/O error, dev sdx, sector 11721044992 Dec 13 01:13:25 Juno kernel: sd 7:0:11:0: [sdq] tag#1609 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:13:25 Juno kernel: sd 7:0:11:0: [sdq] tag#1609 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f ff 80 00 00 00 08 00 00 Dec 13 01:13:25 Juno kernel: print_req_error: I/O error, dev sdq, sector 19532873600 Dec 13 01:13:25 Juno rc.diskinfo[9245]: SIGHUP received, forcing refresh of disks info. Dec 13 01:13:25 Juno kernel: sd 9:0:2:0: [sdz] tag#3693 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:13:25 Juno kernel: sd 9:0:2:0: [sdz] tag#3693 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f ff 80 00 00 00 08 00 00 Dec 13 01:13:25 Juno kernel: print_req_error: I/O error, dev sdz, sector 19532873600 Dec 13 01:13:35 Juno kernel: sd 9:0:6:0: [sdad] tag#5479 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:13:35 Juno kernel: sd 9:0:6:0: [sdad] tag#5479 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f ff 80 00 00 00 08 00 00 Dec 13 01:13:35 Juno kernel: print_req_error: I/O error, dev sdad, sector 19532873600 Dec 13 01:13:35 Juno unassigned.devices: Error: shell_exec(/usr/sbin/hdparm -C /dev/sdaa 2>/dev/null | /bin/grep -c standby) took longer than 10s! Dec 13 01:13:56 Juno kernel: sd 9:0:1:0: [sdy] tag#1686 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:13:56 Juno kernel: sd 9:0:1:0: [sdy] tag#1686 CDB: opcode=0x88 88 00 00 00 00 05 74 ff ff 80 00 00 00 08 00 00 Dec 13 01:13:56 Juno kernel: print_req_error: I/O error, dev sdy, sector 23437770624 Dec 13 01:13:56 Juno kernel: sd 9:0:7:0: [sdae] tag#1060 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:13:56 Juno kernel: sd 9:0:7:0: [sdae] tag#1060 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f ff 80 00 00 00 08 00 00 Dec 13 01:13:56 Juno kernel: print_req_error: I/O error, dev sdae, sector 19532873600 Dec 13 01:13:56 Juno unassigned.devices: Error: shell_exec(/usr/sbin/hdparm -C /dev/sdae 2>/dev/null | /bin/grep -c standby) took longer than 10s! Dec 13 01:13:56 Juno unassigned.devices: Error: shell_exec(/usr/sbin/hdparm -C /dev/sdaa 2>/dev/null | /bin/grep -c standby) took longer than 10s! ### [PREVIOUS LINE REPEATED 2 TIMES] ### Dec 13 01:14:24 Juno kernel: sd 9:0:4:0: [sdab] tag#1694 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:14:24 Juno kernel: sd 9:0:4:0: [sdab] tag#1694 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f ff 80 00 00 00 08 00 00 Dec 13 01:14:24 Juno kernel: print_req_error: I/O error, dev sdab, sector 19532873600 Dec 13 01:14:24 Juno kernel: sd 9:0:5:0: [sdac] tag#4039 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:14:24 Juno kernel: sd 9:0:5:0: [sdac] tag#4039 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f ff 80 00 00 00 08 00 00 Dec 13 01:14:24 Juno kernel: print_req_error: I/O error, dev sdac, sector 19532873600 Dec 13 01:14:24 Juno unassigned.devices: Error: shell_exec(/usr/sbin/hdparm -C /dev/sdab 2>/dev/null | /bin/grep -c standby) took longer than 10s! Dec 13 01:14:36 Juno kernel: sd 9:0:3:0: [sdaa] tag#1695 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 13 01:14:36 Juno kernel: sd 9:0:3:0: [sdaa] tag#1695 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f ff 80 00 00 00 08 00 00 Dec 13 01:14:36 Juno kernel: print_req_error: I/O error, dev sdaa, sector 19532873600 Dec 13 01:14:36 Juno unassigned.devices: Error: shell_exec(/usr/sbin/hdparm -C /dev/sdae 2>/dev/null | /bin/grep -c standby) took longer than 10s! I would also remove the preclear plugin until you get this sorted out. The rc.diskinfo is a preclear background task that is also doing disk io. Edit: You also have an array disk with read errors: Dec 26 04:40:03 Juno root: Fix Common Problems: Error: disk9 (WDC_WD60EFRX-68MYMN1_WD-WX11DB4H8SXT) has read errors You need to get these issues fixed before you start losing data.

Yes, on top of the configuration change regarding shared memory, the new ES presented a lot of issues. Once we get started with a new 'all in one' Docker, we can sort through the ES issues. There is actually a 6.1.7 release now.

Do you have the latest version of UD? Post diagnostics.

Hover your mouse over the icon and it will tell you what it does. It's been there a long time.

Be sure you use the new template from CA and set the shared memory as per the instructions in the template.

I'm not going to go to a pay model. I want this to stay a free solution, but in order to do that I need to change things. Take a pause and let me see what I come up with as an answer that will work for all of us.

There are still issues with the last update to ES. I was being overwhelmed with issues (a lot from GitHub, not necessarily here) and honestly there was some attitude I really didn't appreciate, so I stopped.

A lot of us share your concern, but I believe Parler will not have a problem finding someone to host their service. They said they will be back up by noon Monday. I don't know how a Docker could help.

One of the things that's a problem with Unraid users is that the funding campaign will have to be significant to cover all the users outside the Unraid community. I do not expect Unraid users to bear the brunt of the funding and fully fund the efforts. With so many users out there, it shouldn't be a problem. I'm working on it.

Sorry, didn't mean to come across like that. You need to understand that the Unraid community is only a small base of the Zoneminder users. People saw the Docker and started using it on all manner of hosts - Macs, Windows, Debian, etc and then asked for support for that particular platform. There is no way possible for me to do that. ES/ML is also not that easy to get into a Docker and have it act like a Docker. I think the way forward is for the Docker to be rebuilt into a ZM and ES/ML only Docker and get rid of the environment variables to configure the Docker at runtime. The Docker that is in CA right now could stay for those like me that don't use ML. The issue is the amount of time that will be needed to accomplish this that I just can't 'donate' at this point. I'm thinking of a funding campaign to get funding so I can commit the time to the task. This is a difficult decision for me because I volunteer my time for Unraid, and I'm not here to make money. Unfortunately for me, this Docker has been too successful with over 5 Million downloads and has ended up taking way too much time from my other work.

The files left at /mnt/disks/ were probably created by your mistakes with setting up the paths. There was an update of UD this morning if you care to update and reboot.

Turn off the legacy mount point compatibility and then unmount and re-mount your shares. The /mnt/disks symlinks will disappear.