AppImage Won’t Run on Linux? Every Common Error and Its Fix

An AppImage is supposed to be the easy way to run a Linux app: download one file, make it executable, run it. When it fails, the error messages are short and rarely say what to do next. This guide goes through the errors you are most likely to see, what each one means, and the fix, with the exact commands. The example I use throughout is a real one: an Electron-based desktop app downloaded as an AppImage on Kali Linux, which stopped with a missing libfuse.so.2 library.

Quick triage

What you see	Likely cause	Fix
Permission denied	Usually a missing execute permission (a noexec location can also cause it)	chmod +x file.AppImage, then see section 5 if it persists
dlopen(): error loading libfuse.so.2 / AppImages require FUSE to run	FUSE 2 library missing	Install it, or run with --appimage-extract-and-run
A sandbox or user-namespace error in the terminal (Electron apps)	Unprivileged user namespaces are off or restricted	Enable them, or as a last resort --no-sandbox
cannot execute binary file: Exec format error	Often the wrong CPU architecture (for example an x64 file on an ARM machine)	Compare uname -m and file output, then download the matching build
Nothing happens from a USB stick or /tmp	The location may be mounted noexec	Check with findmnt and move the file
version `GLIBC_2.xx' not found	The distro’s C library is older than the app needs	Use a newer distro or an older app release
Runs in the terminal, does nothing from the application menu	The menu entry’s Exec= line may launch the plain AppImage, and no error is shown	Check and edit the .desktop file (section 9)

1. Permission denied: make the file executable

A downloaded file is not executable by default. Check, then fix:

ls -l ~/Downloads/MyApp.AppImage
chmod +x ~/Downloads/MyApp.AppImage
~/Downloads/MyApp.AppImage

If the ls -l line has no x in the permission column, add it and run the file again. Another error may follow, and the sections below cover those.

2. “AppImages require FUSE to run”

A missing FUSE library is a typical reason an AppImage will not start. It looks like this:

dlopen(): error loading libfuse.so.2

AppImages require FUSE to run.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information

Why it happens. A type 2 AppImage is a compressed filesystem that gets mounted when you run it, and mounting it as a normal user needs FUSE (Filesystem in Userspace). According to the AppImage project’s FUSE page, some AppImages need FUSE version 2, while newer ones have FUSE 3 built in. So an AppImage can fail even on a machine that has FUSE 3 installed, because it is the old FUSE 2 library it is looking for.

Install the FUSE 2 library for your distribution

The package name depends on the distribution and its age. These come from the AppImage troubleshooting guide:

Distribution	Command
Ubuntu 22.04, and Debian/Ubuntu releases that still have libfuse2	sudo apt install libfuse2
Ubuntu 24.04 and later, Debian 13 and later	sudo apt install libfuse2t64 (the package was renamed)
Fedora	sudo dnf install fuse fuse-libs
Arch Linux	sudo pacman -S fuse2
openSUSE	sudo zypper install fuse libfuse2

One warning from that guide is worth repeating: on Ubuntu, do not install the package called plain fuse to fix this. It can break the system. Install libfuse2 (or libfuse2t64) only.

On Ubuntu, the package lives in the universe repository. If apt cannot find it, enable that first with sudo add-apt-repository universe. That repository is Ubuntu-specific, so do not add it on Debian or Kali.

When the package cannot be found: Kali Linux

I hit this on Kali. Both package names failed:

$ sudo apt install libfuse2t64
Error: Unable to locate package libfuse2t64

$ sudo apt install libfuse2
Package libfuse2 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

Error: Package 'libfuse2' has no installation candidate

The cause is upstream, not a typo or an out-of-date package list. A Parallels support article about the same error says libfuse2 was removed from the kali-rolling repository on 20 April 2026, because Debian dropped it from Debian testing, which Kali follows. If you are on kali-rolling and see the same two errors, skip to the fallback below. It needs no package at all.

The fallback that needs no installation

Most current (type 2) AppImages can unpack themselves and run from the unpacked copy, which bypasses FUSE. Support for this option depends on the AppImage’s built-in runtime, and very old AppImages may lack it, in which case use the two-command extraction shown below:

./MyApp.AppImage --appimage-extract-and-run

This is what fixed it for me. The same thing can be switched on with an environment variable, which is handy when the AppImage is started by a launcher or script. The variable was added to the AppImage runtime later than the flag, so on an old AppImage it may have no effect even though the flag works. It did work for the app in my example:

export APPIMAGE_EXTRACT_AND_RUN=1
./MyApp.AppImage

The AppImage documentation calls this a last resort because unpacking is expensive, and you pay that cost on every start. If you want to keep the unpacked files and run them directly:

./MyApp.AppImage --appimage-extract
./squashfs-root/AppRun

If the app’s publisher offers a .deb or .rpm for your distribution, release and CPU architecture, that can be a cleaner install than any of this, because the package manager resolves the declared dependencies. Check that the package is meant for your system, and read the list of changes your package manager proposes, because installing a package runs with administrator rights.

Documented workaround: install the package by hand (not tested by me)

The Parallels article suggests downloading the library from the Debian archive and installing it yourself. I did not use this route, but here is how it would look for a 64-bit PC (amd64). The file name and checksum below are from Debian’s own package index for Debian 13 (trixie), checked on 26 October 2026:

cd ~/Downloads
wget https://deb.debian.org/debian/pool/main/f/fuse/libfuse2t64_2.9.9-9_amd64.deb
sha256sum libfuse2t64_2.9.9-9_amd64.deb
# expected: e60474070e983693ac461af291b876c2304340f75a6b8379a3ba017e4848341e
sudo apt install ./libfuse2t64_2.9.9-9_amd64.deb

Do not install it if the checksum does not match. Downloading a .deb by hand does not add an update source, so do not expect automatic updates for it, and this one needs a C library of version 2.38 or newer. Read the list of changes apt proposes before you accept it. The file name, checksum and dependency note above belong to this exact version. If the Debian pool listing has moved on and you pick a different file, check its version, architecture, dependencies and checksum yourself.

3. Electron apps: sandbox errors

Many AppImages are Electron apps, which use Chromium’s sandbox. That sandbox needs the kernel to allow unprivileged user namespaces. Only go down this path if the terminal output mentions the sandbox or namespaces; a window that simply does not appear is not enough evidence, so run the AppImage from a terminal first. The AppImage guide on Electron sandboxing explains that some distributions, Debian among them, do not enable this by default. Check without root:

sysctl kernel.unprivileged_userns_clone

A result of kernel.unprivileged_userns_clone = 1 means this particular switch is on. It is not a complete sandbox health check, and not every kernel has this setting; an “unknown key” message does not by itself mean namespaces are disabled. If the value is 0, you can turn it on until the next reboot, or permanently:

# until reboot
sudo sysctl -w kernel.unprivileged_userns_clone=1

# permanent (takes effect after a reboot)
echo kernel.unprivileged_userns_clone = 1 | sudo tee /etc/sysctl.d/00-local-userns.conf

The AppImage project is explicit that it gives no guarantee this setting is secure, so if you are unsure, ask your distribution first.

Ubuntu 24.04 is a separate case. It ships an AppArmor restriction on unprivileged user namespaces (apparmor_restrict_unprivileged_userns), which makes many Electron AppImages crash at start; the underlying issue is tracked in Ubuntu bug 2046844. The common workaround is to start the app from a terminal with the sandbox switched off:

./MyApp.AppImage --no-sandbox

Treat --no-sandbox as a temporary test to find out whether the sandbox is the cause, not as a permanent fix. Electron’s documentation describes the sandbox as a protection for the whole application, and the flag turns it off. For everyday use, look for an updated build of the app or a distribution-supported setting (on Ubuntu 24.04, an AppArmor profile for the app). Never run such an app as root.

4. “Exec format error”: wrong architecture

If the shell says cannot execute binary file: Exec format error, the file may have been built for a different CPU. A damaged or incomplete download can give the same message. Compare your machine with the file:

uname -m
file MyApp.AppImage

x86_64 needs the x64 (also called amd64) build; aarch64 needs the ARM64 build. Many projects publish both side by side, so make sure you picked the right one.

5. Nothing happens from a USB stick or /tmp

Some filesystems are mounted with the noexec option, which stops files from being run from them even when they are executable. Check the filesystem the file is on:

findmnt -T ~/Downloads/MyApp.AppImage -o TARGET,OPTIONS

If noexec appears in the options, move the file to a filesystem that allows execution (your home directory usually does, for example ~/Applications) and check that one the same way.

6. “version GLIBC_2.xx not found”

An AppImage carries most of its libraries but still relies on the system’s C library. If the app was built on a newer distribution than yours, you may see an error like version `GLIBC_2.35' not found. Check your version with ldd --version. The fixes are to run a newer distribution release or to download an older release of the app.

