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.
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) orfuse-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-sandboxif 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.desktopfile is absolute and the file exists. - AppImageLauncher dialog never appears — Confirm binfmt support is enabled:
ls /proc/sys/fs/binfmt_misc/. If it shows onlyregisterandstatus, AppImageLauncher may not have registered correctly; reinstall it and reboot. - Wayland issues — Some older AppImages bundle X11-only toolkits. Try setting
DISPLAY=:0or run with--ozone-platform=x11for Electron apps. Newer AppImages that bundle a current toolkit handle Wayland natively.
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
Linux Clipboards Explained (+ Clipboard Managers)
Learn the difference between Linux's PRIMARY and CLIPBOARD selections, use xclip, xsel, and wl-clipboard from the terminal, and manage history with GPaste or Klipper.
Configure LibreOffice for Daily Use
Configure LibreOffice for daily use: set default save formats for MS Office interop, tune autosave, install fonts, and add productivity extensions.
Configure the Touchpad and Multitouch Gestures
Configure Linux touchpad behavior and multitouch gestures using libinput, libinput-gestures, and native GNOME and KDE Plasma settings on both Wayland and X11.
Wayland vs X11: How to Choose and Configure Each
Know when to run Wayland or X11, how to check your current session, switch at login with GDM/SDDM/LightDM, and handle NVIDIA and XWayland edge cases.