TrueNAS 13.0-U5 is Now Available

[eturgeon]

We are pleased to announce the release of TrueNAS 13.0-U5. This release includes one new feature that adds a method to report ARM status information from ACPI tables, and update of the Asigra and Iconik plugins to the latest publicly available release, several NVDIMM improvements, and fixes many issues found in earlier releases.

The improvements include:

• Enclosure management for the R50
• Asigra/Iconik release upgrade to 13.1-RELEASE
• NVDIMM reporting statistics
• NVDIMM 2666 Micron 2.6 firmware qualified

This release fixes a bug with dataset encryption where it was possible to create an encrypted storage pool or dataset and unencrypted datasets within that pool or dataset. Beginning with 13.0-U5, it is no longer possible to create an unencrypted dataset when the storage pool or dataset is created with encryption active. Datasets created in this manner are not affected by this fix. If the original intention was for the dataset to be encrypted, please migrate any data from the unencrypted dataset to a new encrypted dataset.

See the Release Notes for more details.

Release Notes: https://www.truenas.com/docs/core/corereleasenotes/#130-u5
Download: https://www.truenas.com/download-truenas-core/ and https://download.freenas.org/13.0/STABLE/U5/x64/

Thanks for using TrueNAS! As always, we appreciate your feedback!

 

[Patrick M. Hausen]

Try to catch up with upstream FreeBSD releng/13 for U6, please. There are important bhyve fixes that went into the code base recently.

 

[winnielinnie]

Beginning with 13.0-U5, it is no longer possible to create an unencrypted dataset when the storage pool or dataset is created with encryption active.

What was the reasoning behind this? ZFS supports nesting unencrypted dataset underneath encrypted datasets. You can even mount and access files in such an unencrypted dataset, even without unlocking the parent.

Say you have a parent dataset to house multimedia. You create is as an encrypted dataset. Within it you create several children (which all inherit encryption); however, one of them you create as unencrypted, since the files within don't need to be encrypted (as you would like anyone to access them, even if the pool is exported and the disks retrieved.

Now this level of flexible has been removed. It also means that those who already created their pools and encrypted the root dataset cannot create any new unencrypted datasets whatsoever.

Since this is not a ZFS limitation, why is it being enforced like this in the TrueNAS GUI?

 

[jlpellet]

Manually updated 5 systems from U4 without issue. Thanks. John

 

[NickF]

What was the reasoning behind this? ZFS supports nesting unencrypted dataset underneath encrypted datasets. You can even mount and access files in such an unencrypted dataset, even without unlocking the parent.

Say you have a parent dataset to house multimedia. You create is as an encrypted dataset. Within it you create several children (which all inherit encryption); however, one of them you create as unencrypted, since the files within don't need to be encrypted (as you would like anyone to access them, even if the pool is exported and the disks retrieved.

Now this level of flexible has been removed. It also means that those who already created their pools and encrypted the root dataset cannot create any new unencrypted datasets whatsoever.

Since this is not a ZFS limitation, why is it being enforced like this in the TrueNAS GUI?

Is there a usecase for this design that couldn't otherwise work with a separate dataset?

 

[Patrick M. Hausen]

4 systems updated, no issues. Thanks, folks.

 

[awasb]

Dito.

 

[winnielinnie]

Is there a usecase for this design that couldn't otherwise work with a separate dataset?

Starting with TrueNAS Core 13.0-U5, you are no longer allowed this flexibility if you've already created a new pool with "encryption enabled". (Which actually means your root dataset is encrypted.) Thus, you can never create any unencrypted datasets in this pool, even though ZFS allows this flexibility.)

This also applies to parent datasets created with encryption, but you later want to add an unencrypted dataset underneath.

So anyone who has already created a pool with the root dataset encrypted is out of luck, unless they destroy their entire pool and re-create it, but next time "plan out" where their unencrypted datasets will live in the hierarchy. Even if they perfectly plan it out ahead of time (somehow they know their future encryption requirements, like a sage), it forces them to use a logical grouping that is arbitrarily based on "encrypted versus unencrypted"; rather than their own unique requirements. (Perhaps they want to keep datasets, parents, and children grouped in a way to streamline their recursive snapshots because of a particular relationship between the parents and children, yet one of these datasets must have its files always accessible to anyone who acquires the drives; such as for archival reasons, future generation posterity, emergencies, etc.)

This new limitation of TrueNAS 13.0-U5 is enforced in the GUI / middleware. Yet ZFS itself has no such limitation on where you can create unencrypted datasets, regardless if the root dataset or parent is encrypted. (Yes, you can even mount and access unencrypted children that reside underneath an encrypted parent, even while the parent is still "locked".)

 

[winnielinnie]

The great irony of the above new limitation is that the opposite evolution happened in upstream ZFS a few years ago:

