How to Install AppImage on Ubuntu 26.04, 24.04 and 22.04

AppImage files are useful on Ubuntu when an application publishes a single portable download instead of an APT repository, Snap, Flatpak, or packaged .deb file. To install AppImage on Ubuntu Linux in the practical sense, set up FUSE support, keep the file in a stable location, make it executable, and add a launcher when you want the app to behave like a normal desktop program.

These steps cover Ubuntu 26.04, 24.04, and 22.04. The important release split is the FUSE compatibility package: Ubuntu 26.04 and 24.04 use libfuse2t64, while Ubuntu 22.04 uses libfuse2. After that, AppImage handling is mostly about permissions, file placement, architecture matching, desktop integration, updates, and cleanup.

Install AppImage on Ubuntu

Refresh package metadata and apply pending package updates before adding the FUSE compatibility packages.

sudo apt update && sudo apt upgrade

These package commands use sudo. If your account cannot run administrative commands yet, follow the guide to add a new user to sudoers on Ubuntu first.

Install FUSE Packages for AppImages on Ubuntu

Most current AppImages still expect the FUSE 2 compatibility library named libfuse.so.2. Ubuntu keeps these compatibility packages in the Universe component, so customized or minimal systems may need the Ubuntu Universe repository enabled before APT can find them.

On Ubuntu 26.04 and 24.04, install the time64 FUSE 2 package plus small helper tools used later for downloads, architecture checks, and desktop launchers:

sudo apt install libfuse2t64 curl file desktop-file-utils

On Ubuntu 22.04, use the older package name:

sudo apt install libfuse2 curl file desktop-file-utils

Confirm that the FUSE 2 library is visible to the dynamic linker. The pipe uses the Linux grep command to show only the matching FUSE entry:

ldconfig -p | grep 'libfuse.so.2'

Relevant output on Ubuntu 26.04 after installing libfuse2t64:

libfuse.so.2 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libfuse.so.2

Ubuntu 24.04 and 22.04 show the same library name, with the path normally under /lib/x86_64-linux-gnu/. The library name is the part that matters for AppImage startup.

Download and Run an AppImage on Ubuntu

Use the application’s official download page, GitHub releases page, or vendor documentation instead of third-party mirrors. The official AppImage quickstart reduces the core flow to download, make executable, and run, but Ubuntu’s FUSE package split is the part that catches many users. If the project publishes checksums or signatures, verify them before trusting the file. For automated release downloads, the curl command guide covers safer flags and redirects.

Store AppImages in a Stable Folder

The Downloads folder is a poor long-term launch path because browser cleanup, renamed files, or a moved download can break shortcuts. A user-local ~/Applications directory keeps AppImages easy to find without giving them system-wide privileges.

mkdir -p "$HOME/Applications"
cd "$HOME/Applications"
mv "$HOME/Downloads/Example-1.0-x86_64.AppImage" .
chmod u+x Example-1.0-x86_64.AppImage
ln -sfn Example-1.0-x86_64.AppImage Example.AppImage
./Example.AppImage

Replace Example-1.0-x86_64.AppImage with the exact file name you downloaded. The chmod u+x step adds execute permission for your user; the chmod command guide explains the permission bits if you want the full breakdown.

The stable Example.AppImage symlink lets launchers keep one path even after you replace the versioned AppImage file later. If you need to move many AppImage files between folders, review the Linux mv command guide before running bulk moves.

Check AppImage Architecture Before Running It

Most Ubuntu desktop installs on standard PCs need an x86_64 or amd64 AppImage. ARM devices need aarch64 or arm64 builds when the project publishes them.

uname -m

Most Intel and AMD desktop systems report:

x86_64

Check the AppImage file itself before troubleshooting FUSE or permissions:

file -L "$HOME/Applications/Example.AppImage"

Relevant output for an x86_64 AppImage includes the ELF 64-bit and x86-64 markers:

ELF 64-bit LSB executable, x86-64

If your system reports x86_64 but the file command reports ARM aarch64, download the correct build before troubleshooting permissions or FUSE.

Add an AppImage to the Ubuntu Applications Menu

Double-click launching works for quick tests, but a desktop entry is cleaner for daily use. This template creates a user-local launcher, validates the file, and refreshes the application database.

