Cryptsetup and dm_mod kernel module load

In TrueNAS-24.04.2.3, cryptsetup worked as expected.

In TrueNAS-24.10.2, cryptsetup is still available, but without the necessary modules, it becomes completely useless.

I did not expect cryptsetup to be run without modules. This issue has been present in the TrueNAS-24.10 version for several months. Hopefully, the issue is reproducible. Luks formatting is still possible, but Luks opening is not - I hope this is a bug and not a feature. Here is the error output: 'Cannot initialize device-mapper. Is dm_mod kernel module loaded? Or, have I missed something?

additional information which version was tested TrueNAS-24.10.2 SCALE

Welcome to the TrueNAS forums!

TrueNAS SCALE does not support Linux LUKS / crypt, never did. Only ZFS dataset encryption. The fact that it worked means nothing, as it was not a supported feature. So it was “cleaned” up in a later release.

Now I understand Linux LUKS / crypt has advantages over ZFS dataset encryption. And could be quite useful. It is however, not a supported feature at present and the Enterprise Data Center users, (the paying ones), would not likely be using Linux LUKS / crypt.

TrueNAS is not the end all NAS. It is not even a Linux distro. TrueNAS is appliance like software / firmware, designed for a specific use. And not all uses.


All that said, you can try and make a case for Linux LUKS / crypt in the Feature Request section of this forum. Then advocate for it and get as many people here to "vote" for it.
2 Likes

There was already a feature request which has been denied

1 Like

I understand that TrueNAS SCALE never officially supported Linux LUKS / crypt and that this functionality was removed to streamline the platform. However, I’d like to highlight that this feature was extremely beneficial for many users, including myself.

Why should Linux LUKS / crypt be supported?

  1. Flexibility and Versatility: Linux LUKS / crypt offers a well-established and widely-used encryption method that can be applied in various scenarios. Supporting this feature would make TrueNAS an even more versatile solution.
  2. Security Advantages: LUKS / crypt is known for its strong security features. Many users rely on this technology to protect their data. It would be fantastic to see this proven security technology integrated into TrueNAS.
  3. Broader User Base: While TrueNAS targets specific use cases and enterprise users, there are many home and small business users who would benefit from LUKS / crypt support. A broader user base could improve overall feedback and development of the platform.

In the context of the TrueNAS forum post, you could argue that the removal of the Linux LUKS / crypt support is a classic case of “verschlimmbessert.” The developers intended to clean up the platform and enhance its stability by removing an unofficial feature. However, for users like yourself who relied on this functionality, the situation has actually worsened instead of improved.

If you read my responses in the linked declined Feature Request by @LarsR, you would see that using ZFS on top of LUKS could cause data reliability issues. Unless thoroughly tested, as in hundreds to thousands of hours, including mid-write power offs, their is no reason to think ZFS will be stable on top of LUKS.

Worse, any change to LUKS would then require the same testing to make sure the LUKS change did not introduce something that bites ZFS but not other file systems. (ZFS is COW, Copy On Write, AND in a specific order for those writes!)

If the intent is to use another file system on top of LUKS, TrueNAS Core or SCALE does not really support such. And has not since 2014, (again it’s in the linked Feature Request).

And the official response could also be:

Did the GUI or command line Middleware support LUKS?

Since it did not, it was never “an unofficial feature”.

1 Like

TrueNAS and the Lack of GUI Integration for cryptsetup: A Step Backward?

Is cryptsetup being removed from the system simply because it’s not implemented through the GUI? When I was searching for a NAS solution, I was convinced by the complexity of the TrueNAS console. It was precisely because cryptsetup was part of the operating system that I chose TrueNAS. My hard drives have been encrypted with cryptsetup for years – and without any problems – why would there be?

Suddenly, a new update is released – and the function is simply gone. And not even completely gone: Formatting still works, but opening (luksopen) doesn’t. I hope other functions don’t simply disappear as well. Other NAS solutions expand their functionality, and one can rely on that. The GUI can’t be the only standard, can it?

I imagine more Linux utilities being removed simply because they’re not offered in the GUI. This means that after every update, all user-specific scripts would need to be checked to see if they still work. That’s a scary thought. Especially in the area of encryption, which concerns data integrity, each person is, of course, responsible for themselves. What about external (luks) drives that need to be mounted? Just because the GUI doesn’t provide for that – what kind of logic is that? External LUKS drives don’t necessarily have a connection to the ZFS filesystem – what a misconception! ZFS and LUKS coexist peacefully in the Linux world!

