As I upgrade move from Synology to TrueNAS I’d like to have my NAS encrypted as best (and simply) as possible, strong passphrases are what I have used in the past, and what I will likely use here.
Does this mean that if I follow that guidance and if I only encrypt child datasets, when I choose a pool for my apps, the “hidden” ix-applications dataset where my apps and the app data will reside will be unencrypted (unless I configure those apps to store their configs in an encrypted dataset)?
Is it really no longer advisable to do full pool encryption for a single passphrase unlock of the pool and all its child datasets that inherit the encryption?
I was also curious as to what happens on boot with full pool encryption with apps before the pool is unlocked, do they simply fail to start and error out?
Likewise, what happens if I follow the documentation guidance and only encrypt a child dataset that I have configured for the apps to store their data in? On boot and before unlocking the child dataset, do the apps/containers fail to start, or do they start and default back to the .ix-applications dataset for their storage?
The ix-apps dataset is always created unencrypted. Even if you do a “full pool encryption” you will end up with an unencrypted ix-apps dataset. Note that there is no “full pool encryption” in ZFS. It’s not like LUKS where you can encrypt entire hard disks. ZFS Encryption is always on a per-dataset basis.
You shouldn’t store application data inside the ix-apps dataset. Store them in your own dataset where you can control encryption. Docker config will be stored unencrypted, there doesn’t seem to be a easy way around that.
If you try to start an app that has volume mounts that reside on a locked dataset then yes, that will error out. It doesn’t automatically fallback and change the configured storage paths, that would be a recipe for disaster.
If you have datasets which you manually unlock (using a passphrase) and you have docker containers which store data inside those datasets then you may want to set the container restart policy to no or on-failure to prevent errors on boot.
You can still have “single passphrase unlock” even if you don’t do a “full pool encryption”. You can create a single encryption root (maybe tank/enc) and then create all other datasets as children of that dataset. When you unlock the encryption root it will automatically unlock all children.
EDIT: Fixed some inaccuracies related to docker config.
EDIT2: ix-applications → ix-apps (thanks @LarsR)
The ix-application dataset was only used with dragonfish or older (with the old kubernetes backend)
With fangtooth or newer it’s now the idden .ix-apps dataset that gets created and used.
So I will go the way of pool unencrypted, and a dataset with encryption, and sub-datasets under that - Also creating a single dataset for each of my arr containers to use for its config.
Thanks for the tip about container restart policy! I’ll try to find that and set it to no, as you suggested.
