# fscrypt setup
# fscrypt setup /mnt/ext4fs
# mkdir /mnt/ext4fs/root_dir1
# fscrypt encrypt /mnt/ext4fs/root_dir1
[ERROR] fscrypt encrypt: encryption not enabled on filesystem /mnt/ext4fs (/dev/sda5).
To enable encryption support on this filesystem, run:
sudo tune2fs -O encrypt "/dev/sda5"
Also ensure that your kernel has CONFIG_FS_ENCRYPTION=y. See the documentation for more details.
#
Yes, I followed the suggested solution but it didn’t work:
# umount /mnt/ext4fs
# tune2fs -O encrypt "/dev/sda5"
tune2fs 1.46.5 (30-Dec-2021)
# mount /dev/sda5 /mnt/ext4fs
# ll /mnt/ext4fs/
total 20
drwx------. 2 root root 16384 Nov 4 12:22 lost+found
drwxr-xr-x. 2 root root 4096 Nov 4 12:26 root_dir1
# fscrypt encrypt /mnt/ext4fs/root_dir1
[ERROR] fscrypt encrypt: encryption not enabled on filesystem /mnt/ext4fs
(/dev/sda5).
To enable encryption support on this filesystem, run:
sudo tune2fs -O encrypt "/dev/sda5"
Also ensure that your kernel has CONFIG_FS_ENCRYPTION=y. See the documentation
for more details.
#
I’m running out of ideas here. At this point it looks like fscrypt is not really supported without doing some extra steps that I’m struggling to find.
Even a shoutout by someone in the community saying “Hey, I’m running Rocky9.x and got fscrypt working”, will be helpful.
I work at an University and researchers are asking for encryption (filesystem level, not block level) on Lustre shared volumes and also we need to certify some systems in order to get access to shared academic data. Fscrypt seems the right tool for that with kernel support and performance tuning. Going to another app in userland seems like a step back.
I also tried:
I installed Kali Linux on the same hardware and fscrypt worked straight out of the box. So, it’s not the hardware.
I installed Rocky10.0, comes with newer version of the kernel, compiled fscrypt from source (EPEL doesn’t have a package, why? is it considered less important?), and got the exact same behavior as with fscrypt on Rocky9.6.
Compared loaded kernel modules between Kali and Rocky. They are not one-to-one match but I tried to find something that can possibly hint for the missing piece but so far unsuccessful.
the above confirms that the kernel has the support for CONFIG_FS_ENCRYPTION, and also that ext4 has encrypt enabled on the partition.
That said, RHEL do have this: Does Red Hat support fscrypt for filesystem encryption - Red Hat Customer Portal which effectively states that they don’t support fscrypt or third party packages, and that they recommend that people use LUKS encryption. Even that we know third-party packages are not supported, there is obviously something missing that is blocking it. I’m guessing the crypt modules or lack therefore of the ones that fscrypt needs.
They were the ones I build using Fedora 42 source rpms, and then built on Rocky 9 with mock. After installation the problem was the same, despite the fact that the option is set in the kernel and encrypt being enabled on ext4.
Which leads me to believe what I hinted at before, that something else is missing from the kernel, most likely the encryption modules/algorithms are missing that fscrypt requires.
Without knowing exactly what fscrypt requires - and I’ve tried finding out by searching about this problem but nobody from fscrypt actually mentions what else needs to be enabled in the kernel other than the CONFIG_FS_ENCRYPTION option. Which doesn’t help much.
In reality full disk encryption is best, so things like LUKS. fscrypt still leaves unencrypted data on the system, metadata for one. So you cannot rely solely on fscrypt. The readme even suggests double-encryption (eg: LUKS + fscrypt) if the performance hit won’t be a problem. That said, it still wouldn’t work on RHEL/Rocky anyway.
I personally just use LUKS, I don’t have any need for fscrypt, but I realise other peoples requirements are different.
You may be better just using Debian instead unless you are going to put in the effort building a kernel until it starts working.
Hi Ian, Thank you for the effort and time you put into this. Appreciate it.
Full disk encryption solves a different problem. Fscrypt has it’s advantages in a shared environment like ours where different users can use their own keys to unlock the data, integration with file system level encryption and kernel encryption features, which should deliver better performance.
Anyway, we’ll have to look for another solution or a workaround this one (i.e. as you suggested, dedicated Debian based secure nodes for storing and accessing this data)
In case you do want to go the kernel compilation route, I figured I’d just check the Gentoo side (I used to use Gentoo and you compile the entire system basically), but this link does hint at what is required to be compiled into the kernel including the crypto modules: https://forums.gentoo.org/viewtopic-p-8629644.html#8629644
The majority of the post is in German, but all you are really after anyway are the options to choose in the kernel, which is clear enough to read. Basically you could recompile the Rocky kernel with those options built in and it may just be enough.