APP_NAME="Example App"
APPIMAGE_NAME="Example.AppImage"
DESKTOP_ID="example-appimage"
APP_CATEGORIES="Utility;"

APPIMAGE_PATH="$HOME/Applications/$APPIMAGE_NAME"
DESKTOP_FILE="$HOME/.local/share/applications/${DESKTOP_ID}.desktop"

mkdir -p "$HOME/.local/share/applications"

cat > "$DESKTOP_FILE" <<EOF
[Desktop Entry]
Type=Application
Name=$APP_NAME
Exec=$APPIMAGE_PATH
Icon=application-x-executable
Terminal=false
Categories=$APP_CATEGORIES
EOF

desktop-file-validate "$DESKTOP_FILE"
update-desktop-database "$HOME/.local/share/applications"

Edit the variables before running the block. Exec= should point to the stable symlink in ~/Applications, not a disposable file in Downloads. Replace Icon=application-x-executable with an absolute icon path only when the app provides a stable icon file you plan to keep.

Check the launcher target after creating the desktop file:

APPIMAGE_PATH="$HOME/Applications/Example.AppImage"
DESKTOP_FILE="$HOME/.local/share/applications/example-appimage.desktop"

test -x "$APPIMAGE_PATH" && grep -E '^(Name|Exec|Icon)=' "$DESKTOP_FILE"

Log out and back in if the application menu does not refresh immediately. Some desktop environments update launchers only after the session reloads.

Update AppImages Safely on Ubuntu

AppImages do not update through APT unless the application separately provides a repository package. Some projects include an internal updater, but many require you to download a newer AppImage and replace the old file yourself. A universal updater script is not reliable here because release pages, checksums, signatures, and AppImage filenames differ by project; follow that application’s update instructions when they exist.

Stage a New AppImage Before Replacing the Launcher

Keep the old version until the new file passes a basic file check and starts. Then update the stable symlink that your desktop entry uses.

cd "$HOME/Applications"
install -m 755 "$HOME/Downloads/Example-2.0-x86_64.AppImage" "$HOME/Applications/Example-2.0-x86_64.AppImage"
file -L "$HOME/Applications/Example-2.0-x86_64.AppImage"
./Example-2.0-x86_64.AppImage

If the file output matches your system architecture and the app starts, repoint the launcher symlink:

cd "$HOME/Applications"
ln -sfn Example-2.0-x86_64.AppImage Example.AppImage

If the new release fails after you have already repointed the symlink, switch back to the previous file:

cd "$HOME/Applications"
ln -sfn Example-1.0-x86_64.AppImage Example.AppImage
./Example.AppImage

Remove older versioned files only after you know the replacement works and you no longer need a rollback copy.

Use Known AppImage Examples on Ubuntu

Many desktop apps publish AppImages as one install path among several. Use app-specific guidance when the application has its own checksums, release naming, launcher requirements, update behavior, or dependency notes.

• Install digiKam on Ubuntu covers a photo-management app where the official AppImage can be useful when you want the upstream portable build.
• Install Nextcloud Desktop on Ubuntu compares repository, PPA, AppImage, and Flatpak choices for a sync client.
• Install Obsidian on Ubuntu includes AppImage handling for a popular notes app with multiple Linux download formats.

Use AppImage when the project publishes it as the cleanest or only Linux build, when you want a portable copy under your own account, or when the distro package is too old for your workflow. Prefer APT, Flatpak, or Snap when you want automatic updates, stronger system integration, or easier removal. The Flatpak installation guide for Ubuntu is a good comparison point when an app also has a maintained Flathub package.

Fix Common AppImage Errors on Ubuntu

Fix Permission Denied or a Silent Double-Click

A downloaded AppImage normally lacks execute permission. Run it from the terminal first so permission errors are visible instead of hidden behind the file manager.

cd "$HOME/Applications"
ls -l Example.AppImage
chmod u+x Example.AppImage
./Example.AppImage

If the file is on an external drive, network mount, or Windows-formatted partition, check whether the mount uses noexec:

findmnt -no TARGET,OPTIONS --target "$HOME/Applications/Example.AppImage"

Move the AppImage into your home directory when the mount options include noexec. Remounting storage with execute permission is an administrative decision and is usually unnecessary for personal AppImages.

Fix dlopen Error Loading libfuse.so.2

When FUSE 2 support is missing, AppImages commonly stop with this error:

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

