$linuxjunkies
>

How to Run AppImage Files

Download, chmod +x, and run — or go further with AppImageLauncher for menu integration and Firejail for sandboxing. A complete practical guide.

BeginnerUbuntuDebianFedoraArch7 min readUpdated June 7, 2026

Before you start

  • A desktop Linux system with a graphical session (X11 or Wayland)
  • libfuse2 or equivalent FUSE library installed
  • A downloaded .AppImage file from a trusted source

AppImage is a portable application format for Linux — a single self-contained file you download and run without installing anything, touching package managers, or needing root. One file, one app. The trade-off is that nothing sets it up for you automatically; you have to make it executable, optionally integrate it into your desktop, and decide how much you trust it. Here is exactly how to do all of that.

What an AppImage Actually Is

An AppImage bundles the application, its libraries, and a small runtime into a single file using a read-only SquashFS image. When you run it, the runtime mounts itself via FUSE and executes the app. This means the host system needs FUSE support — which every mainstream distro ships by default — but otherwise has no install step.

AppImages come in two formats: Type 1 (legacy, uses ISO 9660) and Type 2 (current, uses SquashFS). You will almost always encounter Type 2 today. The steps below apply to both.

Step 1: Install FUSE If Needed

Most systems already have FUSE. If running an AppImage throws a fuse: device not found or dlopen(): error loading libfuse.so.2 error, install it first.

Debian / Ubuntu

sudo apt install libfuse2

On Ubuntu 22.04+ the package is libfuse2 (not fuse); both coexist fine with FUSE 3.

Fedora / RHEL / Rocky

sudo dnf install fuse fuse-libs

Arch Linux

sudo pacman -S fuse2

Step 2: Make the AppImage Executable

A freshly downloaded AppImage is just a file. Your file manager may show a dialog offering to make it executable — accept it. Or do it from the terminal, which is clearer:

chmod +x ~/Downloads/MyApp-x86_64.AppImage

Verify the permission change:

ls -lh ~/Downloads/MyApp-x86_64.AppImage

You should see an x bit: -rwxr-xr-x. Now run it:

~/Downloads/MyApp-x86_64.AppImage

That is the entire "install" for basic use. If the app launches, you are done — unless you want desktop integration.

Step 3: Desktop Integration with AppImageLauncher

Running AppImages from ~/Downloads forever is untidy. AppImageLauncher intercepts the first run of any AppImage, offers to move it to a dedicated folder (~/Applications by default), and adds a .desktop entry plus an icon to your application menu automatically. It also handles updates via the AppImageUpdate protocol if the app supports it.

Install AppImageLauncher

Debian / Ubuntu — the project provides a PPA:

sudo add-apt-repository ppa:appimagelauncher-team/stable
sudo apt update
sudo apt install appimagelauncher

Fedora — use the RPM from the AppImageLauncher releases page or Copr:

sudo dnf copr enable atim/appimagelauncher
sudo dnf install appimagelauncher

Arch Linux — available in the AUR:

paru -S appimagelauncher
# or with yay:
yay -S appimagelauncher

How the Integration Works

After installation, AppImageLauncher registers itself as the binfmt handler for AppImage files. The next time you double-click or run an AppImage, a dialog appears asking whether to run it once or integrate it. Choose Integrate and run and it moves the file to ~/Applications and writes a .desktop file to ~/.local/share/applications/. The app then appears in your launcher like any installed program.

To remove an integrated app, right-click its launcher entry — AppImageLauncher adds a "Remove" option that deletes both the AppImage and the desktop entry cleanly.

Step 4: Manual Desktop Integration (Without AppImageLauncher)

If you prefer not to install AppImageLauncher, you can integrate apps manually. Move the AppImage somewhere permanent first:

mkdir -p ~/Applications
mv ~/Downloads/MyApp-x86_64.AppImage ~/Applications/
chmod +x ~/Applications/MyApp-x86_64.AppImage

Extract the icon from the AppImage (most include one):

