March 5, 20215 yr After testing 6.9.0 on two other unraid servers for a couple of days, without any problems, I updated the next unraid server, my storage server from 6.9.0-rc2 to 6.9.0. Now I see drives with a red lock icon, claiming "WRONG ENCRYPTION KEY". But every time I try to start the array, it is a different set of drives. Even managed to get the array started with all drives unlocked once. The two other unraid servers also have their drives encrypted, the same way, the same key. No problems there. Example array start: Quote Mar 5 10:58:52 Storage emhttpd: Opening encrypted volumes... Mar 5 10:58:52 Storage emhttpd: shcmd (1639): /usr/sbin/cryptsetup luksOpen /dev/md1 md1 --allow-discards --key-file=/root/keyfile Mar 5 10:58:55 Storage emhttpd: shcmd (1641): /usr/sbin/cryptsetup luksOpen /dev/md2 md2 --allow-discards --key-file=/root/keyfile Mar 5 10:58:57 Storage emhttpd: shcmd (1643): /usr/sbin/cryptsetup luksOpen /dev/md3 md3 --allow-discards --key-file=/root/keyfile Mar 5 10:58:59 Storage emhttpd: shcmd (1645): /usr/sbin/cryptsetup luksOpen /dev/md4 md4 --allow-discards --key-file=/root/keyfile Mar 5 10:59:01 Storage emhttpd: shcmd (1647): /usr/sbin/cryptsetup luksOpen /dev/md5 md5 --allow-discards --key-file=/root/keyfile Mar 5 10:59:03 Storage root: No key available with this passphrase. Mar 5 10:59:03 Storage emhttpd: shcmd (1647): exit status: 2 Mar 5 10:59:03 Storage emhttpd: shcmd (1649): /usr/sbin/cryptsetup luksOpen /dev/md6 md6 --allow-discards --key-file=/root/keyfile Mar 5 10:59:05 Storage emhttpd: shcmd (1651): /usr/sbin/cryptsetup luksOpen /dev/md7 md7 --allow-discards --key-file=/root/keyfile Mar 5 10:59:07 Storage emhttpd: shcmd (1653): /usr/sbin/cryptsetup luksOpen /dev/nvme0n1p1 nvme0n1p1 --allow-discards --key-file=/root/keyfile Mar 5 10:59:09 Storage emhttpd: shcmd (1655): /usr/sbin/cryptsetup luksOpen /dev/sdb1 sdb1 --allow-discards --key-file=/root/keyfile Mar 5 10:59:11 Storage emhttpd: shcmd (1656): touch /boot/config/forcesync Mar 5 10:59:11 Storage root: Starting diskload Mar 5 10:59:11 Storage emhttpd: Mounting disks... Quote Mar 5 10:59:12 Storage emhttpd: shcmd (1668): mkdir -p /mnt/disk4 Mar 5 10:59:12 Storage emhttpd: shcmd (1669): mount -t xfs -o noatime /dev/mapper/md4 /mnt/disk4 Mar 5 10:59:12 Storage kernel: XFS (dm-3): Mounting V5 Filesystem Mar 5 10:59:12 Storage kernel: XFS (dm-3): Ending clean mount Mar 5 10:59:13 Storage kernel: xfs filesystem being mounted at /mnt/disk4 supports timestamps until 2038 (0x7fffffff) Mar 5 10:59:13 Storage emhttpd: shcmd (1670): xfs_growfs /mnt/disk4 Mar 5 10:59:13 Storage root: meta-data=/dev/mapper/md4 isize=512 agcount=11, agsize=268435455 blks Mar 5 10:59:13 Storage root: = sectsz=512 attr=2, projid32bit=1 Mar 5 10:59:13 Storage root: = crc=1 finobt=1, sparse=1, rmapbt=0 Mar 5 10:59:13 Storage root: = reflink=1 Mar 5 10:59:13 Storage root: data = bsize=4096 blocks=2929717235, imaxpct=5 Mar 5 10:59:13 Storage root: = sunit=0 swidth=0 blks Mar 5 10:59:13 Storage root: naming =version 2 bsize=4096 ascii-ci=0, ftype=1 Mar 5 10:59:13 Storage root: log =internal log bsize=4096 blocks=521728, version=2 Mar 5 10:59:13 Storage root: = sectsz=512 sunit=0 blks, lazy-count=1 Mar 5 10:59:13 Storage root: realtime =none extsz=4096 blocks=0, rtextents=0 Mar 5 10:59:13 Storage emhttpd: shcmd (1671): mkdir -p /mnt/disk5 Mar 5 10:59:13 Storage emhttpd: /mnt/disk5 mount error: Wrong encryption key Mar 5 10:59:13 Storage emhttpd: shcmd (1672): umount /mnt/disk5 Mar 5 10:59:13 Storage root: umount: /mnt/disk5: not mounted. Mar 5 10:59:13 Storage emhttpd: shcmd (1672): exit status: 32 Mar 5 10:59:13 Storage emhttpd: shcmd (1673): rmdir /mnt/disk5
March 5, 20215 yr How is the keyfile getting to /root? There may be an issue there. I had endless problems using encryption and keyfiles. Decided it wasn't worth the hassle.
March 5, 20215 yr Author Just now, Energen said: How is the keyfile getting to /root? There may be an issue there. I had endless problems using encryption and keyfiles. Decided it wasn't worth the hassle. Normally pulled of an ftp server so that the array can start automatically. But took that out here for testing. Makes no difference to do it via the GUI.
March 5, 20215 yr How about from the Go file? Is it a passphrase? You could try echo -n "key" > /root/keyfile and see if that works.
March 5, 20215 yr Author 1 minute ago, Energen said: How about from the Go file? Is it a passphrase? You could try echo -n "key" > /root/keyfile and see if that works. The problem is not, that the phrase is wrong or not applied. It fails randomly on drives, every time the array starts. Without touching the kexfile. Only happens with 6.9.0.
August 10, 20214 yr Having the same issue over and over again. Were you able to find a fix? It's starting to get really frustrating.
August 10, 20214 yr Author You can try to default the bios and enable the functions you need step by step (like vt-d). 6.9.2 does not like "too fast" for some reason. At least that is what I have found. Previous version never shown that. Good luck.
September 28, 20214 yr On 8/10/2021 at 1:27 AM, DiscDuck said: You can try to default the bios and enable the functions you need step by step (like vt-d). 6.9.2 does not like "too fast" for some reason. At least that is what I have found. Previous version never shown that. Good luck. Thanks for the feedback, I appreciate it. It seems like that didn't work for me. It actually caused one of my parity drives to generate a significant amount of errors due to the reboots I had to do to get the drives to mount properly.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.