unable to mount file-based volume

[marbenn]

Expected behavior

After installing VeraCrypt using the official Debian 12 .deb package, a normal (non-root) user should be able to mount file-based volumes through the GUI, as was possible in previous versions.

Observed behavior

Mounting any file-based volume fails immediately with the following error:

mount: /media/veracrypt8: wrong fs type, bad option, bad superblock on /dev/mapper/veracrypt8, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.

The volume does not appear in VeraCrypt's volume list after the failed mount attempt. The decrypted block device (/dev/mapper/veracryptX) is created and immediately removed, giving no opportunity to inspect it.

After changing setuid bit, or executing Veracrypt as root it works alright.

$ ls -la /usr/bin/veracrypt
-rwxr-xr-x 1 root root 5574576 May 30 2025 /usr/bin/veracrypt

Changed to:

-rwsr-xr-x 1 root root 5574576 May 30 2025 /usr/bin/veracrypt

Without the setuid bit, VeraCrypt cannot perform the privileged operations required to create mount points and mount volumes when run as a normal user. Running VeraCrypt as root (sudo veracrypt) works correctly.

Steps to reproduce

1. Download veracrypt-1.26.24-Debian-12-amd64.deb from the official VeraCrypt website
2. Install via sudo apt install ./veracrypt-1.26.24-Debian-12-amd64.deb
3. Launch VeraCrypt as a normal (non-root) user
4. Attempt to mount any file-based volume through the GUI
5. Observe the mount error above
6. Confirm the missing setuid bit with ls -la /usr/bin/veracrypt

Workaround: manually restore the setuid bit after installation:
sudo chmod u+s /usr/bin/veracrypt

Screenshots

N/A

Your Environment

VeraCrypt version: 1.26.24
Operating system and version: Debian 12
System type: 64-bit

[idrassi]

@marbenn
Thank you for the report.

This may be related to a bug fixed yesterday in master by PR #1687. That fix is in the elevated core service path used by VeraCrypt when it needs root privileges:

sudo -S veracrypt --core-service

Your observation that sudo veracrypt or chmod u+s /usr/bin/veracrypt makes the issue disappear is useful because both cases bypass the normal sudo-launched core service path. I cannot say yet that this is the same bug, since your visible error is different, but it is close enough that testing current master is the best next step.

Please build current master on Debian 12 using the system-provided wxWidgets packages:

sudo apt update
sudo apt install -y git build-essential yasm pkg-config \
  libwxgtk3.2-dev libfuse-dev libpcsclite-dev dmsetup sudo

git clone https://github.com/veracrypt/VeraCrypt.git
cd VeraCrypt/src
make -j"$(nproc)"

Then restore the stock permission on the packaged binary and run the newly built binary directly as a normal user:

sudo chmod 0755 /usr/bin/veracrypt
./Main/veracrypt

Please try mounting the same file container from this locally built version.

If it still fails, please run these commands and paste the full output:

sudo -k
mkdir -p /tmp/vc-test
./Main/veracrypt -t -v /path/to/volume.hc /tmp/vc-test
dmesg -T | tail -n 80

Please also test whether mounting without the filesystem succeeds:

./Main/veracrypt -t --filesystem=none /path/to/volume.hc
./Main/veracrypt -t -l -v

Finally, please include the commit you tested:

git rev-parse --short HEAD

For reference, the official Debian packages install /usr/bin/veracrypt as 0755 by design. The main VeraCrypt process normally runs unprivileged, and privileged operations are handled by the elevated core service. Making the full VeraCrypt binary setuid root is not the intended fix.

[marbenn]

Thank you for the quick response. I tested the newly built binary from master (commit 401be81a) with following results:

CLI works with both binaries

• /usr/bin/veracrypt -t -v /path/to/container /tmp/vc-test → mounts successfully
• ./Main/veracrypt -t -v /path/to/container /tmp/vc-test → mounts successfully

GUI fails with both binaries

• /usr/bin/veracrypt (GUI) → fails with the original error
• ./Main/veracrypt (GUI) → fails with the same error

This suggests the issue is not related to PR #1687 but is specific to the GUI code path.

Output from requested commands

