Hi,

today I have upgraded my Unraid system from 7.1.4 to 7.2.2. On first reboot I have been surprised that mounting the array did not ask for my key file and cache pool / array got mounted right away (only the cache is encrypted).

To check whether this has been just a one-time simplification in course of the upgrade, I rebooted the system and again: no asking for passphrase or key file!

I have checked for existing "keyfile" files on /boot, but there are none.

I am also wondering about the status display of the cache drive. On 7.1.4 :

• file system type has been shown as "btrfs - encrypted" (with raid 1) -> now it's just "btrfs" (with raid 1)

• on the "main" page the first cache pool device was shown with an "lock/unlock" symbol -> now there is none

This looks like the cache drive would not be encrypted at all. But on the other hand I can still see file content of this drive, which should indicate that encryption is still in place (otherwise I would expect to see only garbage).

How can I:

a) check whether the pool is still encrypted?

b) disable the auto-mount of this pool in means that I have to provide the key file manually on mount?

Thanks in advance!

Regards

Frank

Please post a diag file and/or a picture of the main page of the cache disk the webui ha icons and other to confirm if it was encrypted. ? are you running a user script at boot to provide the key file?

Yes, when I had setup Unraid (using v6.12.10) the pool has been encrypted:

There are no "keyfile" files on /boot and there is no script to unlock the cache pool. Intention is to have a secure system and starting the array/pool is possible only for someone providing the correct key file manually.

I have no recent screen shots showing encryption state, but I have digged through various backups of the cache.cfg file, stored within some flash backups and diag files:

In the beginning cache.cfg contained these lines:

diskUUID="d76f29d1-666f-4e9d-9347-2701cb6969c2"

diskFsType="luks:btrfs"

diskFsProfile="raid1"

diskFsWidth="0"

diskFsGroups="0"

These lines stay until the upgrade to version 7.1.4. Flash backup before the upgrade still shows diskFsType="luks:btrfs", but flash backup after upgrade shows:

diskFsType="btrfs"

diskUUID="d76f29d1-666f-4e9d-9347-2701cb6969c2"

diskAutotrim="on"

diskCompression="off"

diskWarning=""

The order of the first 2 lines has switched and it shows diskFsType="btrfs" instead of diskFsType="luks:btrfs".

However according to my notes I had to provide my key file after system booted into 7.1.4., which means the cache pool still should have been encrypted. I might not have booted the system before the upgrade to 7.2.2, but after this latest upgrade it has been the first time that for starting the array I did not had to provide the key file, even there has not been any option to provide a key file (as before).

Access to the shares located on the cache pool worked all the time (and still does). Shall it mean that 7.1.4 did decrypt my cache pool in place without notification?? I have to get back to a an encrypted cache pool with no auto-mount.

nas-langner24-diagnostics-20251201-1137.zip

The pool is not encrypted:

Nov 30 15:18:24 nas-langner24 emhttpd: cache: btrfs verify devices

Nov 30 15:18:24 nas-langner24 emhttpd: /sbin/btrfs filesystem show d76f29d1-666f-4e9d-9347-2701cb6969c2 2>&1

Nov 30 15:18:24 nas-langner24 emhttpd: Label: none uuid: d76f29d1-666f-4e9d-9347-2701cb6969c2

Nov 30 15:18:24 nas-langner24 emhttpd: Total devices 2 FS bytes used 223.83GiB

Nov 30 15:18:24 nas-langner24 emhttpd: devid 1 size 465.76GiB used 313.01GiB path /dev/sdb1

Nov 30 15:18:24 nas-langner24 emhttpd: devid 2 size 465.76GiB used 313.01GiB path /dev/sdc1

If it was showing as encrypted in the GUI before and asking for a key, it must have been a bug.

Yes, that's like it looks now (and should not be). But as shown above the cache pool was specified as diskFsType="luks:btrfs", which means it had been specified to be encrypted. Or can Unraid 6.x specify that without the pool being encrypted in real?

When I setup the system, first time I created the cache pool without encryption. Later I decided to encrypt it, but it was not been possible to do this on the existing pool. Therefor I had to move all data to the array, delete the pool and create a new one, this time with encryption enabled. This is what is shown in the picture in my previous post. Since that I had to provide the key file on starting the array.

However, I have searched for an old log file, before upgrade to 7.x and found one within a flash backup (at "\logs\syslog-previous" dated 2024/10/28). It contains:

Oct 28 15:22:16 nas-langner24 webGUI: Successful login user root from 192.168.178.70

Oct 28 15:23:01 nas-langner24 kernel: mdcmd (31): set md_num_stripes 1280

Oct 28 15:23:01 nas-langner24 kernel: mdcmd (32): set md_queue_limit 80

Oct 28 15:23:01 nas-langner24 kernel: mdcmd (33): set md_sync_limit 5

