won't run (fuse error)

[2011]

I have about thirty other AppImages that all run without any issues, but (first time I tried this AppImage):

$ /tmp/Google-Chrome-Stable-125.0.6422.112-1-x86_64.AppImage 
fuse: failed to exec fusermount: Permission denied

Cannot mount AppImage, please check your FUSE setup.
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
open dir error: No such file or directory

$ qlist -Iv fuse
sys-fs/fuse-3.16.2
sys-fs/fuse-2.9.9-r2
sys-fs/fuse-common-3.10.4

$ which fusermount
/usr/bin/fusermount

$ ls -al /usr/bin/fusermount*
-rws--x--x 1 root root 35424 2022-11-30 07:12:21 /usr/bin/fusermount*
-rws--x--x 1 root root 34760 2023-12-18 23:25:57 /usr/bin/fusermount3*

Any ideas about what might cause this?

[ivan-hc]

This is a kind of AppImage that don't needs libfuse2

This issue seems to be a known one https://github.com/AppImage/type2-runtime/issues/15

I'm investigating, please wait.

[ivan-hc]

What is your distro?

I need to know how your fusermount installation is done.

For me /usr/bin/fusermount is a symlink to /usr/bin/fusermount3 (i use Debian)

$ ls -al /usr/bin/fusermount*
lrwxrwxrwx 1 root root    11 12 gen 16.46 /usr/bin/fusermount -> fusermount3
-rwsr-xr-x 1 root root 35128 12 gen 16.46 /usr/bin/fusermount3

[ivan-hc]

Just found a discussion with an Arch Linux user in one of my projects:

https://github.com/ivan-hc/AM/discussions/387

but the issue was been fixed.

In brief, on Arch Linux fusermount is a binary from the fuse2 package and fusermount3 is a binary from fuse3, while on Debian fusermount is a symlink to fusermount3.

@Samueru-sama was this been fixed in https://github.com/probonopd/go-appimage/issues/278 ?

[ivan-hc]

EndeavourOS is based on Arch Linux, so fusermount is a binary from the fuse2 package and fusermount3 is a binary from fuse3, but this AppImage works for me

[2011]

This is a kind of AppImage that don't needs libfuse2

This issue seems to be a known one AppImage/type2-runtime#15

I'm investigating, please wait.

Thank you for all of the quick replies.

