"WRONG ENCRYPTION KEY!" error on random disks starting array after upgrading to 6.9.0


Recommended Posts

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

 

Link to comment
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.

Link to comment
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.

Link to comment
  • 5 months later...
  • 1 month later...
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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.