SOLVED How to best resolve this warning? "datasets are not encrypted but are within an encrypted dataset" [22.12.3]

[notsure]

The decision for ix-applications to be created unencrypted was intentional:

https://github.com/truenas/middleware/pull/9954

Bottom line is, ZFS encryption should be used for pretty static datasets. It's not great for parent datasets where lots of dynamic datasets are coming and going frequently, which is the case for ix-applications due to how containers are checked out and snapped.

Makes sense to me, thank you for pointing this out.

I saw the actual issue (warning generated, even though it works as intended) already has a PR. Thanks for resolving this minor annoyance quickly!

 

[notsure]

Unfortunately I'm not able to edit the issue to better reflect what the issue really is. Or maybe I just can't find it :)

 

[Ataraxia]

So, if this is the case, we need to clearly indicate that the ix-application dataset should be created in an unencrypted pool or parent dataset,

So lets report as a docs issue.....

Would this also extend to adjusting tooltips in the initial dataset setup UI for a pool's parent dataset (i.e. adding a message about 'when encryption is checked, apps cannot/should not be installed to this pool - either in the warning it pops when encryption is selected, or the help text on the question mark next to the option)? Or otherwise guardrailing it during initial apps setup (i.e. 'selected dataset is encrypted, please select another dataset' or similar)? Or is this just an update to the documentation pages?

Reason I mention it is that, as a new user, I walked into this issue within 5 minutes of initial setup by starting from an 'encrypt everything at rest' mindset. On one hand, no harm no foul, still early enough to tear it down and rebuild without significant pain. On the other hand, OOTB experience setting up a bad practice config without a warning until after the fact isn't good, either.

 

[sheps]

... so what do you all recommend I do? This would be great to know.

 

[morganL]

... so what do you all recommend I do? This would be great to know.

wait until we agree on a resolution.

I assume its working, but just providing a warning?

 

[sheps]

wait until we agree on a resolution.

I assume its working, but just providing a warning?

Yes, just a warning as far as I can tell. Thanks.

 

[sammael]

I "solved" the issue by moving the unencrypted dataset out from the encrypted parent dataset, and as the remaining children datasets were encrypted the warning went away. My original idea was to then replicate it back into encrypted child dataset, but my laziness got the better of me and I stopped once the warning went away (the particular dataset doesn't really need to be encrypted as it is the "public" smb/nfs share).

As far as I could tell it was just a warning since I had it like that and working for ages, so just a new safety check added in last version I think.

 

[morganL]

Yes, just a warning as far as I can tell. Thanks.

Yes, we've decided to remove the warning in 22.12.4

[NAS-122617] - iXsystems TrueNAS Jira

ixsystems.atlassian.net

The issues that exist are mostly related to HA configurations. So no need to fix quickly.

In Cobia, we will warn against making the whole pool encrypted.

 

[tuxsudo]

Can we get more clarity on why ix-applications is now forced to be unencrypted? Personally I have used ix-applications encrypted for over two years and never had any issues with it related to it being encrypted, including doing an apps pool migration once.

This change makes me dissapointed and makes me reconsider using SCALE for applications as I desire to have all my application's data encrypted. Seems to be a sensible thing to do, I can't possibly be the only one. I know I can probably do hostPath to an encrypted dataset for app data but that is a highly non-ideal and breaks rollback.

This recent change has caused a lot of confusion for me as I've created a backup server and initialized Apps, just to find out it was giving me warnings and created an unencrypted ix-applications dataset, ironically when the recent 22.12.3 update specifically prevents you from creating unencrypted datasets under encrypted datasets and pools.

 

[morganL]

Can we get more clarity on why ix-applications is now forced to be unencrypted? Personally I have used ix-applications encrypted for over two years and never had any issues with it related to it being encrypted, including doing an apps pool migration once.

This change makes me dissapointed and makes me reconsider using SCALE for applications as I desire to have all my application's data encrypted. Seems to be a sensible thing to do, I can't possibly be the only one. I know I can probably do hostPath to an encrypted dataset for app data but that is a highly non-ideal and breaks rollback.

This recent change has caused a lot of confusion for me as I've created a backup server and initialized Apps, just to find out it was giving me warnings and created an unencrypted ix-applications dataset, ironically when the recent 22.12.3 update specifically prevents you from creating unencrypted datasets under encrypted datasets and pools.

Most of the causes are related to supportability of complex systems. For complex systems that need all data encrypted, we typically recommend disk encryption to our customers.

If its an important need for you, please make a suggestion in the jira system and then report the ticket number here for others to upvote.

It's worth stating whether you need it as a UI option, or are you OK with a CLI option?

 

[TrueRandom]

@tuxsudo I totally agree. I usually run (docker) applications with access configured as environment variables. Now it's not enough anymore to use encrypted datasets as volumes because the access data for those applications is laying unencrypted on the disks.
An option to choose would be great, preferably on the UI. If there are considerations, they could be shown as a warning.

 

[tuxsudo]

I've posted a suggestion with an implementation example

[NAS-123318] - iXsystems TrueNAS Jira

ixsystems.atlassian.net