TL;DR: How can I make TrueNAS forget the saved key to a dataset?
L;R:
Dear TrueNAS community,
today, I made the severe mistake of validating my backup, specifically, I unlocked it. It’s being sent over from another system that’s holding the keys for auto-unlock purposes. Up until now it remained locked on the backup system and I would like this to be the case again.
Unfortunately, when I entered the keys, it decided to save them and now the backup system auto-unlocks the dataset as well. There was no toggle to instruct it not to save the keys.
I already tried the following steps:
zfs unmount -u <Dataset> → only works until the device is rebootet
zfs change-key -o keylocation=prompt <Dataset> → requires me to perform a key rotation which would bring the dataset out of sync with the source so it’s not an option.
Currently the only option I seem to have left would be to delete the entire dataset and do the backup from scratch and even then I cannot be sure the keys are gone. I don’t really want to reinstall the OS just to get rid of keys that are stored on the boot volume…
While TrueNAS leverages ZFS, it automates some things that are not inherent with ZFS.
With regards to TrueNAS specifically: Whenever you use a “key” (or keystring) to encrypt a dataset, it saves it on the boot-pool, without a means to “lock” the dataset. (You can only “lock” a passphrase-protected dataset.) To reiterate: This is specific to TrueNAS, not ZFS.
In order to wipe the key for such datasets, you need to export the pool.
However, unless you’re using “raw streams” to backup via replication, then the destination still needs to be unlocked for every replication.
Sure thing. Still doesn’t make me particularly happy to not have any say in it saving my key on a one-time unlock, no matter if it’s TrueNAS or ZFS.
Exporting the entire pool to get rid of the key for one (or a handful of) dataset(s) in there seems like shooting ants with orbial laser cannons.
I think TrueNAS is using ZFS send for replication tasks. So far it’s all been working fine and there doesn’t seem to be any need to unlock the dataset on the receiving machine. Encryption is inherited from the sending side.
I can assure you that the dataset should be locked and that there is no need to have it unlocked. I unlocked it once to confirm if everything is in order and now I can’t undo that.
To conclude: From my understanding, there is no way to delete a key or decide if TrueNAS saves it in the first place. To purge the key I need to export the entire pool, then re-import it and make sure to never provide the key again. As this does not seem to be me missing a setting, menu or command, this is a missing feature or unwanted behavior that I should open a feature request over. Any objections?
P.S.
On one hand it’s a funny post, on the other hand I’d say it’s quite unfitting. If TrueNAS doesn’t provide a way to do what we need, we basically have to directly interface with ZFS. The commands did exactly what they were supposed to. Make the dataset unavailable without being destructive. There was no randomness involved. (Also -o keylocation=<location> being a ZFS option strongly suggests direct involvement of ZFS with auto-unlock ^^)
Might warrant a feature request: “Ability to lock encrypted datasets protected with a key”
The request might be rejected, since by design they want datasets to automatically unlock at bootup, so that the System Dataset is immediately available. (It is for this reason why you cannot use a passphrase for a root dataset of a pool that also houses your System Dataset.) They also don’t want you to lock a dataset that was automatically unlocked on boot, for the same safety reasons.
This gets me an identical copy of the dataset on the backup machine, including snapshots if I’m not severely mistaken. It inherited the encryption from the source.
If the source dataset is encrypted + you use either (or both) “Include Dataset Properties” or “Full Filesystem Replication” + you leave unchecked “Encryption” on the destination = raw stream is invoked[1]
Since you’re not using a passphrase, then it means you have to export the pool on the backup server every time you unlock it to validate.
Or you can use the command-line.
The GUI doesn’t make this clear. With ZFS in the command-line, the -w flag can be manually specified. However, with the TrueNAS GUI, the -w flag is only invoked when you use a combination of settings that invoke it. You’ll notice there is no checkbox labeled “Raw stream”. ↩︎
Correct. Saving the key (automatically) is a TrueNAS thing. (You could save it with the command-line, but you’d be doing that manually, if desired.)
In order to unlock the datasets in the command-line, you’ll still need to provide the key, anyways, which is usually saved locally. Or copy+paste the long hex string.
EDIT: Obligatory caveat. You risk breaking things when you bypass the GUI or middleware.