Allow unencrypted children of encrypted datasets by tcaputi · Pull Request #8870 · openzfs/zfs

When encryption was first added to ZFS, we made a decision to prevent users from creating unencrypted children of encrypted datasets. The idea was to prevent users from inadvertently leaving some o...

github.com

ZFS used to have this arbitrary limitation, until they fixed it to allow users more flexibility in where they can create unencrypted datasets. Especially if they already created an encrypted root dataset.

Now with TrueNAS, it's being undone...

 

[awasb]

Well … an annoyance. But as long as it works via CLI / shell terminal …

 

[morganL]

The great irony of the above new limitation is that the opposite evolution happened in upstream ZFS a few years ago:

Allow unencrypted children of encrypted datasets by tcaputi · Pull Request #8870 · openzfs/zfs

When encryption was first added to ZFS, we made a decision to prevent users from creating unencrypted children of encrypted datasets. The idea was to prevent users from inadvertently leaving some o...

github.com

ZFS used to have this arbitrary limitation, until they fixed it to allow users more flexibility in where they can create unencrypted datasets. Especially if they already created an encrypted root dataset.

Now with TrueNAS, it's being undone...

Hi, the reason for the change was when replicating an encrypted dataset to another system. The keys for that dataset don't necessarily go the receiver.. and there are complications. We'll look at improving the release notes.

 

[Kris Moore]

We ran into some issues in practice when using this setup, on failover or pool import (reboot), there was a set of conditions where the unencrypted dataset may end up inadvertently mounted to the wrong location, due to parent not unlocking. (Causing all sorts of other issues naturally with the shares that expected to live on top of this unencrypted dataset). We can look at this further if it becomes a major issue for users in the field though.

 

[winnielinnie]

Hi, the reason for the change was when replicating an encrypted dataset to another system. The keys for that dataset don't necessarily go the receiver.. and there are complications. We'll look at improving the release notes.

We ran into some issues in practice when using this setup, on failover or pool import (reboot), there was a set of conditions where the unencrypted dataset may end up inadvertently mounted to the wrong location, due to parent not unlocking. (Causing all sorts of other issues naturally with the shares that expected to live on top of this unencrypted dataset). We can look at this further if it becomes a major issue for users in the field though.

That makes sense, especially for an appliance.

I guess "TrueNAS is as TrueNAS does" is appropriate, since it isn't vanilla ZFS, but rather an appliance. The above situations can be avoided in vanilla ZFS if the user is aware of such implications and understands (or customizes) their mountpoints. (I've successfully done it myself on a non-TrueNAS Linux system.)

The way the release notes were worded came off as ambiguous. It refers to a "bug", but does not link to any ticket. It does not even explain the rationale for why it is important (from a TrueNAS perspective) to explicitly prevent someone from creating an unencrypted dataset that lives in a pool with an encrypted root dataset.

Because I'm not able to test something out with this release (since all my drives already exist in pools), does TrueNAS 13.0-U5 outright warn the user that it will be impossible to create any unencrypted datasets when they select the "encryption" checkbox option upon creating a new pool? If not, it absolutely should warn them of this, since you cannot "undo" an encrypted root dataset. (They may believe because of the new ZFS native encryption that they can always say "I'll just create an unencrypted dataset sometime later.")

 

[Kris Moore]

Yea, we missed including the correct NAS ticket on the release notes (I'll correct that now)

Here's the relevant fixes that were merged:

[NAS-121871] - iXsystems TrueNAS Jira

ixsystems.atlassian.net

NAS-121871 / 13.0 / Make sure unencrypted dataset cannot be created inside an encrypted dataset (by sonicaj) by bugclerk · Pull Request #11262 · truenas/middleware

Original PR: #11256 Jira URL: https://ixsystems.atlassian.net/browse/NAS-121871

github.com

Having the team check on pool creation scenario now, if its not properly alerting at creation time, we'll get a ticket made to add that.

 

[ThreeDee]

Update went without a hitch

 

[morganL]

Try to catch up with upstream FreeBSD releng/13 for U6, please. There are important bhyve fixes that went into the code base recently.

I assume you've seen some of these issues in your deployments?
Can you "report-a-bug" in Jira.
Documenting the specific fixes needed is useful.
Volunteering to test would be appreciated.

 

[Patrick M. Hausen]

FreeBSD: https://reviews.freebsd.org/D39620
iX: https://ixsystems.atlassian.net/browse/NAS-122108

Sorry - I just notice it's not yet in releng/13. Anyway it seems to work. So it would be great if you could incorporate it.

 

[Kelly Hays]

Can this release support FreeBSD 13.2 jails?

 

[Patrick M. Hausen]

Can this release support FreeBSD 13.2 jails?

Yes.

 

[Davvo]

Sucesfully updated; will remove the vfs.zfs.arc.meta_prune = 0 sysctl and report back any unusual ARC behaviour.