Skip to content

FUSE

Jump to bottom
probonopd edited this page Mar 27, 2022 · 46 revisions

AppImages require FUSE version 2 to run. Filesystem in Userspace (FUSE) is a system that lets non-root users mount filesystems.

Install FUSE

Many distributions have a working FUSE setup out-of-the-box. However if it is not working for you, you may need to install and configure FUSE manually.

For example, on Ubuntu:

sudo apt install fuse libfuse2
sudo modprobe fuse
sudo groupadd fuse

user="$(whoami)"
sudo usermod -a -G fuse $user

For example, on openSUSE:

sudo zypper install fuse libfuse2

In order to use fusermount on OpenSUSE with the default (?) "secure" file permission settings (see /etc/permissions.secure), your login needs to be part of the trusted group. To add yourself, run

sudo usermod -a -G trusted `whoami`

Then log out and log in for the change to take effect.

For example, on CentOS/RHEL:

yum --enablerepo=epel -y install fuse-sshfs # install from EPEL
user="$(whoami)"
usermod -a -G fuse "$user"

For example, on Armbian 64-bit systems (e.g., for the Pine64) you need to install 32-bit libfuse2 in order to run 32-bit AppImages such as the MuseScore one:

sudo apt install libfuse2:armhf

For example, on Clear Linux OS:

This may be a bug, please see https://github.com/clearlinux/distribution/issues/273

sudo su
mkdir -p /etc/modules-load.d/
echo "fuse" > /etc/modules-load.d/fuse.conf
reboot

For example, on Arch Linux:

If you are seeing "fusermount: mount failed: Operation not permitted"

sudo chmod u+s `which fusermount`

Chrome OS, Chromium OS, Crostini:

FUSE is not operational out of the box, but installation is simple after version 73:

sudo apt install fuse

check https://bugs.chromium.org/p/chromium/issues/detail?id=841787 for details

Fallback

If you don't want to install FUSE, you can either mount or extract the AppImage.

type-2 AppImage

To extract the contents of the AppImage, simply run the AppImage with --appimage-extract.

type-1 AppImage

If the above does not work, you may still have an older type-1 AppImage. To mount the AppImage and run the application, simply run

sudo mount -o loop Some.AppImage /mnt
/mnt/AppRun

A type-1 AppImage is an ISO, so

sudo apt install libarchive-tools # Or any other method to get `bsdtar`
mkdir AppDir
cd AppDir
bsdtar xfp /home/me/Downloads/Some.AppImage
./AppRun

also works.

Docker

When running an AppImage from a Docker container you will get the following error:

fuse: failed to open /dev/fuse: Operation not permitted
Could not mount AppImage
Please see https://github.com/probonopd/AppImageKit/wiki/FUSE

You'll often hear "oh, just add these arguments to docker run --cap-add SYS_ADMIN --cap-add MKNOD --device /dev/fuse:mrw and it'll work", but that is considered to be insecure.

Instead, just use the --appimage-extract-and-run parameter to the AppImage in your build script:

[...]
./appimagetool-*.AppImage --appimage-extract-and-run ...
[...]

You can also make appimagetool do this using export APPIMAGE_EXTRACT_AND_RUN=1

Note: appimagetool-*.AppImage can be extracted starting with release version 9

If you want to decide whether to use the AppImage directly or extracted depending on whether you're in a container or not, for example in a build script, you can combine this with some detection code.

More troubleshooting information

https://docs.appimage.org/user-guide/troubleshooting/fuse.html

Notes on FUSE version 3

https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 was released in December 2016. Early 2022, more than 5 years later, we are seeing this new major version as a problem, which goes like this:

  • libfuse 3.0.0 was "designed to be co-installable with libfuse 2" source
  • Initially, distributions happily shipped libfuse3 and libfuse2 in their repository
  • Until recently, distributions shipped libfuse2 in their default installation and on Live ISOs because other packages depended on it https://bugs.launchpad.net/ubuntu/+source/fuse3/+bug/1934510
  • Lately, distributions engaged in distribution-internal discussions (e.g., Ubuntu in in July 2021) to port everything that required libfuse2 to libfuse3 https://bugs.launchpad.net/ubuntu/+source/fuse3/+bug/1934510
  • However, no one discussed this with projects outside of distributions who are highly dependent on libfuse2 being available on all systems, like AppImage. How is a project that is not part of a Linux distribution supposed to know that a discussion buried away under a title like "[MIR] fuse3 as a dependency of qemu 6.0 and GNOME apps" means that soon libfuse2 that has been part of every Linux desktop for more than a decade will soon be no longer there by default?
  • As soon as they changed their own packages to no longer depend on libfuse2, they now no longer want to support it because it has not been actively maintained by upstream anymore.
  • In Ubuntu 21.10 (October 2021) libfuse3 is in universe (=unsupported) and libfuse2 is in main (=supported) (source) but just one version later in Ubuntu 22.04 (April 2022), libfuse3 is destined to be in main (=supported) and libfuse2 is in universe (=unsupported) (source), making both versions of libfuse supported in exactly 0 versions of Ubuntu. Even worse, both versions of libfuse are supported in exactly 0 LTS releases of Ubuntu. Not even one. How valuable is it to have libfuse 3.0.0 "designed to be co-installable with libfuse 2" when distributions don't want to support more than one version?
  • As a result, all existing applications (including all AppImages made so far) that rely on the existence of libfuse2 break
  • Meanwhile, libfuse is already at version 3.10.5 and no one knows how long it will be until an incompatible version 4.0.0 will appear, at which point the cycle of suffering will repeat itself?
  • Does anyone care about preserving the possibility to run old versions of applications on new distributions?

Takeaways

  • It would be helpful if Upstream authors of core system libraries did everything possible to avoid breaking changes (major versions) at all cost, as they create a huge pain and extra work for everyone even half a decade later
  • It would be very useful if Linux Foundation would define the Linux Standards Base Desktop again and lobby for distributions to comply to it
  • Also it would be very helpful if distributions made guarantees not to remove core system libraries nor to replace them with breaking new major versions without announcing the date of the switch a couple of years in advance, so that everyone has enough time to adopt
  • The mindset that only software that is constantly changed should be supported is adding plenty of work for everyone all the time. We should rethink our mindset. Isn't software that needs no further changes the most reliable and best software, after all?
  • There should be a policy that if a library in Ubuntu main gets upgraded to a new major version, the old major version would need to stay in main for at least one (1) LTS release of Ubuntu. Ubuntu just being used as an example here. Such policies would make distributions much more reliable and useful as a target for outside developers than they are today.

One can dream.

Clone this wiki locally