Updated: May 16, 2025
A few days ago, I encountered a rather bizarre yet highly interesting if frustrating problem. First, the circumstances. I connected an external hard disk containing an NTFS-formatted VeraCrypt container to my Slimbook Titan machine running Kubuntu 22.04. On this machine, I have both VeraCrypt and TrueCrypt installed, and the laptop's internal NVMe devices are both encrypted (LUKS). So far so good.
I then tried to mount the VeraCrypt container, and encountered all sorts of problems, including various mount errors, filesystem errors, and eventually, after I did succeed in mounting the container, a hard system lockup and kernel freeze during a simple copy operation. Fully repeatable with VeraCrypt, and as it turns out, with TrueCrypt, too. All right, let's debug, shall we.
Problem in more detail
For me, the ingredients that triggered the issue:
- Linux host (Kubuntu 22.04) with two encrypted internal disks. The first was encrypted during the system installation, the second separately, both using the Linux built-in LUKS/cryptsetup utility. The two internal disks show in the file manager are dm-1/2, and are mapped under /dev/dm-X, or /dev/mapper/dm-X, the latter being symbolic links.
- External disk with a single NTFS partition with a VeraCrypt (or TrueCrypt) container, also formatted as NTFS.
- The error manifestation is identical for whatever tool you choose - TrueCrypt 7.1a, the latest version of VeraCrypt that supports TrueCrypt containers (1.25.9 or 1.26.7) all the way to the latest available version of VeraCrypt (at the time of writing).
First, when you try to mount the container, you will see errors like these - again, please note, they are identical for both programs, so don't get hung up on which of the *crypts this is, or which mount point is specified.
The message text reads as follows:
Mount is denied because the NTFS volume is already exclusively opened. The volume may be already mounted, or another software may use it which could be identified for example by the help of the 'fuser' command.
device-mapper: create ioctl on truecrypt1 failed: Device or resource busy
Command failed.
ntfs-3g-mount: mount failed: Device or resource busy
The system log only shows a single entry:
/dev/mapper/truecrypt1: Can't open blockdev
/dev/mapper/veracrypt1: Can't open blockdev
The exact number of the truecryptX or veracryptX entry will depend on which mount point you chose in either program's GUI.
So, it seems there is a competition between LUKS/cryptsetup, which has partial, experimental support for TrueCrypt and VeraCrypt containers, and the programs themselves, over which one performs the mount operation. It seems the kernel is faster, which is why you get all those failures.
Indeed, the external devices show as if they are internal volumes, which is confusing - you may also not see any "safely remove" option:
I noticed you can sort of work around the mount problem by choosing a "higher" mount point, e.g.: instead of mount point 1 or 2, you go for 10 or 13 or similar. Basically, you want a number higher than the highest number of dm-* devices already mounted. But even then, you may get the "device busy" error.
The mount will actually succeed, but the containers won't show in VeraCrypt or TrueCrypt. And from that point on, it's up to the kernel to do the right thing. And apparently, with NTFS added into the combo, you will end up with some juicy system freezes.
Solution
As it turns out, both VeraCrypt and TrueCrypt have a handful of command-line options/flags, which can be quite useful. Notably, -m=nokernelcrypto allows these programs to mount volumes without handing control over to the kernel. For example:
sudo veracrypt -m=nokernelcrypto /volume /mount
Similarly, for TrueCrypt:
sudo veracrypt -m=nokernelcrypto /volume /mount
And that's it. Now, the volumes will show in your file manager as ordinary mounts, they can be safely removed, and you won't encounter any weird filesystem glitches or kernel freezes. The -m option works both for file containers, partitions and entire disks.
Conclusion
I encountered this issue while trying to copy a large volume of data from an external disk onto the laptop. So this was a time-bound operation, and you can imagine my frustration when the laptop froze mid-copy. With these kind of tasks, the last thing you want is a critical, data backup/recovery process to fail. Especially, since the problem is really avoidable, and in a way, self-inflicted.
Luckily, you can work around it by not letting VeraCrypt (or TrueCrypt) use the kernel's cryptographic libraries, but their own stuff. I tested and verified the fix with both the installable (deb) and self-extracting packages for both programs, with multiple versions. If you hit this issue, try the nokernelcrypto option. And that would be all. See you around, fellas.
Cheers.