7. AppImages inside Docker

Most Docker setups do not allow FUSE inside containers. The AppImage guide says to use the extract-and-run method there. It warns against the popular workaround of adding --cap-add SYS_ADMIN --cap-add MKNOD --device /dev/fuse:mrw to the container, which it calls insecure.

8. Very old AppImages (type 1)

Old type 1 AppImages are ISO images, so --appimage-extract does not apply. Mount one with root privileges on a directory you create just for it (mounting over a folder that is already in use hides its contents), or unpack it with bsdtar:

mkdir -p ~/appimage-mnt
sudo mount -o loop MyApp.AppImage ~/appimage-mnt
~/appimage-mnt/AppRun
# close the app first, then:
sudo umount ~/appimage-mnt

9. The app is in the menu but nothing happens when you click it

If an AppImage runs from the terminal but not from the application menu, look at the command the menu entry runs. Entries live in .desktop files, usually in ~/.local/share/applications/, and the command is the Exec= line. A menu launcher does not open a terminal, so an error from the AppImage (the FUSE error, for example) is typically not shown and the app just looks dead.

Find the entry and read it:

grep -rl "MyApp" ~/.local/share/applications/ /usr/share/applications/ 2>/dev/null
cat ~/.local/share/applications/MyApp.desktop

If you had to use --appimage-extract-and-run in the terminal, the launcher needs the same treatment. The environment-variable form is easiest to put in front of an Exec= line:

