Description: I would like to request that dm_mod.so be included in TrueNAS as it is a core piece in using cryptsetup and LUKS. It was previously included and in 24.10.2 was removed. This vote would be to support bringing back the dm_mod.so file so that cryptsetup can manually be used.
With this, but not the primary reason, I also propose that support for the transfer of large hard drives in TrueNAS be improved. Specifically, the hardware of today’s NAS systems with USB 3.2 (e.g., UGREEN DXP4800 Plus) should contribute to performing data backups outside the network efficiently. Additionally, support for mounting LUKS-encrypted drives with ext4 filesystem should be reinstated. This functionality does not necessarily need to be accessible through the GUI; the ability to perform this via the console, as in previous versions, would suffice.
Benefits:
Increased Data Transfer Speed: USB 3.2 offers faster data transfer rates, significantly speeding up the transfer of large amounts of data.
Enhanced Security: Support for LUKS allows secure encryption of drives, protecting sensitive data from unauthorized access.
Compatibility: Many users utilize ext4 as the standard filesystem for their drives. Supporting this ensures seamless integration and usage.
Flexibility in Data Backup: With the support of modern NAS hardware, users can directly connect large hard drives via USB 3.2 and perform data backups outside the network.
Versatility: The ability to mount LUKS-encrypted drives with ext4 filesystem provides users with more options for secure and efficient data management.
User Story: As a TrueNAS user, I want to be able to connect large hard drives via USB 3.2 to perform data backups outside the network. Additionally, I want to mount LUKS-encrypted drives with ext4 filesystem to securely store my data while benefiting from the performance and reliability of ext4. This functionality does not necessarily need to be accessible through the GUI; the ability to perform this via the console, as in previous versions, would suffice. This allows me to transfer data faster and make the backup of my important data more efficient and secure.
Implementation Details:
Integration: Support for USB 3.2, LUKS-encrypted drives, and ext4 filesystem should be seamlessly integrated into TrueNAS.
Documentation: Detailed documentation on using these features should be provided to facilitate users’ getting started.
Voting Option: This topic includes a voting option. Each forum user has a limited number of votes that can be cast for this feature at any time. The higher the user’s trust level, the more votes they can cast.
As mentioned before, LUKS is not supported, and it appears it won’t be. However, regular USB-connected ext4 drives are supported just fine; that’s how I do backups currently, since it’s much faster than doing a backup to a USB drive over a GbE connection.
basically it is not a request for a new function. during the cleanup dm_mod.so simply fell victim. this module is essential for cryptsetup , it is just a hint: “either pregnant , or not”. a little cryptsetup for formatting is nonsense if it cannot be mounted ! no big development environment has to be created to enable this function “AGAIN”. just don’t forget dm_mod.so in the kernel as in previous versions
This is not what you proposed in the original posting here and it is very different. I am not sure if you can edit your original posting however if you are not able, if you send me a message with “exactly” what you would like the posting to say, I will be happy to change it for you.
And remember, you do need to solicit for the votes. 10+ votes almost guarantees serious consideration. Also adding a single kernel module is easy for iXsystem to include. iXsystems has been hardening the system and sometimes if affects certain people. So, unless it poses a security concern or there was some valid reason for removing it, iX may easily put it back in.
In TrueNAS version 24.04.2.3, the kernel module dm_mod.so was still present. Starting from TrueNAS version 24.10.2, only remnants of cryptsetup (during hardening) remain. There has been neither a roadmap announcement nor a release note about LUKS being removed as part of the hardening process.
The fact that this feature was not available in the GUI is completely fine. However, the sudden disappearance of existing functionalities without any announcements is alarming. The main issue here is the inability to load dm_mod.so when needed. Any help to address this would be greatly appreciated. Thank you for your support!
Feel free to make any adjustments or let me know if you need further assistance!
I made a change to the posting. If it is not what you desire, please provide something I can cut/paste and I will do that.
In the meantime, and I understand this is not ideal, have you tried to build and manually install the file? It is fairly (sort of) easy but you need to know what you are doing and you need to use Developer Mode. The real issue here is any upgrade of TrueNAS, it will be gone and you have to rebuild again. If you are having problems accessing your data, I believe this is still an option.
Thank you very much for your support and the changes - very well done! My English phrasing is limited. Yes, the option to use developer mode after each update would be Plan B. I don’t have the impression that this module negatively impacts the hardening of the system. Implementing the appropriate module would also be entirely sufficient - activation via insmod dm_mo.so is done manually. That would be a good compromise, wouldn’t it?
i hope and assume that the missing module is a bug and not a feature - something like that can happen. removing only the corresponding module without the cryptsetup tool indicates that it was not thought through to the end, or simply overlooked. i hope ixsystem can deal with the request honestly and respectfully. if no one votes - it was all for nothing
I would also really like to see the return for dm_mod
Like several others I use large external USB 3.x hard drives in rotation fo r backup where I have a large encrypted xfs volume and some rsync scripts.
Being unable to access this natively under TrueNas is incredibly frustrating and means I need to run these via a bastion host with appropriate SSH or Rsync access.
You’ve also remove a lot of file system support. Whilst I understand the need for an hardened appliance style approach there are times where being able to access data off an external device is really useful.
TrueNAS as an appliance is the way to look at this. Yes, they allow you root access, primarily for developer work, which users have used in the past do to things like mount drives that were not ZFS.
I don’t think the argument is should be do users have the need or why would they remove this feature. Anything that is only possible via shell with developer mode should likely be assumed to not be guaranteed as much as matter of convenience.
If you depend on unofficial functionality from some release that gets removed just don’t upgrade.
A very quick and performant solution here is to use a VM and NFS. I needed to migrate an encrypted XFS hardware raid array while I tried shoehorning through root first, it was the wrong approach. A VM took 15 minutes and was able to max out the raid card’s IO so there wasn’t really a slow down and able to use the exact versions of everything I wanted.
With most appliances you only have the external services to access them, IE SMB or NFS mounts. The more you use local shell or install features or make direct modifications the more likely it is a wipe and restore of the config on a clean OS install wouldn’t work.
I think as a filesystem based appliance it is especially important they limit the alternate file system support and try to keep file transfers through tested and expected methods. Technically one could do the inverse and use an alternate machine or VM to expose the drive via NFS to TrueNAS.
I am sure there are use cases a VM might not work but TrueNAS’s goal is not to provide solution for everyone, but to concentrate on their specialization and you have a myriad of services and APIs you can use to integrate with w/e other platforms you want.
Big oof stumbling over this while setting up a new box.
I am also affected and this is a deal breaker for me, unfortunately. I don’t require enterprise grade stability / support nor UI support. Just allow me to use my cryptsetup via the cli and I am happy to live with the consequences (as there seems to have been a discussion whether or not this shall be an officially supported feature - it does not have to from my point of view).
Also I’d highly appreciate if someone could point me in the direction of a howto for the aforementioned workarounds in a little more detail (rebuilding the kernel / adding the module on my own).
Many thanks for re-considering this one - as well as all your efforts I am freeloading on.
It is rather remarkable to observe the considerable spectrum of proposed solutions to technical queries within this forum. While certain contributors demonstrate profound expertise and offer precisely articulated resolutions, other submissions regrettably lack substantive technical foundation.
The most productive methodology for the presented issue undoubtedly lies in the systematic utilisation of the official Scale-Build environment accessible at GitHub - truenas/scale-build: TrueNAS SCALE Build System. This repository constitutes the fundamental basis for sustainable solutions, notwithstanding various forum contributions that might suggest alternative approaches.
Regarding practical implementation: The integration of the dm-crypt module necessitates a structured process encompassing the build environment, kernel configuration, and subsequent compilation. Experienced practitioners will immediately recognise the imperative for methodological precision in this undertaking.
Of particular importance is system stability: Any kernel modification may potentially impact future updates and long-term maintainability. Whereas superficial proposals frequently overlook these ramifications, substantiated contributions properly address such considerations through transparent risk assessment.
The most valuable discourse is ultimately characterised by technical depth, practical experience, and realistic appraisal of consequences - qualities which, regrettably, appear somewhat inconsistently represented in the current discussion.
I get the appliance approach. Yet, the whole point of a NAS is to store data, and that means data exchange, especially bulk import and bulk export, is key.
Say I have a pile of (old) external USB3/4 drives, formattedi n ext4, btrfs, ntfs, xfs, etc. then the ability to hook them up and transfer the data is kind of an existential function for a storage appliance.
For media professionals it would also mean hooking up card readers to dump major photo shoots or video rolls onto the device.
If fundamental file systems like ntfs, ext, btrfs, xfs, exfat, etc. or even LUKS are considered a security issue, then Linux has a major problem, and basing TrueNAS on Linux would be a problem.
Standard file systems should be supported for rapid data import and export. Classical difference between data center NAS and home/SoHo/workgroup NAS use cases.
Is there a reason using a VM wouldn’t do this easily? I had no problem becoming drive IO bound using a basic VM to offload data. If the argument is the hassle of setting up NFS shares for whatever truenas volumes you want to mount do the opposite. Create a VM that runs on an internal network only shared between it and truenas then a half dozen commands like:
mkdir -p /mnt/remote_disks
mount vm_ip_addy:/mnt /mnt/remote_disks
Now do whatever you want in the VM just put things under /mnt and you can now access it all just by using /mnt/remote_disks in truenas.
Heck someone could even create a simple TrueNAS app that was just an NFS server + all the filesystem tools for the common file systems to make it a near one click deploy (not that the dozen commands above are hard).
I would guess the truenas folks don’t do things for no reason so I am sure some user created some issue with direct mounting some filesystem other than ZFS at which point they took the effort to remove it.