user@Dropbox:~/VeraCrypt/src$ sudo -k
mkdir -p /tmp/vc-test
./Main/veracrypt -t -v /home/user/Documents/Key-crypt-ext4 /tmp/vc-test
dmesg -T | tail -n 80

Enter password for /home/user/Documents/Key-crypt-ext4: 
Enter PIM for /home/user/Documents/Key-crypt-ext4: 
Enter keyfile [none]: 
Protect hidden volume (if any)? (y=Yes/n=No) [No]: 
Volume /home/user/Documents/Key-crypt-ext4 has been mounted.
dmesg: read kernel buffer failed: Operation not permitted

user@Dropbox:~/VeraCrypt/src$ ./Main/veracrypt -t --filesystem=none /home/user/Documents/Key-crypt-ext4
./Main/veracrypt -t -l -v

The volume /home/user/Documents/Key-crypt-ext4 is already mounted.
Slot: 1
Volume: /home/user/Documents/Key-crypt-ext4
Virtual Device: /dev/mapper/veracrypt1
Mount Directory: /tmp/vc-test
Size: 9.8 MiB
Type: Normal
Read-Only: No
Hidden Volume Protected: No
Encryption Algorithm: AES
Primary Key Size: 256 bits
Secondary Key Size (XTS Mode): 256 bits
Block Size: 128 bits
Mode of Operation: XTS
KDF: HMAC-SHA-512
Volume Format Version: 2
Embedded Backup Header: Yes

user@Dropbox:~/VeraCrypt/src$ git rev-parse --short HEAD

401be81a

Potentially relevant observation

From journalctl, after every failed GUI mount attempt the following line appears:

systemd[1]: tmp-.veracrypt_aux_mnt1.mount: Deactivated successfully.

This auxiliary mount does not appear when mounting via CLI. It may be that this auxiliary mount is being torn down prematurely by systemd before VeraCrypt can use it.

Environment

This is running in a Qubes OS AppVM on Debian 12, which may be relevant to the systemd behaviour observed.

Additional comparison

As an additional data point, I tested the official VeraCrypt 1.26.24 RPM package on Fedora 40 in a Qubes OS disposable VM and it mounted the same file container successfully via the GUI. This rules out Qubes OS as the cause and points specifically to a difference in the Debian package.

[idrassi]

@marbenn
Thank you for testing master.

The remaining difference is that the GUI uses saved default mount options from the user preferences, while your text-mode command doesn't load preferences. A saved filesystem mount option could explain a GUI-only mount: wrong fs type, bad option... error, especially for an ext4 volume.

Please first dismount the volume, then test the CLI with the same slot/mount point as the GUI:

./Main/veracrypt -t -d /home/user/Documents/Key-crypt-ext4

sudo -k ./Main/veracrypt -t -v --slot=8 /home/user/Documents/Key-crypt-ext4 /media/veracrypt8

If that works, please dismount and repeat with GUI preferences loaded:

./Main/veracrypt -t -d /home/user/Documents/Key-crypt-ext4

sudo -k ./Main/veracrypt -t -v --load-preferences --slot=8 /home/user/Documents/Key-crypt-ext4 /media/veracrypt8

Please also test the GUI with a clean temporary configuration:

mkdir -p /tmp/vc-clean-config
XDG_CONFIG_HOME=/tmp/vc-clean-config ./Main/veracrypt

If the clean-config GUI works, then the issue is certainly in the existing user preferences. Please check Settings > Preferences > Mount Options, especially "Filesystem mount options". For an ext4 volume this field should be empty.

Finally, after a failed GUI mount, please run:

sudo dmesg -T | tail -n 80

and paste the output.

[marbenn]

Mea culpa... In all the testing I have done in this environment with Veracrypt, Wine and Totalcmd I must have set the default Mount Options to Filesystem=ntfs at some point in time. After I made this blank, everything works fine and as expected without error messages. The thing that threw me off though is the fact that it would still work with root account and/or setuid bit, so I was searching in the wrong direction. Thanks for helping to debug this and hope it didn't cost you too much time.

[idrassi]

Thank you for the update.
No issues. Such investigations of user issues are always beneficial even when it turns out to be false positive.