dlandon

Soon.

This is resolved in rc6. You will have to update UD before updating to rc6.

Works for me.

Yes, but I had to do some network/ip address changes to prevent the log flooding with the unexpected gso message.

I don't see what this has to do with this bug report. Post in the UD forum and add diagnostics. No one can help you based on this report of an issue with no supporting information.

Click on the + sign. You'll see this: In this case it is sdg1. The '1' is the partition number. Yes, the array keyfile is used.

Ok. Go to a terminal and enter these commands: /sbin/cryptsetup luksOpen /dev/sdX1 HGST_HDN726060ALE614_K1H90MAD -d /root/keyfile xfs_admin -U generate /dev/mapper/HGST_HDN726060ALE614_K1H90MAD /sbin/cryptsetup luksClose HGST_HDN726060ALE614_K1H90MAD sdX1 is the current partition designation.

A few posts up he says the disk will mount when the array is not started, but fails when the array is started because of a duplicate UUID. A little history. His disk was originally installed in the array, but now removed and he is now wanting UD to mount it so he can recover some files. I'm not sure how he removed the disk from the array.

There are others here that are more knowledgeable than I am on disk drive issues. Maybe @johnnie.black can lend a hand.

Update once more. The file system check should be working now.

Click on the button that says "Run with Correct Flag" to identify/fix file problems. I see you already did that. I see another issue I need to work on here. It is not running xfs_repair.

Update to the latest version of UD and then reboot. You should see better handling of the encrypted disk when the mount fails, and the file system check should work properly now.

I don't compile ZM.C You'll need to ask the zoneminder devs to do it.

I see a problem here. /dev/mapper doesn't exist because the disk has not been opened with luksopen. I'll have to take a look.

UD has this built in. Click the + sign by the serial number, then click on the four squares icon.

Ok, now we are getting somewhere. Nov 3 13:51:18 Tower unassigned.devices: Mount drive command: /sbin/mount '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD' '/mnt/disks/HGST_HDN726060ALE614_K1H90MAD' Nov 3 13:51:18 Tower kernel: XFS (dm-10): Filesystem has duplicate UUID 196ad532-7693-46cf-ad40-13bdccc057cf - can't mount Nov 3 13:51:18 Tower unassigned.devices: Mount of '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD' failed. Error message: mount: /mnt/disks/HGST_HDN726060ALE614_K1H90MAD: wrong fs type, bad option, bad superblock on /dev/mapper/HGST_HDN726060ALE614_K1H90MAD, missing codepage or helper program, or other error. Nov 3 13:51:18 Tower unassigned.devices: Partition 'HGST_HDN726060ALE614_K1H90MAD' could not be mounted... You have a disk problem. I am not an expert on this type of error, maybe someone else can pipe in here and help. I do potentially see an issue that I need to work on with UD. Try to mount the drive once more and see if the log gives the message about the mapper file already exists.

I wanted you to leave it auto mount to see if it would mount. Try to mount it now.

The problem with this is that if the disk is unmounted, the keyfile will not be there to re-mount. Or if an encrypted disk is added after the array is mounted. The keyfile will be missing.

I don't see anything that would keep the UD disk from mounting. Reboot your server and start the array with the passphrase. Don't do anything with the UD disk. Let it mount on its own. Once the array has started, wait about 5 minutes and post diagnostics.

No. You cannot force the disk to mount. Looks like Unraid still thinks it is part of the array. Please show a screen shot of the Main tab Array Devices.

Go to a Unraid terminal and type: cat /root/keyfile This will show you the keyfile contents. If the keyfile exists, UD should mount the encrypted drive.

According to the log, the array is not starting because the keyfile is missing, so I don't see how you can say the array is working without issues. The array has to be started before UD can see the keyfile. You can create a keyfile with only the passphrase text, Be sure there are no new lines in the file.

