I don’t see giving fellow users the pro/cons of encryption as any different than giving forum advice about whether a Z2 is better than a Z3, whether to implement a sVDEV vs. a L2ARC, or whatever topic. ZFS is a swiss army knife, it can do a lot of things, and some of them may cut you the wrong way if the proper care is not taken. That’s why we make backups.
Your and my opinions of the benefit vs. the cost of encryption are very different and we’ll simply have to agree to disagree on that point. That said, I consider the casual use of “paranoid” to describe someone because you don’t agree with their opinion as unnecessarily inflammatory.
Bringing guns into the discussion is not only inappropriate, it also further ratchets up the rhetoric and creates a straw-man argument that does not apply to the question of whether file-level, data-set level, or even pool level encryption should be used by themselves, in combination, or whatever. Guns serve a very different purpose than a NAS, encrypted or not.
A good password manager should be standard issue with every type of encryption. Ditto a plan to get to said passwords if a catastrophy affects one physical location. No different than having off-site and ideally off-line+offsite backups for the same reason. The minute some data needs to be encrypted, the need for a password manager and the careful management of its access / backups / alternative sources / etc. arises.
For example, how many among us store their password keys offsite in a way that your estate executors and/or kids can access them, if necessary? There is a lot to think about when it comes to encryption and going through what it would take to recover a locked pool/dataset/veracrypt/archive should be part of every recovery plan.
Quite a lot, really, but that’s getting wildly off-topic.
You’re right that encryption carries a not-insignificant risk of data loss, as we’ve seen (once again) in this very topic. It’s less fragile than it was before native ZFS encryption, but it’s still pretty easy to give yourself unintended ransomware, as you’ve said.
But it remains a tool for which people perceive a need. And just as other people don’t get to tell you how to use your NAS, neither do you get to tell them how to use theirs.
Full disclosure, I use veracrypts full disk encryption on my windows machines, so comparable to pool level encryption.
My TrueNAS backups are replication tasks that preserve the dataset encryption.
My B2 Cloud Backup is comparable with file level encryption. And for the offline copy (encrypted with veracrypt) I use the same passphrase I use daily to unlock my main PC.
Agreed! I prefer the comfort of at rest encryption for now.
As long as you don’t lose your encryption key / passphrase I consider it okay. But I agree, one should only dive into that if the proper base is laid. Proper backups should be in place before introducing another point of failure.
Sorry for the late reply on this one, I appreciate the help but I had to step away from it for a little while and clear my head.
Firstly, the output of the two commands are as follows:
On a hunch, I had previously made new mount points and mounted the configs/rrd/syslog for those vols labeled with e31904440bf4429a9f451dd56dc297b9 to no avail, nothing in them.
Secondly, yes there is a pwenc_secret.bak in the /data/ directory.
Lastly, I had the boot-pool hdd start throwing SMART test failures a while back, so I replaced the drive with a new one. I found the old drive squirreled away somewhere and it appears to still have the partitions on it, but I can’t seem to figure out how to import the boot-pool.
Tried to do it on a laptop with Ubuntu 23.10 first. I could get zdb -l to show the label, but nothing would show up when I tried to import or otherwise mount it. The Gnome Disk Utility and fdisk both show the proper drive structure, which matches the fdisk output from the truenas box, but if I try to mount it with the utility, it says the kernel doesn’t have the ZFS module loaded.
I then tried plugging it back into the Truenas-Scale box in the same sata slot as the current boot-pool disk, but it doesn’t seem to read it as a bootable disk, I just get the “Insert Boot Medium” prompt.
Your output suggests that you have a non-mounted (old?) System Dataset that resides on your share pool.
You might be able to check within here for old configs:
# CREATE TEMP SNAPSHOT
zfs snap share/.system/configs-f1f5036a6e4448d09a9ddb3c45165866@temporary-hold
# PROTECT TEMP SNAPSHOT / DATASET
zfs hold temporary share/.system/configs-f1f5036a6e4448d09a9ddb3c45165866@temporary-hold
# MOUNT THE RESIDUAL DATASET
zfs mount share/.system/configs-f1f5036a6e4448d09a9ddb3c45165866
# LIST THE CONTENTS
ls -l /mnt/share/.system/configs-f1f5036a6e4448d09a9ddb3c45165866
I have a hunch your old configs live inside there. (It’s over 20 MiB, which means you likely have old configs in there.)
If so, you might be able to tarball one of the “old’ish” configs with pwenc_secret.bak or pwenc_secret, to upload and reboot with an unlocked pool.
Or, alternatively, you can decode the HEX for the encrypted dataset(s) by using the method in this post by @chuck32, this time with a relevant config file that you found in this residual dataset.
no such luck unfortunately, looks like that config is locked inside the encrypted pool
root@truenas [~]# zfs mount share/.system/configs-f1f5036a6e4448d09a9ddb3c45165866
cannot mount 'share/.system/configs-f1f5036a6e4448d09a9ddb3c45165866': encryption key not loaded
I don’t know what else to say at this point. You may have indeed ransomed your own data, with no means of retrieving it.
You final options are:
Try to locate the exported config file. Maybe you had saved it at some point in time? The filetype is either .tar or .db, with truenas somewhere in the filename. Maybe you’ll get lucky and remember “I did make a backup of this config!”
Try to locate the exported keys file. Maybe you had saved it at some point in time? The filetype is .json, with your pool’s name (or dataset’s name) somewhere in the filename. Maybe you’ll get lucky and remember “I did make a backup of the encryption keys!”
Restore from backup.
If no backups exist, then you know what’s implied…
EDIT: I’m pretty sure the GUI prompts you to save your keyfile upon creating a pool with an encrypted root dataset. Did you ignore it? Click cancel? Save it somewhere that you forgot about?
On a somewhat related note, this is why I wish they implemented “multi keyslots”[1] for encrypted ZFS datasets, in the same way that LUKS manages it. You would be able to store multiple user keys to access the encrypted data; including a combination of keys and passphrases. If you lose or forget one, you can still access your data with the other(s).
