[Not Accepted] Support for LUKS

Feature Requests
,
1

Problem/Justification
(What is the problem you are trying to solve with this feature/improvement or why should it be considered?)
Absence of dm_mod prevents mounting LUKS encrypted drives for offline backup

Impact
(How is this feature going to impact all TrueNAS users? What are the benefits and advantages? Are there disadvantages?)
Impact: for normal user probably none
Benefits: you’re be able to mount LUKS drives for offline backups for example so you can have encrypted backup drives just laying anywhere
Disadvantages: none from what I can tell

User Story
(Please give a short description on how you envision some user taking advantage of this feature, what are the steps a user will follow to accomplish it)
User want’s to have offline backups that are encrypted and doesn’t want to write scripts for making gpg encrypted tars, so he makes a LUKS encrypted drive, which he mounts and rsyncs his backups there. Command line would be fine, but for the more average not so technical user who doesn’t want to mess with commandline a GUI solution would be nice.

2

But ZFS already supports native encryption?

3

And SCALE does not really support any other file system… I mean you could likely use EXT2/3/4 or potentially FAT / exFAT, but they are not supported.

4

I know, that TrueNAS is built around ZFS and I really like it, but it would be nice to have more options for encrypted offline backups just because of backward compatibility with legacy systems or just systems without zfs support. Given, that there are all nessesary tools present for LUKS except of that one kernel module…

5

Except that LUKS without a supported non-ZFS file system, would be less useful.

As an example, say iX starts supporting LUKS on SCALE. You start using EXT4 on top of LUKS. At some future date iX removes EXT4, (regardless of why). And since it was never an official supported file system, you have to jump through hoops to restore functionality.

What I am trying to say, is that the only supported file system at present is ZFS.

If you want X, Y or Z, (aka EXT2/3/4, XFS, FAT, or exFAT), make that clear TOO.

The targeted clients for TrueNAS, SCALE or Core, are Enterprise Data Center users. They want / need high reliability not extreme customizations. The result of this is more tightening down of SCALE's OS. For example, making certain mount points R/O, (Read Only) and not allowing out of normal update package installs.

iX did start work on a developer mode that does allow MANY things. However, the converse to that is any bugs would have to be repeated on a “clean” install to be sure that user did not corrupt their OS. And if developer mode ends up being required for the user, they can’t easily get assistance with bugs.

1 Like
6

Ah I see, ye, I’d use ext4, but given that iX want’s to target enterprise then in that context it doesn’t make much sense. But it would be nice to have an option at least for setting up offline backups on single disks with encrypted zfs in GUI, so small businesses (my case) could do it.

On a tangent, I’m experiencing some issues with ACLs because it looks like TrueNAS is not built for it the way I use it (migrated from legacy fedora machine with a mess of ACLs)

7

Make a thread about it and see if someone here can offer assistance.

8

Nothing prevents creating a ZFS encrypted pool on a single drive in the GUI, replicating to it, and then exporting the single drive pool.
The offline backup is readable by any system which can mount ZFS.

4 Likes
9

One thing to consider is that ZFS always encrypts per dataset. Even though the encryption root can be the same, a different underlying encryption key is always used. It is randomly generated when creating an encrypted dataset and cannot be changed. The user-facing key just allows ZFS to access that underlying key and makes it possible to easily change the user key (per dataset) without needing to re-encrypt it.
However, this means block cloning between encrypted datasets is impossible, as the underlying encryption key cannot be manually set.
With block cloning, you can instantly copy and/or move files between datasets on the same pool. This is not possible with encrypted datasets.*

With LUKS, the entire hard drive is encrypted as-is (and dataset names would be hidden, which can contain information like names).
This would make block cloning possible with encryption.

I’m not saying we really need LUKS in TrueNAS, just wanted to give my thoughts about a possible advantage.

*Note: Block cloning is only possible between encrypted datasets that share the same underlying encryption key, so only for snapshots, the original dataset, and clones of snapshots.
You can indeed snapshot an empty encrypted dataset, clone it to multiple datasets, and make block cloning work between those encrypted datasets, as they now share the same underlying encryption key. That’s not a good solution though due to multiple reasons though…