You have a keyfile problem. Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (47): exit status: 1 Nov 1 06:37:43 Tower emhttpd: shcmd (49): /usr/sbin/cryptsetup luksOpen /dev/md2 md2 --allow-discards --key-file /root/keyfile Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (49): exit status: 1 Nov 1 06:37:43 Tower emhttpd: shcmd (51): /usr/sbin/cryptsetup luksOpen /dev/md3 md3 --allow-discards --key-file /root/keyfile Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (51): exit status: 1 Nov 1 06:37:43 Tower emhttpd: shcmd (53): /usr/sbin/cryptsetup luksOpen /dev/md4 md4 --allow-discards --key-file /root/keyfile Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (53): exit status: 1 Nov 1 06:37:43 Tower emhttpd: shcmd (55): /usr/sbin/cryptsetup luksOpen /dev/md5 md5 --allow-discards --key-file /root/keyfile Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (55): exit status: 1 Nov 1 06:37:43 Tower emhttpd: shcmd (57): /usr/sbin/cryptsetup luksOpen /dev/md6 md6 --allow-discards --key-file /root/keyfile Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (57): exit status: 1 Nov 1 06:37:43 Tower emhttpd: shcmd (59): /usr/sbin/cryptsetup luksOpen /dev/md7 md7 --allow-discards --key-file /root/keyfile Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (59): exit status: 1 Nov 1 06:37:43 Tower emhttpd: shcmd (61): /usr/sbin/cryptsetup luksOpen /dev/md8 md8 --allow-discards --key-file /root/keyfile Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (61): exit status: 1 Nov 1 06:37:43 Tower emhttpd: shcmd (63): /usr/sbin/cryptsetup luksOpen /dev/md9 md9 --allow-discards --key-file /root/keyfile Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (63): exit status: 1 Nov 1 06:37:43 Tower emhttpd: shcmd (65): /usr/sbin/cryptsetup luksOpen /dev/nvme0n1p1 nvme0n1p1 --allow-discards --key-file /root/keyfile Nov 1 06:37:43 Tower root: Failed to open key file. Nov 1 06:37:43 Tower emhttpd: shcmd (65): exit status: 1 Nov 1 06:37:43 Tower emhttpd: Missing encryption key Nov 1 06:37:43 Tower kernel: mdcmd (46): stop Nov 1 06:37:43 Tower kernel: md1: stopping Nov 1 06:37:43 Tower kernel: md2: stopping Nov 1 06:37:43 Tower kernel: md3: stopping Nov 1 06:37:43 Tower kernel: md4: stopping Nov 1 06:37:43 Tower kernel: md5: stopping Nov 1 06:37:43 Tower kernel: md6: stopping Nov 1 06:37:43 Tower kernel: md7: stopping Nov 1 06:37:43 Tower kernel: md8: stopping Nov 1 06:37:43 Tower kernel: md9: stopping Nov 1 06:37:43 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Nov 1 06:37:44 Tower avahi-daemon[6579]: Server startup complete. Host name is Tower.local. Local service cookie is 3274231656. Nov 1 06:37:44 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Nov 1 06:37:44 Tower avahi-daemon[6579]: Service "Tower" (/services/ssh.service) successfully established. Nov 1 06:37:44 Tower avahi-daemon[6579]: Service "Tower" (/services/smb.service) successfully established. Nov 1 06:37:44 Tower avahi-daemon[6579]: Service "Tower" (/services/sftp-ssh.service) successfully established. Nov 1 06:37:45 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token ### [PREVIOUS LINE REPEATED 89 TIMES] ### Nov 1 06:39:20 Tower unassigned.devices: Adding disk '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD'... Nov 1 06:39:20 Tower unassigned.devices: luksOpen: key file not found. You need to start the array and enter the passphrase so it is available to UD, or provide the key file. The keyfile is 'keyfile' and is stored at /root/. It contains the passphrase that UD will use.

Yes, and yes. The drives will appear like multiple cache disks.

UD was originally designed and implemented to allow USB devices to be plugged into Unraid and files transferred on and off the array with ease. It then morphed into mounting disks for VMs and Dockers and remote mounting SMB/NFS shares. I use a UD disk for doing some daily backups and mounting shares on a remote Unraid server. It was always intended that VMs and Dockers would be on the array or the cache drive. Using UD to mount disks for VMs and Dockers works fine, even though it was not intended for that purpose. Then it was requested that an encrypted drive be mountable by UD so an array drive cold be mounted and the files taken off the drive. Mounting an encrypted drive by UD was never intended to be operated as VM or Docker storage. That's why you have run into the situation that you have now that LT is tightening security. LT is responding to the need you have by implementing cache pools. UD needs to go back to what was originally intended - mount USB disks for file transfer, mount hard drives for backups, temporary storage, remote SMB/NFS mounts, etc and not a part of array, VM, or Docker operation. Lt does not intend to do anything further to work out the password situation with UD devices. I don't intend to do anything further with UD to handle the password situation. LT is working on implementing cache pools that is the correct solution to your situation and is the best solution in the long run. You have several options: - Continue to use it as you have it set up now with the recognized inconvenience of using the password file. - Use the UD device without encryption. - Put your Docker image on the array or cache drive where it belongs.