Probably will be met with a “locked” root dataset of the storage pool, with errors and warnings about “Unavailable SMB share paths”. The System Dataset might start anew on your boot-pool (since it is inaccessible on the storage pool.)
You’ll then have to import your (“good”) keyfile to unlock the storage pool.
It’s the same thing that would happen if you removed the drives, installed them on a different computer, and then installed a fresh instance of TrueNAS. (The fresh instance of TrueNAS would have no such keyfiles on the boot-pool. Your storage pool would be “importable”, but would not auto-unlock any datasets, until you import the keyfile for the first time.)
EDIT: Life is good when a guy with “fart” in their name gives your post a “like”.
I know this used to be possible, but I thought upstream nixed that as a terrible idea that sort of worked by accident if you closed your eyes and ears and pretended edge cases don’t exist.
I created an encrypted dataset, and then created an unencrypted dataset underneath it. I’m able to mount, write files, read files, and use them normally. No warnings. ZFS allowed it. If I first mount the unencrypted child, and then unlock/mount its encrypted parent, then the path for my unencrypted dataset gets “overlaid” by the parent, since I reversed the order of mounting them. (Nothing happens to my data, but I cannot access it until I unmount the parent.)
I don’t think there should be any arbitrary restriction. Otherwise, a user can never access their data because of locked datasets further up the hierarchy? What if a parent dataset’s encryption key is lost? Or the passphrase is forgotten? If the child is unencrypted or encrypted with a different key/passphrase, then your data should still be accessible and mountable.
EDIT: Speaking of which. Does TrueNAS not allow unlocking a child dataset that is nested below a locked parent that uses a different encrryptionroot? If it does not prevent this, then its safeguard is inconsistent.
The main problem with “nesting unencrypted below encrypted” (which cannot be helped if your root dataset is encrypted, anyways) is that you can accidentally “overlay” your mount directories if the parent datasets are unlocked later or mounted in the wrong order.
For TrueNAS? This safeguard makes more sense. Sure. It’s an appliance and you don’t want to give your user a heart attack when they think “My files went missing?!”
But for vanilla ZFS? Leave us the power and flexibility, with the risks and caveats involved.
EDIT 2: I still don’t recommend anyone try this or implement it. I’m just arguing that even though it’s not a good idea, I still think it should be allowed for those who want to take a risk with such a granular setup that is prone to breaking.