~/Applications/MyApp-x86_64.AppImage --appimage-extract-and-run squashfs-root/myapp.png 2>/dev/null
# Icon paths vary; list what is available:
~/Applications/MyApp-x86_64.AppImage --appimage-extract squashfs-root
ls squashfs-root/*.png squashfs-root/*.svg 2>/dev/null

Copy an icon to your local icon directory:

cp squashfs-root/myapp.png ~/.local/share/icons/myapp.png
rm -rf squashfs-root

Create a .desktop file:

cat > ~/.local/share/applications/myapp.desktop << 'EOF'
[Desktop Entry]
Name=MyApp
Exec=/home/YOUR_USER/Applications/MyApp-x86_64.AppImage
Icon=/home/YOUR_USER/.local/share/icons/myapp.png
Type=Application
Categories=Utility;
StartupNotify=true
EOF

Replace YOUR_USER with your actual username, or use $HOME — note that some desktop environments do not expand shell variables in Exec lines, so an absolute path is safer. Update the database:

update-desktop-database ~/.local/share/applications/

The app should appear in your menu within seconds.

Step 5: Sandboxing AppImages

AppImages run with your full user permissions by default. For apps from unknown sources, or apps that have no business accessing your home directory, sandbox them with Firejail or Bubblewrap.

Firejail

# Install
sudo apt install firejail       # Debian/Ubuntu
sudo dnf install firejail       # Fedora
sudo pacman -S firejail         # Arch

# Run an AppImage sandboxed
firejail ~/Applications/MyApp-x86_64.AppImage

For tighter control, restrict home directory access:

firejail --private ~/Applications/MyApp-x86_64.AppImage

--private gives the app a temporary empty home directory. It cannot read your real files. Combine with --net=none to also block network access.

Bubblewrap (manual, minimal)

sudo apt install bubblewrap     # Debian/Ubuntu

bwrap \
  --ro-bind /usr /usr \
  --ro-bind /lib /lib \
  --ro-bind /lib64 /lib64 \
  --ro-bind /etc /etc \
  --bind /tmp /tmp \
  --proc /proc \
  --dev /dev \
  --unshare-net \
  ~/Applications/MyApp-x86_64.AppImage

Bubblewrap is lower-level than Firejail and requires you to explicitly allow everything the app needs. Start with Firejail unless you need fine-grained policy.

Verification

After integration, check the .desktop file was picked up:

grep -r "MyApp" ~/.local/share/applications/

Confirm the AppImage is executable and in place:

ls -lh ~/Applications/*.AppImage

If using AppImageLauncher, verify the binfmt handler is registered:

cat /proc/sys/fs/binfmt_misc/appimage-type2

A file with enabled on the first line confirms AppImageLauncher is active.

Troubleshooting

  • "dlopen(): error loading libfuse.so.2" — Install libfuse2 (Ubuntu/Debian) or fuse-libs (Fedora). On Ubuntu 22.04+ these are separate from the FUSE 3 packages.
  • AppImage exits immediately with no error — Run from the terminal to see stderr. Try --no-sandbox if it is a Chromium/Electron-based app; many need that flag when running as a non-root user on certain kernels.
  • Icon missing from menu — Run update-desktop-database ~/.local/share/applications/ and log out/in. Confirm the icon path in the .desktop file is absolute and the file exists.
  • AppImageLauncher dialog never appears — Confirm binfmt support is enabled: ls /proc/sys/fs/binfmt_misc/. If it shows only register and status, AppImageLauncher may not have registered correctly; reinstall it and reboot.
  • Wayland issues — Some older AppImages bundle X11-only toolkits. Try setting DISPLAY=:0 or run with --ozone-platform=x11 for Electron apps. Newer AppImages that bundle a current toolkit handle Wayland natively.
tested on:Ubuntu 24.04Fedora 40Arch 2024.05Debian 12

Frequently asked questions

Do I need root or sudo to run AppImages?
No. AppImages are designed for unprivileged users. The only time you need sudo is when installing system-level helpers like AppImageLauncher or Firejail via your package manager.
Why does my Electron-based AppImage crash on launch?
Electron apps often need the --no-sandbox flag when running without user namespaces enabled. Try: ./MyApp.AppImage --no-sandbox. Alternatively, enable unprivileged user namespaces: sudo sysctl -w kernel.unprivileged_userns_clone=1 (Debian/Ubuntu).
How do I update an AppImage?
AppImages do not auto-update. Check the developer's release page and download the new version. AppImageLauncher adds an update option for apps that embed an update URL (AppImageUpdate protocol), but many apps do not include one.
Can I extract the contents of an AppImage without running it?
Yes. Run: ./MyApp.AppImage --appimage-extract — this extracts everything into a squashfs-root directory in the current folder. Useful for inspecting contents or running on systems without FUSE.
Is AppImageLauncher safe to use with all AppImages?
AppImageLauncher itself is safe, but it does not vet the AppImages it integrates. You are responsible for trusting the AppImage source. Prefer official project releases and verify checksums when provided.

Related guides