Oct 28 15:23:01 nas-langner24 kernel: mdcmd (34): set md_write_method

Oct 28 15:23:01 nas-langner24 kernel: mdcmd (35): start STOPPED

Oct 28 15:23:01 nas-langner24 kernel: unraid: allocating 15750K for 1280 stripes (3 disks)

-> that's me logging in to start the array, providing the key file

...

Oct 28 15:23:01 nas-langner24 kernel: md1p1: running, size: 5860522532 blocks

Oct 28 15:23:01 nas-langner24 emhttpd: shcmd (155): udevadm settle

Oct 28 15:23:01 nas-langner24 emhttpd: Opening encrypted volumes...

Oct 28 15:23:01 nas-langner24 emhttpd: shcmd (158): touch /boot/config/forcesync

Oct 28 15:23:01 nas-langner24 emhttpd: Mounting disks...

Oct 28 15:23:01 nas-langner24 emhttpd: mounting /mnt/disk1

...

Oct 28 15:23:01 nas-langner24 emhttpd: mounting /mnt/cache

Oct 28 15:23:01 nas-langner24 emhttpd: shcmd (162): mkdir -p /mnt/cache

Oct 28 15:23:01 nas-langner24 emhttpd: /sbin/btrfs filesystem show d76f29d1-666f-4e9d-9347-2701cb6969c2 2>&1

Oct 28 15:23:01 nas-langner24 emhttpd: Label: none uuid: d76f29d1-666f-4e9d-9347-2701cb6969c2

Oct 28 15:23:01 nas-langner24 emhttpd: #011Total devices 2 FS bytes used 77.00GiB

Oct 28 15:23:01 nas-langner24 emhttpd: #011devid 1 size 465.76GiB used 83.01GiB path /dev/sdb1

Oct 28 15:23:01 nas-langner24 emhttpd: #011devid 2 size 465.76GiB used 83.01GiB path /dev/sdc1

Oct 28 15:23:01 nas-langner24 emhttpd: /mnt/cache uuid: d76f29d1-666f-4e9d-9347-2701cb6969c2

Oct 28 15:23:01 nas-langner24 emhttpd: shcmd (163): mount -t btrfs -o noatime,space_cache=v2 -U d76f29d1-666f-4e9d-9347-2701cb6969c2 /mnt/cache

Oct 28 15:23:01 nas-langner24 kernel: BTRFS info (device sdb1): first mount of filesystem d76f29d1-666f-4e9d-9347-2701cb6969c2

Oct 28 15:23:01 nas-langner24 kernel: BTRFS info (device sdb1): using crc32c (crc32c-intel) checksum algorithm

Oct 28 15:23:01 nas-langner24 kernel: BTRFS info (device sdb1): using free space tree

Oct 28 15:23:01 nas-langner24 kernel: BTRFS info (device sdb1): enabling ssd optimizations

Oct 28 15:23:01 nas-langner24 emhttpd: shcmd (164): mount -o remount,discard=async /mnt/cache

Oct 28 15:23:01 nas-langner24 kernel: BTRFS info (device sdb1: state M): turning on async discard

These lines do not show any indication of encryption (besides "Opening encrypted volumes..."), but I don't know which lines are expected when encryption is enabled...

Posted a reply more than 3 hours ago, but it is shown in pink and says "Hidden - This content must be approved before it can be edited.". Have no idea why...

15 hours ago, Starfish4711 said:

Yes, that's like it looks now (and should not be).

For sure the pool was not decrypted automatically; that would require a reformat, so, like mentioned, if before it showed as encrypted, it was a GUI bug.

Understood, what a tremendous GUI bug!!!

I guess that means that once again I have to move all data from the cache pool to the array, drop the cache pool and recreate it, hoping that this time it will be encrypted. Which lines can I look for within the syslog file to prove encryption is really in place?

2 hours ago, Starfish4711 said:

Which lines can I look for within the syslog file to prove encryption is really in place?

The pool must be using /dev/mapper for the devices, instead of this:

Nov 30 15:18:24 nas-langner24 emhttpd: devid 1 size 465.76GiB used 313.01GiB path /dev/sdb1

Nov 30 15:18:24 nas-langner24 emhttpd: devid 2 size 465.76GiB used 313.01GiB path /dev/sdc1

Wit will show as e.g.

Nov 30 15:18:24 nas-langner24 emhttpd: devid 1 size 465.76GiB used 313.01GiB path /dev/mapper/sdb1

Nov 30 15:18:24 nas-langner24 emhttpd: devid 2 size 465.76GiB used 313.01GiB path /dev/mapper/sdc1

I have re-created the pool, again using btrfs with encryption. According to syslog this time it should be encrypted indeed:

Dec 2 21:00:34 nas-langner24 emhttpd: shcmd (506): udevadm settle

Dec 2 21:00:34 nas-langner24 kernel: md1p1: running, size: 5860522532 blocks

