A couple weeks to a month ago I was unhappy with the layout of my datasets and did some reorganizing. In doing so I moved 2 encrypted datasets to a new parent dataset. One dataset was encrypted with a passphrase and this worked as expected. One was encrypted using a key and I originally had access to the dataset but after a reboot (I needed to move the server) the dataset did not automatically decrypt like other key encrypted datasets usually do. I have both the original key before I made the move, and the new key I downloaded after moving the dataset. Neither key is working.
To clarify this is what I did to my datasets:
vault/backup/confidential → vault/archive/confidential
Using the CLI command: zfs rename vault/backup/confidential vault/archive/confidential
The dataset keys are:
{“vault/backup/confidential”: “key1”}
{“vault/archive/confidential”: “key2”}
So far I’ve tried loading both key files, inputting key1 and key2 manually, and edited the key1 file so it points to the updated dataset. None of these have unlocked the dataset.
I’m assuming my data is gone at this point but I thought I would ask just to make sure. I have a backup of this data but the problem is this is where I kept backup keys for various accounts and I don’t remember if I added any since I did my last manual backup. So does anyone know of a way to retrieve access to the dataset? Would the correct encryption key be stored somewhere in a log that I can still access?
Also should I report this as a bug or is this user error? If user error should I not reorganize using rename for encrypted datasets?
I hava a naive question. Did you already try to rename it back?
You mean just physically move, right? No hardware changes?
Also, post the output of sudo zfs list -o name,encryption,keylocation vault/archive/confidential.
Have you tried opening the keyfile in a text editor and copy/paste the key into the UI instead of just uploading the key file itself?
I had not tried renaming it back, but that does not appear to have worked unfortunately.
I do mean just physically move, nothing about the configuration changed. I just needed it slightly further down in the room.
I did try that to no avail unfortunately.
Ah sorry I missed this part of the response. Here is the output from that:
NAME ENCRYPTION KEYLOCATION
vault/archive/confidential aes-256-gcm prompt
Well, this means that it is using a passphrase (which you must enter to unlock it). Not a keyfile.
Ok, what is the output for the dataset that is still “working”?
That’s weird becasue the GUI lists it as a key…
I get the same output from the passphrase locked dataset which I can still access as well as another key locked dataset which I can still access and is unlocked by default upon reboot.
Are there 3 encrypted datasets now? Do they all show keylocation prompt in the shell?
EDIT. I did some testing. Truenas shows key encrypted datasets as prompt in the shell.
Quick googling showed that @winnielinnie is a very truenas-encryption-savvy user. Perhaps he could help.
Also, it looks like the correct command is sudo zfs list -o name,keyformat,keylocation <dataset-name>
Let’s look at the entire pool to rule out some things:
zfs list -t fs -r -o name,encroot,encryption,keyformat,keylocation <pool> | grep -v "\.system"
The history of the pool can provide clues on what happened:
zpool history <pool> | tail -n 100
You will have to copy the output from some day before the date that this started.
Please don’t post the output as a screenshot and please use preformatted text.
