up to version TrueNAS-24.04.2.3 TrueNAS with cryptsetup and dm_mod.so was useful and recommendable. After that they tried to clean it up - unfortunately not very successful…
TrueNAS isn’t a general purpose Linux (or FreeBSD) distro. For storage, it’s ZFS, and ZFS only.
The presence of other modules or libraries is not indicative of what TrueNAS offers or how it’s “recommended” to use.
not understood, it’s about mounting - and data transfer , i really didn’t expect - basic functionalities (like mounting encrypted drives , or non encrypted drives like ext4) to be discussed here - for a nas system this should be state of the art. i don’t see the problem - what is artificially described here .
There are two supported means of data transfer in TrueNAS: to or from a mounted ZFS pool, and over the network. You managed to hack together an unsupported method, and now it doesn’t work any more. Too bad for you.
My grief is limited - there are alternatives. but your inflexibility seems unlimited
Understood.
Except EXT2/3/4 is not supported. So yes, in theory, those could be removed.
At one time, importing data from non-ZFS external disks was supported. However, too many people had trouble with, or lost ACLs, permissions and extended attributes which caused grief among users. So the only supported data import method today is via the network.
Yes, it would be nice to have a general purpose OS that has great NAS abilities, along with Apps and VMs. But, TrueNAS SCALE is a targeted appliance firmware.
While iX has added features and fixed bugs that only affect free users, (like many SOHO), larger features really seem to need a purpose for Enterprise Data Center users, (the ones who pay for development via purchases & support contracts).
1 Like
i can understand this answer. the sadness is limited to the fact that it was not foreseeable - for me - that a simple luks mount (which is not to be regarded as elaborate and complicated) - after so many versions - is suddenly gone.
You appear to misunderstand what is going on here.
You are talking to community members, ordinary people whom have no special relationship in iX.
They have tried to explain to you what iX has said and communicated regarding LUKS, and in the later posts - other filesystems, on TrueNAS. You don’t need to change their mind, you would need to change iX’s mind and you still haven’t posted a proper Feature Request.
That said, my understanding is that iX has already made they intent known on this issue in an older Feature Request linked earlier in this topic.
This is not my opinion, this is my understanding of the facts.
1 Like
thanks for the clarification. i will follow the advice.
answer like a teacher, and yet only elementary school students 
I’m now also hitting the issue around the lack of dm_mod for mounting existing external drives.
I have historical backups on luks encrypted xfs drives which I can no longer access directly from my TrueNas box. This considerably reduces the effectiveness of TrueNas as my primary home storage and workload server.
I understand the focus around ZFS, but I really don’t understand the removal of standard basic linux capabilities like dm_mod. For example if I’m troubleshooting a VM issue I often use a range of device mapper centric tools to access the VMs filesystem to resolve issues.
This isn’t a question of “implementing Luks”. The fact is Luks is a default part of almost every existing Linux distribution and should be included as part of TrueNas.
It is reassuring to see that there are still users who have high expectations for an operating system. Fundamental components such as the file system and encryption are typically improved over time and only removed when they become obsolete or are no longer maintained.
The argument that thousands of hours of testing would be required to ensure safe operation is completely absurd! Countless distributions worldwide use LUKS and XFS and have shared their experiences in forums. The core features of LUKS and XFS continue to exist in these distributions.
The claim that the entire system would be affected is entirely unreasonable—especially when the modules are loaded only when needed, naturally via the command line. No one demands that these functions must be available in a graphical interface! The user should be able to decide whether to activate a module for LUKS or XFS based on their individual needs.
It would be desirable for someone from the core TrueNAS development team to provide an expert statement on this topic. The arguments against it so far seem superficial and overly theoretical—they lack depth
1 Like
It’s not marketed as a general OS or distributions.
It’s marketed as an appliance.
That sets the groundwork for what kind of flexibility one can expect.
Perhaps you would be better suited by using straight up Debian with zfs?
It’s about maintaining the quality of TrueNAS.
If programming is done professionally, either LUKS is implemented completely, or not at all.
Cryptsetup is usable, but the dm_mod module is not.
Now, explain the professional logic behind this.
I haven’t understood this logic. 
Do you have two different accounts?
Why?
shango02 belongs to the group shango with several people.
no reason to worry
Title: Reminder: TrueNAS SCALE – Today dm-mod.ko, tomorrow your feature?
This is not the first time I’m bringing this up.
I want to make it crystal clear once again, because it seems the core issue is still being overlooked.
The facts:
Up to and including TrueNAS‑SCALE‑ElectricEel 24.10 [release]:
dm-mod.ko was present → cryptsetup worked as expected.
ls -l /lib/modules/$(uname -r)/kernel/drivers/md/dm-mod.ko
-rw-r--r-- 1 root root 521568 Oct 9 2024 /lib/modules/6.6.32-debug+truenas/kernel/drivers/md/dm-mod.ko
From TrueNAS‑SCALE‑Fangtooth 25.04 [release] onwards:
dm-mod.ko is gone → cryptsetup luksOpen is impossible.
ls -l /lib/modules/$(uname -r)/kernel/drivers/md/dm-mod.ko
ls: cannot access '/lib/modules/6.12.15-production+truenas/kernel/drivers/md/dm-mod.ko': No such file or directory
The result:
- LUKS formatting (
cryptsetup luksFormat) is still allowed. - LUKS opening (
cryptsetup luksOpen) fails because the device‑mapper module cannot be loaded.
Example:
cryptsetup luksOpen disk TEST
Cannot initialize device-mapper. Is dm_mod kernel module loaded?
The contradiction:
TrueNAS still lets you encrypt – but removes the very module you need to decrypt.
That’s like selling you a safe, letting you lock it, and then taking away the key the first time you try to open it.
Yes, there are workarounds:
Rebuilding the kernel, running in a VM, manually adding modules – all possible.
But that’s not the point.
The point is that a core function, present in previous releases, has been deliberately removed – without any official explanation.
To the community:
Today it’s dm-mod.ko. Tomorrow it could be another feature, quietly disappearing without notice.
If you shrug it off now, don’t be surprised when it’s your workflow that breaks next.
To the developers – and I mean to Hans, not to little Hans:
If this was intentional: give us a clear, technical explanation for why encrypted drives should now be blocked.
If it wasn’t: put dm-mod.ko back into the kernel build immediately.
And remember: “Community Edition” doesn’t mean removing features without telling the community.
Your repeating this six months later doesn’t make it any more true. LUKS is not, never has been, and in all likelihood never will be “a core function” of TrueNAS.
Moreover, TrueNAS tells you every time you log into the shell that the only supported way of doing things is through the API and middleware (which includes the GUI, because the GUI uses the API). Doing anything else to the system risks unexpected results. If you want a system that you can modify to your heart’s content, that system is something other than TrueNAS–perhaps consider moving to vanilla Debian as @rungekutta recently did.
There’s enough trouble with iX messing with officially-supported stuff; IDGAF about their breaking things you shouldn’t have been using in the first place.
1 Like
Since you parrot the same arguments as you did months ago even though the variables have not changed and iX made their stance clear last year, it only seems fair to make this argument:
Imagine LUKS was a parrot.
This is the current state of LUKS in TrueNAS:
You’re welcome.
1 Like