SOLVED That padlock icon

[glauco]

I have two zfs pools: MyVolume and replica.

MyVolume is my main pool. It's made up of two SSDs that I've set up as Self-Encrypting Drives (SEDs) by following the instructions at https://www.truenas.com/docs/core/coretutorials/storage/sed/ As you can see in the first screenshot, the Storage > Pools web page shows no padlock next to it.

The pool named replica was encrypted at creation time and is the target of my replication experiments. As I imported it and decrypted it, it shows an open padlock icon next to its root dataset (second screenshot). The dataset right below it, called MyVolume, is the target of a periodic replication task I've set up. As you can see, it has that padlock icon that means (quoting https://www.truenas.com/docs/core/c.../storageencryption/#encrypting-a-storage-pool ):
A Dataset on an encrypted pool with encryption properties that don’t match the root dataset have this icon:

NOTE: An unencrypted pool with an encrypted dataset also shows this icon:

At the command line, I can see the data in replica/MyVolume, so why do I get that icon? Is it because MyVolume is deployed on SEDs?
Should I be worried that I might not be able to restore replica/MyVolume if my main TrueNAS pool is destroyed?
What am I failing to understand?
Thanks.

 

[winnielinnie]

Native ZFS encryption is agnostic to SED encryption.

From ZFS's perspective, "MyVolume" is a non-encrypted dataset. (Even if the underlying devices are using SED encryption.)

The icon indicates that while your top-level root dataset "replica" is encrypted (with native ZFS encryption), its nested child "replica/MyVolume" breaks this inheritance as a non-encrypted dataset.