10

+1 for adding LUKS support back, for the following reasons:

  1. Every version of TrueNAS SCALE supported it up until the latest version, so there are people using it.
  2. The cryptsetup binary is still included in the latest version (but is now apparently useless).
  3. It is not unreasonable for a storage server to understand multiple filesystems, including encrypted ones.
  4. Encrypted ZFS leaks all kinds of metadata and therefore won’t solve all use cases where security is important.

If iX wants to target enterprise customers, the worst thing they can do is to continue randomly removing features between releases. No right-minded CTO is going to say, “I’d love to switch my company’s storage solution to a product that might randomly delete a critical feature that we rely on in 6 months.”

“Oh, you’re using Docker containers? Well we just removed Docker in favor of K3s, so now you get to work on migrating all your stuff to it. Oh, you migrated to K3s last year when we got rid of Docker? Well guess what, we’ve just switched back to Docker and removed K3s support (24.10) so you need to migrate back again. Oh, you use the apps infrastructure that we built? Well guess what…”

I’m just a hobbyist, but it’s still annoying as hell to figure out the hoops I have to jump through every 6 months when I need to upgrade TrueNAS. I guess it’s nice that they reverted back to Docker with Eel (so I can remove the jlmkr hack that I had to set up last year just so I could run the docker binary after they removed it), but it would be even nicer if they hadn’t stopped supporting this very common use case.

And now apparently I need to create a Linux VM and add a USB passthrough device to it just to be able to mount the encrypted external drive that was mounting just fine for several years up until last week, and then I need to figure out how to change my workflow/scripts to rsync my files to it over the (virtual) network because I can’t just move them from one directory to another anymore.

11

Yes, it is unfortunate. ZFS was not originally designed with encryption in mind.

However, adding LUKS, (or for that mater, re-instating GELI encryption for Core), can cause reduced reliability. ZFS was designed and heavily tested with direct access to the disks. That means no hardware RAID, no external logical volume manager and no external software based encryption.

The reasons for direct access are multiple. The biggest is that ZFS wants things written in order that ZFS determines. This is key to both COW, (Copy On Write), and ZFS’ data integrity. Meaning the last thing updated on disk / pool, is the Uber blocks which are at the top of the file system.

This allows any write to be aborted without damaging the pool. ZFS is always consistent on disk. Of course any write that is aborted would be lost. Yet that happens on every single file system out their, (in varying degrees).

To be clear, I don’t know that LUKS would interfere with ZFS’ order of writes. Nor do I know if it would occasionally corrupt a pool. That is the point, it was never a supported feature, thus never thoroughly tested. And likely never will be thoroughly tested.

I am not trying to stop anyone from using ZFS on top of LUKS. I just want people to understand that this would be uncharted territory. If a pool can’t be imported, their may be less trouble shooting we can do. Go into this with your eyes open.


PS - SCALE never supported Docker before Electric Eel. It may have worked in the beginning, but was not a supported feature. So same issue, GUI never supported it.


Edit: In my epic response, I forgot that one of the posters for adding LUKS would be using EXT4. So some / most of my comments about ZFS on top of LUKS don’t apply.

However, TrueNAS never supported EXT2/3/4 directly. SCALE never supported anything but ZFS. FreeNAS, TrueNAS Enterprise, & TrueNAS Core did support UFS for a while in parallel to ZFS, but later versions deprecated UFS.

2 Likes
12

The “later version” was FreeNAS 9.3, released in 2014. FreeNAS 9.2 supported creation of UFS volumes, but 9.3 didn’t. And, as you say, it’s never supported any other filesystem.

13

There was some limited support for importing data from EXT#, UFS, MSDOS and NTFS disks in previous iterations.

That is no longer possible, and hasn’t been for quite some time.

14

Thank you for your suggestion but iXsystems does not currently have any interest in implementing LUKS in the foreseeable future.

In order to release votes and not drag the discussion we have archived this discussion for now.

Thank you for understanding.