Dec 2 21:00:34 nas-langner24 emhttpd: shcmd (510): /usr/sbin/cryptsetup luksOpen /dev/sdb1 sdb1 --allow-discards --key-file=/root/keyfile

Dec 2 21:00:34 nas-langner24 kernel: device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: [email protected]

Dec 2 21:00:36 nas-langner24 kernel: BTRFS: device fsid 2560928a-5aad-4693-b1f5-6dc76d97f289 devid 1 transid 11 /dev/dm-0 (251:0) scanned by udevd (11432)

Dec 2 21:00:36 nas-langner24 emhttpd: cache: Encrypted volume present

Dec 2 21:00:36 nas-langner24 emhttpd: shcmd (512): /usr/sbin/cryptsetup luksOpen /dev/sdc1 sdc1 --allow-discards --key-file=/root/keyfile

Dec 2 21:00:38 nas-langner24 kernel: BTRFS: device fsid 2560928a-5aad-4693-b1f5-6dc76d97f289 devid 2 transid 11 /dev/dm-1 (251:1) scanned by udevd (11433)

Dec 2 21:00:38 nas-langner24 emhttpd: cache2: Encrypted volume present

Dec 2 21:00:38 nas-langner24 emhttpd: import 30 pool device: (sdb) Samsung_SSD_870_EVO_500GB_S7EWNL0X331366M

Dec 2 21:00:38 nas-langner24 emhttpd: import 31 pool device: (sdc) Samsung_SSD_870_EVO_500GB_S7EWNL0X331385N

Dec 2 21:00:38 nas-langner24 emhttpd: update_pool_cfg: 30 cache 0

...

...

Dec 2 21:00:39 nas-langner24 emhttpd: mounting /mnt/cache

Dec 2 21:00:39 nas-langner24 emhttpd: shcmd (520): mkdir -m 0666 -p /mnt/cache

Dec 2 21:00:39 nas-langner24 emhttpd: cache: btrfs verify devices

Dec 2 21:00:39 nas-langner24 emhttpd: /sbin/btrfs filesystem show 2560928a-5aad-4693-b1f5-6dc76d97f289 2>&1

Dec 2 21:00:39 nas-langner24 emhttpd: Label: none uuid: 2560928a-5aad-4693-b1f5-6dc76d97f289

Dec 2 21:00:39 nas-langner24 emhttpd: Total devices 2 FS bytes used 144.00KiB

Dec 2 21:00:39 nas-langner24 emhttpd: devid 1 size 465.75GiB used 2.01GiB path /dev/mapper/sdb1

Dec 2 21:00:39 nas-langner24 emhttpd: devid 2 size 465.75GiB used 2.01GiB path /dev/mapper/sdc1

Dec 2 21:00:39 nas-langner24 emhttpd: mounting: cache devices: 2 slots: 2 missing: 0

Dec 2 21:00:39 nas-langner24 emhttpd: shcmd (521): mount -t btrfs -o noatime,nodiscard,space_cache=v2 -U 2560928a-5aad-4693-b1f5-6dc76d97f289 /mnt/cache

Dec 2 21:00:39 nas-langner24 kernel: BTRFS info (device dm-0): first mount of filesystem 2560928a-5aad-4693-b1f5-6dc76d97f289

Dec 2 21:00:39 nas-langner24 kernel: BTRFS info (device dm-0): using crc32c (crc32c-intel) checksum algorithm

Dec 2 21:00:39 nas-langner24 kernel: BTRFS info (device dm-0): enabling ssd optimizations

Dec 2 21:00:39 nas-langner24 kernel: BTRFS info (device dm-0): enabling free space tree

Dec 2 21:00:39 nas-langner24 emhttpd: shcmd (522): mount -o remount,discard=async /mnt/cache

Dec 2 21:00:39 nas-langner24 emhttpd: update_pool_cfg: 30 cache 0

But, what I really don't like: the keyfile used for unlocking the cache pool still exists on the local drive:

root@nas-langner24:~# ls -la /root/keyfile

-rw-r--r-- 1 root root 799760 Dec 2 21:16 /root/keyfile

In my opinion the keyfile should be removed immediately after unlocking drives! Can I delete the keyfile after the array has been started or is it needed for some reason?

25 minutes ago, Starfish4711 said:

the keyfile used for unlocking the cache pool still exists on the local drive:

That is not a drive; it's in RAM, you can delete if you like after array starts. There's a GUI button for that, or with a script.

Yes, but it's still there and potentially accessible. Sure, if someone would gain access to this file somehow, this person most likely could do much more bad stuff on the system besides just to copy this file. But it's still a piece of security related information that should not stay after usage. Therefor my opinion/suggestion that it should be deleted automatically.

As you suggested, I will use that GUI button or write a small script. That "delete" button on the main page sounded dangerous to me, therefor I did not use it before.

Thanks for your support!