SOLVED TrueNAS not automatically opening Encrypted dataset with the key

Keven

Contributor
Joined
Aug 10, 2016
Messages
114
Hi,

I have recently added new Encrypted sub-dataset and configure ACL on them. The main dataset is not encrypted and it has been updated to the latest ZFS version from FreeNAS 9.10. the new sub-dataset that i just created a couple weeks ago ARE encrypted with a key, (Not a passphrase) yesterday i shut down the server by short pressing the power button. change the fans and start it up after that. now i notice that 1 of 3 dataset is remaining lock (qbittorrent) after boot.

Capture d'écran 2021-05-28 13.19.10(2).png


i don't get why this one would not unlock when all the other are. they are all Key based encrypted only.

so first, i would like to know why it doesn't unlock itself after booting and second i would like to know how to search a config backup "FREENAS-20210509140740.tar" with the secret seed exported to find the encryption for this dataset. i am not sure if i did the backup before or after creating the qbittorrent dataset, and also i made change to the config after in term of ACL... not the end of the world if i loose that but if i can save from doing it again it would be great.

Also i can recreate the data inside the qbittorrent dataset, but it would take me a lot of time so not the end of the world if i MUST delete and recreate the dataset

12.0-U3.1
latest pool version (upgraded from freenas 9.10)
 
Joined
Oct 22, 2019
Messages
3,641
Did you at any point export your pool keys for the zpool Vol1?

What is the output of:
zfs get keyformat,keylocation Vol1/Bibliotheque/qbittorrent

i would like to know why it doesn't unlock itself after booting and second i would like to know how to search a config backup "FREENAS-20210509140740.tar" with the secret seed exported to find the encryption for this dataset.
From what I understand, when you upload the .tar file (i.e, import your configuration), it uses the secret seed behind-the-scenes to decrypt certain passwords and sensitive information. I don't know of any way to manually use it on a local PC to find the HEX string used for unlocking your datasets. (Unless someone else here knows a trick.) That's why it's imperative to export the pool keys as soon as you finish setting up your ZFS-encrypted datasets.
 

Keven

Contributor
Joined
Aug 10, 2016
Messages
114
Did you at any point export your pool keys for the zpool Vol1?

not the key as is, i only backup my config and ticking the option for secret seed


What is the output of:
zfs get keyformat,keylocation Vol1/Bibliotheque/qbittorrent


Code:
root@FREENAS:~ # zfs get keyformat,keylocation Vol1/Bibliotheque/qbittorrent
NAME                           PROPERTY     VALUE        SOURCE
Vol1/Bibliotheque/qbittorrent  keyformat    hex          -
Vol1/Bibliotheque/qbittorrent  keylocation  prompt       local
 
Joined
Oct 22, 2019
Messages
3,641
Did you by chance copy-and-paste the same 64-character HEX string for the datasets deluge and qbittorrent to use for their encryption key? If so, you can export the pool's keys, open the .json file in a text editor, and then use the same HEX string to unlock qbittorrent. My hunch is you left them at their randomly generated defaults? If so, you might have locked yourself out of accessing qbittorrent and its child datasets. :frown:

not the key as is, i only backup my config and ticking the option for secret seed
Rule of thumb, always export the pool keys and store them somewhere safe; even if it means attaching and emailing the .json file to yourself with a trusted email provider.

Someone here might know how to extract it from the .tar file, but you might be able to save yourself a lot of time by re-doing your qbittorrent and children datasets.

You could try to re-import your config file (.tar), and then reboot, on the offchance that you exported it while qbittorrent was currently unlocked. However, you will lose any settings you've changed or added since you exported your config.
 

Keven

Contributor
Joined
Aug 10, 2016
Messages
114
i have an idea, if i backup my config now with secret seed and then upload my old backup, in the off chance that it was unlock, can i then export the key only and after that revert back to the latest backup and input the key manually?

Did you by chance copy-and-paste the same 64-character HEX string for the datasets deluge and qbittorrent to use for their encryption key? If so, you can export the pool's keys, open the .json file in a text editor, and then use the same HEX string to unlock qbittorrent. My hunch is you left them at their randomly generated defaults? If so, you might have locked yourself out of accessing qbittorrent and its child datasets. :frown:

yes i leave them random :(


Also did i do something wrong in the setup of this dataset because i don't want others in the future to not open like that...
 
Joined
Oct 22, 2019
Messages
3,641
i have an idea, if i backup my config now with secret seed and then upload my old backup, in the off chance that it was unlock, can i then export the key only and after that revert back to the latest backup and input the key manually?

That's worth a shot. How long ago did you last save your config (.tar) file?

Also did i do something wrong in the setup of this dataset because i don't want others in the future to not open like that...
I'm not sure what caused your qbittorrent dataset to lock itself in the first place. The safest thing to do (really should be considered mandatory) is to always export your pool's keys whenever:
  • You finish creating a pool / datasets with native encryption
  • You change the encryption properties / key of an already encrypted dataset
 

Keven

Contributor
Joined
Aug 10, 2016
Messages
114
That's worth a shot. How long ago did you last save your config (.tar) file?

that from 9th of may... but it didn't work.


i deleted the dataset and remade one, this time i exported the key ASAP. and then rebooted. after the reboot the qbittorrent dataset was still locked and the other unlock. i unlock it and then click save in the system/general. now when it reboot it is unlock. I am 80% sure that it was the save that made the difference, but can't be sure because for some reason TrueNAS reboot itself a couple of time after switch from backup save config...
 
Top