I’ve got what may or may not be a problem with some replicated datasets…
Let me try and explain.
Site A is my main TrueNas server with lots of different datasets, encrypted with the key option.
I replicate most of the datasets to Site B as a backup.
Whilst I was at Site B, I needed some files so thought I would be clever and just unlock the relevant dataset, create a read-only share and copy the files.
This worked, in that at least I was able to access the files via a read-only share.
However when I went to lock the datasets again, guess what? No option to lock and this is apparently by design.
I tested my replication job and it still seems to work okay.
I restarted TruenNas at Site B, to see if the datasets would get locked again. They didn’t.
So I guess my questions are:
Is this a problem?
If yes, what can I do to lock them again?
If no, is there a risk that in the event of the machine at Site B being stolen, the unlocked datasets would be easier to get access to?
What would be the impact of moving to passphrase encryption at Site A? Would everything need to be replicated again to Site B?
I guess in some ways this was a good recovery test, and in fact I didn’t have the latest key saved in my password manager.
Make sure you never modify or write to a backup dataset. This can disrupt future incremental replications.
There’s a legacy reason for it and I never knew why TrueNAS kept it like this. There’s nothing to prevent unloading a key (“locking”) if the encrypted dataset is using a keystring instead of a passphrase.
You can lock a dataset using the command-line. Not sure how the middleware might handle it. Make sure you’re not using the filesystem and stop any shares.
zfs unload-key mypool/mydataset
This is because after unlocking it the first time, TrueNAS stores the keystring (in an encrypted form) in the database file on the boot-pool. It uses this to automatically unlock the dataset at every reboot.
If the thief knows what TrueNAS is, they can access the data if they’re able to reset the root user password. If they know some things about Linux and ZFS, they can extract the keystring from the database file.
This is unlikely. A thief might just wipe or sell your drives.
If you want to prevent access to your data and not take a chance with tech-smart thieves, then a passphrase will prevent the datasets from being automatically unlocked at every reboot. (This only applies to TrueNAS. ZFS has no auto-unlock mechanism.)
Changing the user encryption key does not change the master encryption key. You will be able to continue incremental replications like normal.
I would recommend you remember to save the new passphrase in a password manager. It doesn’t hurt to make a checkpoint on both pools (source and backup servers) before you do any of this. The checkpoints can be discarded after a day or so.
That unloads the encryption key from memory and the dataset goes back to locked state. You will need to provide the key again next time you want to access it.
Your replication continuing to work is expected by the way - ZFS replication sends the raw encrypted stream so it does not need the dataset unlocked on the receiving end. The UI not offering a lock button on replicated datasets is a long-standing design decision in TrueNAS but the middleware has no such restriction, which is why the CLI works fine.
The alternative is to switch to passphrase, to get around TrueNAS’s limitation. This way you won’t need to use the command-line or bypass the middleware.
The TrueNAS GUI/middleware allows you to unlock an encrypted dataset that uses a key, the same as with a passphrase-protected one. It doesn’t have a lock option for encrypted datasets that use a key though.
I think this is for legacy reasons and they never bothered to improve it.
IIRC, they wanted to prevent users from accidentally locking a root dataset that has the System Dataset under it. There was no risk of this with a passphrase-protected root dataset, since the middleware would not allow you to set the System Dataset to the pool, unless you switched from passphrase to key.
The problem is that this “protection” affects all datasets. That’s why we can’t lock an unlocked dataset that uses a key.
He provided they key when he unlocked it on the destination server. TrueNAS saves the key in the local db on the boot drive whenever a key-protected dataset is unlocked. The only way to have it removed from the local db is to export the entire pool.
I have changed the encryption to passphrase on one dataset as a trial.
And pleased to say that replicated okay to my downstream backup servers.
I should probably have set it up like that to start with.
Only thing that bothers me is that I set the pool to use encryption and I can’t change that. TrueNAS’s own documentation seems to suggest that you should make the pool unencrypted if you are going to use passphrase encryption on datasets.