It’s claimed that TrueNAS is flexible and provides a stable environment. Currently, it’s rather shaky; what works today might not work tomorrow.

What about them? Why should TrueNAS cater to them?

TrueNAS supports one filesystem: ZFS. The last vestiges of anything like support for other filesystems were removed when the “import disk” function went away. My crystal ball is in the shop, but I don’t see this ever changing.

Encryption concerns data integrity, at most, only very tangentially. Yes, there are cryptographic (or crypto-adjacent) processes that ensure integrity (or at least alert to its loss), but encryption primarily concerns data confidentiality. And ZFS, and thus TrueNAS, fully supports encryption. You’ve just chosen to do it in a manner that’s never been supported or even recommended.

iX have never claimed that TrueNAS provides a stable Linux CLI environment; their message has been consistently (and increasingly) to the contrary. And yes, it is flexible–but that always has his limits.

2 Likes

Half Measures Won’t Work - half pregnant does not exist…

Unfortunately, there is only one viable option: either completely remove cryptsetup (to avoid the impression that the dm_mod.so module is present) or keep this small module available. I haven’t found a single post in the forum reporting an issue with LUKS (in the CLI). By the way, this feature could also create excitement among TrueNAS users. You can find more information here: Unraid OS Data Encryption.

There are many people out there who have the same requirement (for example, simply mounting a LUKS data carrier) – but not everyone has the time to discuss half-installed packages in the forum. Take the opportunity to maintain functions with simple means that are not even discussed elsewhere.

Stay on course and provide clarity for everyone!

Unraid OS Data Encryption

Data Encryption

Unraid supports the use of encrypted drives in both the cache and the array. It does this using the Linux LUKS encryption modules.

LUKS is the standard for Linux hard disk encryption. By providing a standard on-disk-format, it does not only facilitate compatibility among distributions but also provides secure management of multiple user passwords. In contrast to an existing solution, LUKS stores all necessary setup information in the partition header, enabling you to transport or migrate your data seamlessly.

The initial reason for its inclusion in TrueNAS SCALE was to encrypt the swap partitions. Going forward, SCALE is disabling swap entirely. There’s no reason to include the module whatsoever.

Why are you posting something from the Unraid docs?

Is there a reason you think this is relevant to TrueNAS? You’re free, of course, to use Unraid if you believe it better meets your needs.

2 Likes

Thank you for your question. The reason I shared information from the Unraid documentation is that it provides relevant and useful insights into similar functionalities that could also be implemented in TrueNAS. It is crucial to consider various sources and best practices to continuously enhance your capabilities and ensure that TrueNAS offers the best possible service.

By comparing different approaches, valuable insights can be gained that contribute to improving the efficiency and effectiveness of your solution. My goal is to provide constructive input by sharing this information, so TrueNAS remains innovative and competitive. By learning from each other and adapting proven methods, you can collaboratively develop the best solutions.

For Unraid it makes sense to include it because unraid also supports xfs and btrfs, whereas truenas only supports zfs and zfs has native enctyption.

1 Like

Dear TrueNAS Team,

I didn’t mean to cause any stress, but rather to offer a suggestion. When cleaning up TrueNAS, it’s important not to discard everything that is useful. Your work is highly appreciated, and I understand the message that has been conveyed to me.

It’s not a big deal if some functionalities are removed, but it’s crucial to remember that there are alternatives available. Thank you for your understanding and your continued efforts to improve TrueNAS.
Best regards

This is completely out of context. Should we expect the ext3 and ext4 file systems in TrueNAS to be phased out soon because only ZFS is supported? Does this mean that ext4 will no longer be mountable in the future? It’s important to clarify this misinformation because TrueNAS supports multiple file systems, each with its own use cases and benefits. Relying solely on ZFS would indeed be limiting, especially given the wide adoption and specific advantages of file systems like ext4.

I mean this with no disrespect. After reading your latest reply, why are you using TrueNAS?

The information you wrote is either incorrect or outdated.

I think you might have the wrong impression of what TrueNAS is and what it offers.

1 Like

Hopefully one didn’t assume that a zfs file system should be encrypted with luks (nonsense) - I assumed that luks encrypted ext4 file systems would be mounted. I didn’t expect to have to describe this in detail here.