Running AppImage on Fedora Silverblue - "Failed to obtain administrator privileges"

[LittleBlueBreeze]

When I run VeraCrypt (latest version, 1.26.24) as an appimage (installed via GearLever) on Fedora Silverblue (latest version, 43.2), it fails to obtain administrator privileges when I try and mount a volume and type in my administrator password.

Expected behavior

Volume should mount successfully

Observed behavior

Produces an error message "Failed to obtain administrator privileges"

Steps to reproduce

1. Install VeraCrypt as an appimage on Fedora Silverblue (or probably any atomic/immutable Fedora-based distro)
2. Try mounting a volume
3. Type in administrator password when prompted

Screenshots

Your Environment

Please tell us more about your environment

VeraCrypt version: 1.26.24, appimage

Operating system and version:

Fedora Silverblue 43.2

System type:

x86_64

My workaround for this right now is just to use an app called Main Menu to edit the desktop file / launcher for VeraCrypt to add 'sudo' to the default execution command so VeraCrypt always runs with sudo. It's not ideal because it doesn't remember any volumes I've mounted or respect dark mode

[andreas-1107]

Same experience here on Debian 12 Bookworm.
And thanks for the description of the workaround!

[diazbastian]

I have the same problem. I usually have VeraCrypt Containers or external flash drives encrypted with VeraCrypt, and I can mount them graphically with GNOME Disks. But I wanted to create new ones with the official VeraCrypt appimage, but since the creation process asks to mount the new volume, the process can't continue.

Bluefin (Version: 43.20260113)
VeraCrypt 1.26.24

[mouarfff]

Same behavior here in Linux Mint XFCE 22.3 with APPIMAGE version

No issue with the version from this Ubuntu's PPA : ppa:unit193/encryption

It's very difficult to find this version for a new user, they will think "it's no working and reliable"...

[LittleBlueBreeze]

So the AppImage is kind of wonky... it doesn't seem to always want to launch.

[Torben2000]

Might be of help for some people here:
As I read "AppImage" and "GearLever" this may also be related to #1628.
You can read in my comment that the filename (which is changed by GearLever) seems to play a major part in that issue.

[diazbastian]

Might be of help for some people here: As I read "AppImage" and "GearLever" this may also be related to #1628. You can read in my comment that the filename (which is changed by GearLever) seems to play a major part in that issue.

It actually worked, so I manually configured VeraCrypt by creating a custom desktop file. Anyway, I'm wondering if this is an issue with this particular appimage or a Gear Lever issue.

I'll see if there's a fix to avoid renaming appimages in Gear Lever, which would partially solve this problem, but it's the first time I've encountered something like this with an app in this format. I had already noticed some problems with VeraCrypt appimage, such as the app info and desktop icon not displaying correctly, and, most annoyingly, the window being completely locked and unable to be resized or maximized.

Cheers

[LittleBlueBreeze]

@Torben2000 @diazbastian, wow, thanks! Renaming the appimage from veracrypt.appimage to VeraCrypt.appimage does indeed do the trick.

definitely strange that the app only runs properly when it has those capital letters.

hopefully the developers of VeraCrypt and GearLever both see this.

[diazbastian]

So, as I suspected, this is more about VeraCrypt's AppImage packaging not adhering to the specifications correctly. The Gear Lever author indicates here that they don't plan any improvements, as it's not a bug in the app (Gear Lever) itself.

For now, we'll have to use this workaround (only if you use Gear Lever) while the VeraCrypt developers create a new, better-functioning AppImage and, hopefully, a Flatpak package.

--

Edit: Perhaps @LittleBlueBreeze should change the title and description of this report, since technically, if you download the VeraCrypt AppImage from the official website and grant it permission to run as a program, it works. The problem arises with its interaction with third-party applications, in this case, Gear Lever.

Off Topic: There's another way to manage AppImages with a graphical interface that works on immutable operating systems called AppManager, which functions similarly to how applications are installed on macOS. It has greater compatibility with AppImage specifications (includes older versions) and doesn't generate the issue described with VeraCrypt, which is useful for those who want to avoid using this Gear Lever trick and maintain compatibility across versions.

Cheers

[idrassi]

Thank you all for the reports and for narrowing this down to the AppImage filename.

I investigated the issue and confirmed that this has already been fixed in commit 87a5024 dated June 9th 2025. Unfortunately, this fix was committed after the 1.26.24 Linux release and I could not release a new VeraCrypt version since then and that's why you are still affected.

The failure is caused by VeraCrypt's AppImage detection logic used during sudo elevation. When VeraCrypt runs from an AppImage, the elevated helper must be started by executing the outer AppImage file from $APPIMAGE, not the internal binary under the temporary AppImage mount directory.

In VeraCrypt 1.26.24, the detection only accepted mount paths beginning with:

• /tmp/.mount_Veracr
• /tmp/.mount_VeraCr

GearLever renames the file to veracrypt.appimage. The AppImage runtime uses the beginning of the AppImage filename when creating the mount directory, so this becomes something like:

/tmp/.mount_veracrXXXXXX

Because of the lowercase veracr, VeraCrypt 1.26.24 did not recognize that it was running from an AppImage. It then tried to elevate the internal mounted binary instead of the AppImage file itself, which leads to the "Failed to obtain administrator privileges" error.

The fix makes the AppImage mount-name check case-insensitive, so filenames such as veracrypt.appimage, VeraCrypt.appimage, Veracrypt.appimage, and similar variants should work correctly.

Until a new Linux AppImage is published, the practical workaround is to keep the AppImage filename starting with VeraCrypt or Veracrypt, for example VeraCrypt.appimage or VeraCrypt-1.26.24-x86_64.AppImage

I will prepare a nightly build of the AppImage from master tomorrow. It can be used until official full release is published.

Note: Other AppImage integration issues mentioned in the thread, such as metadata/icon display or desktop integration behavior, are separate packaging/integration topics and can be tracked independently. But I will try to address them as soon as possible.