Yes, you have certainly found the issue. I run Gentoo, and as you can see from my description of the issue, the fusermount binaries have permissions 4711. Changing the permissions solves the problem (though I won't want to leave them as 4755 forever, and any updates will return them to 4711).

Thank you again.

[ivan-hc]

forgive my ignorance, can adding your user to some groups make a difference?

[Samueru-sama]

The issue I had on archlinux was that I still needed fuse2 to run the furse3 appimages because the runtime was still looking for fusermount instead of fusermount3. On debian this issue didn't happen because fusermount is symlinked to fusermount3.

However the issue was fixed and I can now run fuse3 appimages without needing fuse2 installed.

The issue didn't have to do with permissions. On arch both fusermount and fusermount3 are 4755.

@2011 Do you have this issue when running the cemu appimage? that one also uses fuse3.

EDIT: Also I think this is something that needs to be reported to gentoo, all other distros use 4755 for fusermount, I even used voidlinux for a few days and didn't have this issue, although I didn't check if I had fuse3 installed in voidlinux and it was defaulting to fuse2.

[2011]

forgive my ignorance, can adding your user to some groups make a difference?

I can't think of any. The binaries (as shown in my original post) get installed as root:root, but with the suid bit set.

The issue I had on archlinux was that I still needed fuse2 to run the furse3 appimages because the runtime was still looking for fusermount instead of fusermount3.

Gentoo has different "slots" for fuse2 and fuse3 (meaning one can have both of them installed at the same time.

On debian this issue didn't happen because fusermount is symlinked to fusermount3.

However the issue was fixed and I can now run fuse3 appimages without needing fuse2 installed.

The issue didn't have to do with permissions. On arch both fusermount and fusermount3 are 4755.

On Gentoo, I renamed fusermount to fusermount2 and fusermount3 to fusermount, and neither the chrome AppImage nor the cemu AppImage would run with permissions set to 4711.

@2011 Do you have this issue when running the cemu appimage? that one also uses fuse3.

Yes (with permissions at 4711, it won't run - with the same error message as shown in my original post).

EDIT: Also I think this is something that needs to be reported to gentoo, all other distros use 4755 for fusermount, I even used voidlinux for a few days and didn't have this issue, although I didn't check if I had fuse3 installed in voidlinux and it was defaulting to fuse2.

I can mention this in their forums, but I would expect to get a lot of resistance for a change like that (it would require many more users to complain to make something happen). From reading the linked issue in the first reply by @ivan-hc, it appears that the test for the existence of fusermount consists of checking if the AppImage can read it (clearly wrong, as POSIX systems have never required the read permission to execute a file).

I see no activity on that issue over the past seven months. Not too surprising (things happen slowly in the AppImage world). I first brought up the issue of fuse 3 (to initial scorn, which soon changed to minor panic as distributions started dropping fuse 2) in https://github.com/AppImage/AppImageKit/issues/1120 more than three years ago.

[Samueru-sama]

Yes (with permissions at 4711, it won't run - with the same error message as shown in my original post).

Can you now try the appimage of amdgpu_top as that one is built with cargo appimage, it is also fuse3 compatible.

This appimage didn't have the issue with the lack of symlink that I had before with go-appimage. Maybe it doesn't have this issue.

which soon changed to minor panic as distributions started dropping fuse 2

Also a bit off topic, but how much a small panic was this? On arch fuse2 is a dependency for ntfs-3g and mtpfs ,so I don't think any distro will remove fuse2 from their repos anytime soon.

[2011]

Can you now try the appimage of amdgpu_top as that one is built with cargo appimage, it is also fuse3 compatible.

Exact same behavior.

Also a bit off topic, but how much a small panic was this?

If you read the replies to that issue, you would have seen it start when Ubuntu 22.04 came out (with fuse 3 and without the ability to install fuse 2 simultaneously), leading to lots of "I can't run AppImages any more" reports.

Ubuntu did provide plenty of warning:

https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041530.html

On arch fuse2 is a dependency for ntfs-3g and mtpfs ,so I don't think any distro will remove fuse2 from their repos anytime soon.

Gentoo uses fuse 3 for both of those. I would assume that Gentoo has kept fuse 2 around only to run AppImages.

[Samueru-sama]

Exact same behavior.

Oh boy, this isn't gonna be easy then. I think there is another implementation of appimagetool written in shell but I don't have high hopes that it will work.

If you read the replies to that issue, you would have seen it start when Ubuntu 22.04 came out (with fuse 3 and without the ability to install fuse 2 simultaneously), leading to lots of "I can't run AppImages any more" reports.

Gentoo uses fuse 3 for both of those. I would assume that Gentoo has kept fuse 2 around only to run AppImages.

I see, I knew that fusermount2 didn't come by default on ubuntu, but I didn't know that you couldn't have both installed.

[ivan-hc]

I don't know if this would be useful, but in case you wish to maintain just fuse3, my package manager "AM" allows you to install also just libfuse2 from the official Debian package using the command am -i libfuse2

I don't really know how can I help you in ths case.

[Samueru-sama]

I don't really know how can I help you in ths case.

I don't either, it's a shame cargo appimage also has the issue, because I have no problem switching all my appimages to use it.

[2011]

I see, I knew that fusermount2 didn't come by default on ubuntu, but I didn't know that you couldn't have both installed.

You probably can (manually, by renaming files and changing install directories, but Ubuntu doesn't support installing both simultaneously with their package manager).

I don't know if this would be useful, but in case you wish to maintain just fuse3, my package manager "AM" allows you to install also just libfuse2 from the official Debian package using the command am -i libfuse2

As much as I override default behaviors in Gentoo, I feel comfortable simply having both versions around as long as Gentoo supports it (and just temporarily changing the file permissions on fusermount when required).

Edit to add:

The lists of files in each package suggests how Gentoo handles having both versions installed:

$ qlist fuse-2.9.9-r2 | sort
/sbin/mount.fuse
/usr/bin/fusermount
/usr/bin/ulockmgr_server
/usr/include/fuse.h
/usr/include/fuse/cuse_lowlevel.h
/usr/include/fuse/fuse.h
/usr/include/fuse/fuse_common.h
/usr/include/fuse/fuse_common_compat.h
/usr/include/fuse/fuse_compat.h
/usr/include/fuse/fuse_lowlevel.h
/usr/include/fuse/fuse_lowlevel_compat.h
/usr/include/fuse/fuse_opt.h
/usr/include/ulockmgr.h
/usr/lib64/libfuse.so
/usr/lib64/libfuse.so.2
/usr/lib64/libfuse.so.2.9.9
/usr/lib64/libulockmgr.so
/usr/lib64/libulockmgr.so.1
/usr/lib64/libulockmgr.so.1.0.1
/usr/lib64/pkgconfig/fuse.pc
/usr/share/doc/fuse-2.9.9-r2/AUTHORS.bz2
/usr/share/doc/fuse-2.9.9-r2/ChangeLog.bz2
/usr/share/doc/fuse-2.9.9-r2/NEWS.bz2
/usr/share/doc/fuse-2.9.9-r2/README.NFS.bz2
/usr/share/doc/fuse-2.9.9-r2/README.md.bz2
/usr/share/doc/fuse-2.9.9-r2/how-fuse-works.bz2
/usr/share/doc/fuse-2.9.9-r2/kernel.txt.bz2
/usr/share/man/man1/fusermount.1.bz2
/usr/share/man/man1/ulockmgr_server.1.bz2
/usr/share/man/man8/mount.fuse.8.bz2

$ qlist fuse-3.16.2 | sort
/usr/bin/fusermount3
/usr/include/fuse3/cuse_lowlevel.h
/usr/include/fuse3/fuse.h
/usr/include/fuse3/fuse_common.h
/usr/include/fuse3/fuse_log.h
/usr/include/fuse3/fuse_lowlevel.h
/usr/include/fuse3/fuse_opt.h
/usr/include/fuse3/libfuse_config.h
/usr/lib64/libfuse3.so
/usr/lib64/libfuse3.so.3
/usr/lib64/libfuse3.so.3.16.2
/usr/lib64/pkgconfig/fuse3.pc
/usr/sbin/mount.fuse3
/usr/share/man/man1/fusermount3.1.bz2
/usr/share/man/man8/mount.fuse3.8.bz2

[Samueru-sama]

As much as I override default behaviors in Gentoo, I feel comfortable simply having both versions around as long as Gentoo supports it (and just temporarily changing the file permissions on fusermount when required).

You may want to write a script that automatically does this and checks the permissions of fusermount and fusermount3 and if they are not what it is needed it to be it automatically uses pkexec to change them back.

[rsau]

@2011

I had same issue with appimaged https://github.com/probonopd/go-appimage/issues/288 I had path /bin/fusermount After symlinking to /usr/bin/fusermount, it is working

[Samueru-sama]

@2011

I had same issue with appimaged probonopd/go-appimage#288 I had path /bin/fusermount After symlinking to /usr/bin/fusermount, it is working

So the problem is that the appimage is hardcoded to look for /usr/bin/fusermount and not that you don't have read access to the bin directories?

If the symlink solves the issue even when you don't have read access, the solution is very simple then:

Simply change the appimage to look for /bin/fusermount and /bin/fusermount3 that way it will always work.

I think probono is going to reinstate the look for binary path, which was removed due to security concerns, but if the issue is that it was looking for /usr/bin instead of /bin then that is all that needs to be changed. Because the distros that don't use /bin have it symlinked to /usr/bin already.

[Samueru-sama]

I booted into alpine with distrobox, alpine also install fusermount to /bin instead of /usr/bin.

I tried this htop appimage since it contains a static binary and uses go-appimage with the static runtime.

• If I'm logged as the normal user it doesn't work.

• if I'm logged as root it works.

• If I link /bin/fusermount to /usr/bin it also works when I'm logged as a regular user.

@probonopd I think that all that needs to be done is look for /bin/fusermount, /bin/fusermount3 and that is it, the distros that don't use /bin to install packages link that location to /usr/bin.

[probonopd]

Hi @Samueru-sama, I think this pull request might fix this: https://github.com/AppImage/type2-runtime/pull/32

[2011]

@2011 I had same issue with appimaged probonopd/go-appimage#288 I had path /bin/fusermount After symlinking to /usr/bin/fusermount, it is working

So the problem is that the appimage is hardcoded to look for /usr/bin/fusermount and not that you don't have read access to the bin directories?

If the symlink solves the issue even when you don't have read access, the solution is very simple then:

Simply change the appimage to look for /bin/fusermount and /bin/fusermount3 that way it will always work.

That doesn't work for me. I tried creating symlinks in /bin/, and running certain AppImages produces the same error as before.

The suggested solution seems completely wroing to me. Instead of testing to see if the AppImage can read /usr/bin/fusermount or /usr/bin/fusermount3, the AppImage should test if it can execute /usr/bin/fusermount or /usr/bin/fusermount3.

[probonopd]

If there is a fusermount binary on the $PATH which cannot be executed, it's a broken FUSE setup.