If you want to hide/protect the files found in "replica/MyVolume", then you need to either inherit "replica's" encryption property, or encrypt "replica/MyVolume" with its own encryption property. (It's too late now, as you'll have to destroy and replicate "MyVolume" -> "replica/MyVolume" all over again; unless you don't mind.)

 

[glauco]

Thank you @winnielinnie for clarifying that replica/MyVolume is actually not encrypted.
Still, how can one access replica/MyVolume without entering the key to decrypt replica?

 

[winnielinnie]

Still, how can one access replica/MyVolume without entering the key to decrypt replica?

They don't need to decrypt (unlock) replica. They simply import your pool. ZFS will automatically mount the available datasets. (Or the person can choose to manually mount whatever dataset they prefer, regardless of where the dataset "sits".)

replica will not get mounted automatically under the path /replica because it is still locked.

However, replica/MyVolume will automatically be mounted under the path /replica/MyVolume because it is not encrypted, and thus does not need to be unlocked (decrypted) before mounting.

The way the TrueNAS GUI behaves (and restricts the user)[1] gives a false impression that "nested" non-encrypted child datasets beneath an encrypted parent are somehow "protected" by the locked parent. They're not. This is just the way the GUI was designed.

It's better to think of each dataset as its own filesystem, regardless where it sits in the hierarchy. This means that non-encrypted datasets are always accessible, even if the TrueNAS GUI might fool you otherwise.

(You can try it for yourself in a modern Linux distro. Simply import the pool without unlocking anything, and you'll notice that the "locked" datasets are not mounted, yet the non-encrypted datasets are automatically mounted, with all their files accessible.)

My above scenario assumes that an unauthorized person (malicious or friendly) is using something other than TrueNAS to access your files. (Technically, they can still do it with TrueNAS if they bypass the GUI and just use SSH or the Shell.)

[1] It's actually good that the GUI behaves in this way (removing the ability to manually mount/unmount at will), since some new users might accidentally mount a parent dataset over a child's mount path.

 

[glauco]

This is shocking! Thank you for opening my eyes. Exactly like you said, I thought replica/MyVolume was encrypted just because its parent is...
So, in order to see with my own eyes, I imported replica without unlocking it, that is, I clicked "cancel" at this stage.

Now replica is locked and replica/MyVolume should be accessible because it isn't even even encrypted, but how do I access it?

zfs list | grep replica shows me replica/MyVolume and its child datasets, along with their mount points at /mnt/replica/MyVolume, but ls'ing any of those mount points throws error: No such file or directory. so are they really accessible?
Thanks.

 

[winnielinnie]

but ls'ing any of those mount points throws error: No such file or directory. so are they really accessible?

This is because TrueNAS has a layer on top of the operating system (Middleware and GUI) which does stuff under-the-hood to make TrueNAS act more like an appliance rather than a vanilla server/desktop.

Its "logic" will not mount a non-encrypted child dataset if the parent is not first unlocked and mounted. This is not a technical limitation: it's by design for TrueNAS. (Otherwise, it would open up a bunch of problems if users manually mount a child dataset, and then later manually mount its parent, which will replace the child dataset's own mount path. Users will complain "Why did my files disappear?" When in fact nothing disappeared; it's just that they mounted their datasets in the incorrect order. If you use ZFS on a "vanilla" non-appliance OS (such as Linux or FreeBSD), you can see this for yourself as you tinker with it. The OS will not stop you from doing things in the wrong order, nor "guide" you through it; unlike TrueNAS which does stuff behind the scenes to lower the chance of breaking things or creating confusion.)

That's why I wrote earlier (emphasis added):

My above scenario assumes that an unauthorized person (malicious or friendly) is using something other than TrueNAS to access your files. (Technically, they can still do it with TrueNAS if they bypass the GUI and just use SSH or the Shell.)

EDIT: If you want, you can use SSH (or use the Shell) to manually mount replica/MyVolume without first unlocking replica. This can be done with the "zfs mount replica/MyVolume" command. Keep in mind you're not supposed to use TrueNAS like this...

If you do try it out, make sure to unmount it before doing anything else (including "safe" things in the GUI), otherwise you can introduce uncanny issues. "zfs umount replica/MyVolume"

There's a reason why you don't see "mount" and "unmount" in the GUI. (Just an aside, when you select "Unlock" in the GUI next to a dataset, TrueNAS is issuing more than one command in a very specific order. It's loading the key for all dataset members of the "encryptionroot", and it's likewise mounting them.)

 

[glauco]

EDIT: If you want, you can use SSH (or use the Shell) to manually mount replica/MyVolume without first unlocking replica. This can be done with the "zfs mount replica/MyVolume" command. Keep in mind you're not supposed to use TrueNAS like this...

Thank you. I could successfully see the content of a replicated dataset after just mounting it.
With this knowledge, I went ahead and:

• destroyed pool replica
• created it again without native zfs encryption
• turned on encryption on the destination dataset in the replication task settings
• ran the replication task

Now it appears like this:

Is replica/MyVolume/videos encrypted?
There's no padlock icon next to it, but I guess no icon means its encryption setting gets inherited because

Code:

zfs get encryption MyVolume/videos replica/MyVolume/videos
NAME                     PROPERTY    VALUE        SOURCE
MyVolume/videos          encryption  off          default
replica/MyVolume/videos  encryption  aes-256-gcm  -

 

[winnielinnie]

There's no padlock icon next to it, but I guess no icon means its encryption setting gets inherited because

Another setback of the GUI if you ask me.

This matter of ambiguity has been brought up before, even with a feature request:

No padlock for Dataset with inherited encryption

Heya! Is it only me going into panic mode for a split of a second every time i see no padlocks near my encrypted datasets? My brain quickly realizes that it is because encryption is inherited (after my eyes are forced to check the parent/root Dataset). The concept with the icons is just weird...

www.truenas.com

[NAS-115096] - iXsystems TrueNAS Jira

ixsystems.atlassian.net

---

You can also display a flat view of your ZFS layout, and look at the "encryptionroot" property. An "encryptionroot" is a dataset where other dataset(s) inherit their encryption properties from. This also means they are locked/unlocked together as a family; not independently. (Yes, an encrypted dataset is its own encryptionroot if it is not inheriting its encryption properties from a higher-level dataset.)

zfs list -t filesystem -o name,encryptionroot

This does not affect the security of each individual dataset nor have an effect on the strength of encryption. It's a matter of convenience and "logically" grouping datasets together in the pool's hierarchy.

In your case, the top-level root dataset "replica" is non-encrypted, while "replica/MyVolume" is encrypted. You can consider the top-level root dataset as a "placeholder" for everything else, since you should never store data directly to it anyways.

 

[glauco]

I registered on atlassian.com just to upvote that proposal. Hopefully it gets approved!
Thanks for explaining encryptionroot.
Now that I know how to replicate to an untrusted pool, I can sleep better at night!

 

[winnielinnie]

I registered on atlassian.com just to upvote that proposal. Hopefully it gets approved!

I'm sure it had more votes before the Jira migration. I had to vote for it again just now.