Exec=env APPIMAGE_EXTRACT_AND_RUN=1 "/home/you/Applications/MyApp.AppImage" %U

A .desktop file has to open with the [Desktop Entry] group header before any settings (only blank lines and comments may come before it, per the Desktop Entry Specification). If settings appear first, update-desktop-database, which parses the files in that folder, reports Key file does not start with a group. A minimal file looks like this:

[Desktop Entry]
Type=Application
Name=MyApp
Exec=env APPIMAGE_EXTRACT_AND_RUN=1 "/home/you/Applications/MyApp.AppImage" %U
Terminal=false
Categories=Utility;

Check the file’s format, then run the database tool, which both parses the entries and refreshes the desktop MIME cache (it is not a general “reload the menu” command; menus normally pick up new entries by themselves):

desktop-file-validate ~/.local/share/applications/MyApp.desktop
update-desktop-database ~/.local/share/applications

The validator checks format only. The real test is clicking the entry.

Also keep the AppImage somewhere stable. The Exec= path is fixed, so moving the file breaks the entry.

A note on safety

• An AppImage is a program you run with your own user’s permissions. Download it only from the project’s official site.
• If the publisher lists a checksum, compare it with sha256sum before you run the file.
• Do not run an AppImage with sudo to get around an error.

Checklist

1. Is it executable? chmod +x
2. Right architecture? uname -m and file
3. On a noexec filesystem? Check with findmnt, then move it
4. FUSE error? Install libfuse2 or libfuse2t64, or run with --appimage-extract-and-run
5. Package not found (Kali)? Use --appimage-extract-and-run
6. Sandbox or namespace error in the terminal (Electron apps)? Check kernel.unprivileged_userns_clone, and use --no-sandbox only as a temporary test
7. Works in the terminal but not from the menu? Check the Exec= line of its .desktop file
8. Does the publisher offer a .deb or .rpm for your distribution, release and architecture? That can be cleaner than an AppImage

For a worked example of the Kali case, see ZCode on Kali Linux: fixing the libfuse.so.2 AppImage error. If your problem is a command rather than an app that will not start, the “command not found” checklist may help.