Questions[veracrypt](ubuntu)

As of late I have discovered that the mounting of veracrypt volumes is supported natively by cryptsetup and systemd.

Since I seek a dual-boot fully-encrypted installation where all partitions are accessible by all systems, and LUKS can't be read from windows AFAIK, I decided to go in the rabbit hole that is installing Ubuntu manually to a veracrypt volume.

So far, I have achieved almost everything. I unsquashed the squashfs image the CD came with into the root partition, made a few configuration tweaks and got:

• A root filesystem with Lubuntu in /dev/sdb5 (An encrypted veracrypt volume),
• A /boot/efi partition in /dev/sdb2 (Unencrypted FAT32 partition),
• A shared /home folder located within /dev/sdb6 (Another encrypted veracrypt volume)

Since both the root and home partitions have the same password, I set up crypttab as such (supposedly the keyscript decrypt_keyctl shortly caches the passwords and passes it to subsequent calls):

# <target name> <source device> <key file>      <options>
ubunturoot      /dev/sda5       /dev/null       tcrypt,tcrypt-veracrypt,keyscript=decrypt_keyctl
sharedfiles     /dev/sda6       /dev/null       tcrypt,tcrypt-veracrypt,keyscript=decrypt_keyctl

And to mount the filesystems my fstab is configured as such:

#[Device]                [Mount Point]      [File System Type]      [Options]       [Dump]  [Pass]
/dev/mapper/ubunturoot   /                  ext4                    defaults        0       1
/dev/mapper/sharedfiles  /media/sharedfiles ntfs-3g                 defaults        0       2
/dev/sda2                /boot/efi          fat32                   defaults        0       2
/media/sharedfiles/Users /home              none                    defaults,bind   0       2

(And yes, I am aware that the shared files partition is not mounted directly to /home, that is the intended effect)

I have chrooted into the fs using a live CD, making sure to mount -B all of /dev, /dev/pts, /sys, /proc and /run from the live CD to the chroot.

I have successfully installed grub using grub-install without any errors. However, when trying to build an initramfs to reside in /boot/efi using

mkinitramfs -o /boot/efi/initramfs

I get the following output:

cryptsetup: ERROR: ubunturoot: Source mismatch
cryptsetup: WARNING: target 'ubunturoot_1' not found in /etc/crypttab
cryptsetup: WARNING: target 'ubunturoot_2' not found in /etc/crypttab
W: Possible missing firmware /lib/firmware/amdgpu/navi10_gpu_info.bin for module amdgpu

Some 10 more lines regarding AMD firmware, which I'm not particularly worried about, then

E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1.

I have looked through the internet for the "Source mismatch" line, and have not found much to help me.

I have gone to the mentioned script in the last line, found it prerequired another initramfs hook, then found the offending line and surrounding comments in /usr/share/initramfs-tools/hooks/cryptroot

# crypttab_print_entry()
#   Print an unmangled crypttab(5) entry to FD nr. 3, using CRYPTTAB_*
#   and _CRYPTTAB_* values.
#   _CRYPTTAB_SOURCE is replaced with /dev/mapper/$sourcename for mapped
#   sources, otherwise by UUID=<uuid> if possible (eg, for LUKS).  If
#   the entry uses the 'decrypt_derived' keyscript, the other
#   crypttab(5) entries it depends on are (recursively) printed before
#   hand.
#   Various checks are performed on the key and crypttab options, but no
#   parsing is done so it's the responsibility of the caller to call
#   crypttab_parse_options().
#   Return 0 on success, 1 on error.
crypttab_print_entry() {
    local DEV MAJ MIN sourcename uuid keyfile
    if resolve_device "$CRYPTTAB_SOURCE"; then
        if [ "$(dmsetup info -c --noheadings -o devnos_used -- "$CRYPTTAB_NAME" 2>/dev/null)" != "$MAJ:$MIN" ]; then
            cryptsetup_message "ERROR: $CRYPTTAB_NAME: Source mismatch"

I have tried to understand the surrounding script, but failed. I am barely understanding that the initramfs script concerning mounting an encrypted rootfs is failing, but I can't for the life of me find why.

Any other troubleshooting actions I can take to shed some light on this? If any commands are suggested, I'll run them and update on it.

I'm unable to run Veracrypt on 18.10 Cosmic, it says that gtk library is missing.

veracrypt: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

However, when I locate it, it is there, as a snap package

$ locate libgtk-x11-2.0.so.0
/snap/gnome-3-26-1604/70/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
/snap/gnome-3-26-1604/70/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30

How to make it work with snap libgtk?

VeraCrypt was apparently installed during the upgrade to 18.04, but won't open documents. VeraCrypt icon showed up. I tried uninstalling, then reinstalling VeraCrypt, and now the icon is gone, and typing 'veracrypt' (or 'sudo veracrypt') in the command-line now returns "command not found"

Good day everyone!

I've recently upgraded to Ubuntu-Mate Bionic 18.04 and now fighting new "features". Google has helped a lot, but this time I didn't manage to find a solution.

Every time I resume from sleep, VeraCrypt process dissapears and the previously mounted encrypted volume gets unmounted with no visible error messages. It's a simple file container located on main SSD, not on external drive.

I've used to put my laptop with Ubuntu 16.04 to sleep having a VeraCrypt volume mounted and had no issues after resume until swithcing to 18.04. It always resumed with VeraCrypt still running and the volume mounted. Now it's a clean install of Ubuntu-Mate 18.04 with all partitions reformatted, not just a dist-upgrade and this version has such issue.

This issue is terribly annoying as I can't use sleep mode because of it. First time it even lead to data loss as the volume just dissapeared despite it's been in use by a running program.

Will appreciate any advice on how to debug this. I can't even figure out if it happens while going to sleep or while resuming and, what is the most important, why does this happen.

Thank you!

A regular user is unable to mount a VeraCrypt volume without first authenticating with an administrator password. According to the original TrueCrypt documentation, the workaround is to give the user sudo privileges on the veracrypt directory.

Edit visudo and add USERNAME ALL = (root) NOPASSWD:/usr/bin/veracrypt

Source = Method 2 here

This is insecure and opens up doors for vulnerabilities at the root level.

Source: Is it secure to mount VeraCrypt without sudo password in this way | Security SE

How can a regular user safely mount a VeraCrypt container without needing the administrator password or having sudo privileges?

Or is it actually safe to add the above to visudo?