2024-09-15

Having started using the funny Dell Latitude 7490 that doesn't tolerate Linux, but that had a simple FreeBSD setup inteded for family rather than my main work computer, I wanted a better encryption for my homedir, within the already more crudely (simple pass, first level) encryption of the system.  The system has a root-on-zfs freebsd 14.1-r4, using one pool for everything. The pool is itself on a GELI encrypted partition, so there *is* a prompt for *that* password at the start of boot.  It's then convenient to use ZFS own encryption to give a further level for my specific data.  This worked well (not that I actually know or have tested whether the contents *are* encrypted - trust!). 


Remove the original volume from pool "zroot" 
# zfs destroy zroot/home/nt 

Recreate it, but encrypted:
# zfs create -o encryption=on -o keylocation=prompt -o keyformat=passphrase  zroot/home/nt 

On boot, all went smoothly: zroot pool was mounted and no fuss/error/passwordentry was given for the inaccessible volume.
The other volumes for the system and other users all mounted.  (It didn't feel totally obvious that it would be this way, 
given that some systems have panics or emergency consoles for failure of a mount, if not having a particular option of 
"noauto" or similar.)

Now, in our own time, provide the key to access this volume:
# zfs load-key zroot/home/nt 

It was then necessary to tell it to mount the unlocked volume:
# zfs mount zroot/home/nt 
   [or  zfs mount -a   for all]