Install libfuse2t64 on Ubuntu 26.04 or 24.04, or libfuse2 on Ubuntu 22.04, then run the AppImage again. The official AppImage FUSE troubleshooting documentation also documents the extraction fallback for systems where FUSE cannot be used.

Fix Wrong Architecture Errors

An AppImage built for ARM will not run on an ordinary x86_64 Ubuntu PC. The failure looks like this when an aarch64 AppImage is launched on x86_64 hardware:

pkg2appimage-aarch64.AppImage: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped
bash: ./pkg2appimage-aarch64.AppImage: cannot execute binary file: Exec format error

Match the AppImage architecture to uname -m. On most Ubuntu desktops, that means choosing the x86_64 or amd64 asset rather than aarch64, arm64, armhf, or i686.

Handle GLIBC Version Errors

Errors such as GLIBC_2.38 not found usually mean the AppImage was built on a newer base system than your Ubuntu release provides. Do not replace Ubuntu’s system glibc to force one AppImage to start. Use an older AppImage from the same project, choose a Flatpak/Snap/native package if available, or run the app on a newer Ubuntu release.

Check Electron AppImage Sandbox Issues on Ubuntu 24.04 and Newer

Some Electron-based AppImages can hit sandbox or user-namespace failures on Ubuntu 26.04 and 24.04. This setting currently returns 1 on Ubuntu 26.04 and 24.04, while Ubuntu 22.04 returns 0:

sysctl -n kernel.apparmor_restrict_unprivileged_userns 2>/dev/null || echo MISSING

1

Ubuntu documents this AppArmor restriction as a security hardening feature in the Ubuntu 24.04 release notes. If an Electron AppImage fails with sandbox errors, check the vendor’s current Linux notes first, then inspect AppArmor logs before changing system policy. Keep any AppArmor changes on Ubuntu scoped to the affected app instead of disabling the restriction globally.

sudo journalctl -k -g 'apparmor|userns' --no-pager

A one-off --no-sandbox launch can confirm the symptom, but it disables an internal security feature and should not become your permanent fix unless the upstream project explicitly documents that path. A maintained package, a project-provided AppArmor profile, or a different package format is usually safer than turning off the restriction globally.

Run an AppImage Without FUSE as a Last Resort

If you cannot install FUSE because you lack admin access, are inside a locked-down container, or are testing a one-time file, extract the AppImage and run its internal entry point. This is slower and less tidy than normal FUSE execution, but it can rescue a one-off launch.

cd "$HOME/Applications"
./Example.AppImage --appimage-extract
./squashfs-root/AppRun
rm -rf squashfs-root

Some newer AppImages also support --appimage-extract-and-run. If the option fails, fall back to manual extraction and remove squashfs-root after testing.

Remove AppImages from Ubuntu

Removing an AppImage is mostly file cleanup because the application was never installed through APT. Remove the versioned AppImage files, the stable symlink, and any desktop entry you created.

rm -f "$HOME/Applications/Example.AppImage"
rm -f "$HOME/Applications/Example-1.0-x86_64.AppImage"
rm -f "$HOME/Applications/Example-2.0-x86_64.AppImage"
rm -f "$HOME/.local/share/applications/example-appimage.desktop"
update-desktop-database "$HOME/.local/share/applications"

Application data is separate. Check the app’s documentation before deleting folders under ~/.config, ~/.local/share, or ~/.cache, because names differ and some apps store important project data there.

If you no longer run any AppImages, remove the FUSE compatibility package for your Ubuntu release. Skip this step if another AppImage still depends on it.

Ubuntu 26.04 and 24.04:

sudo apt remove libfuse2t64

Ubuntu 22.04:

sudo apt remove libfuse2

Preview any dependency cleanup before accepting it:

sudo apt autoremove --dry-run

Continue with the real autoremove only when the dry run lists packages you recognize as no longer needed. If it lists old kernels, desktop helpers, remote-desktop packages, or anything unrelated to AppImages, skip the cleanup or review the packages separately.

sudo apt autoremove

Conclusion

Ubuntu can run AppImages cleanly once the right FUSE package is installed, the file has execute permission, and the launcher points to a stable path. Keep AppImages under ~/Applications, use a symlink for updates, prefer official download pages, and treat FUSE, architecture, glibc, and Electron sandbox errors as separate problems instead of changing system security settings blindly.