FS#61261 - [fuse-common] 3.3.0-1 missing fuse3 dependency/split-package issue

Attached to Project: Arch Linux
Opened by Peter Uchno (puchno) - Thursday, 03 January 2019, 09:59 GMT
Last edited by Anatol Pomozov (anatolik) - Tuesday, 28 July 2020, 18:52 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Anatol Pomozov (anatolik)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:
Version 3.3.0-1 of fuse-common contains a mount.fuse binary that links against libfuse3.so.3, which is part of fuse3. However, fuse-common does not explicitly depend on fuse3, leading to a shared library error when trying to mount fuse2-based filesystems using mount.fuse via an fstab entry.

This is because fuse2 pulls fuse-common in as a dependency, but that does not pull fuse3.

I don't know whether it should pull in fuse3, as far as I know mount.fuse and mount.fuse3 should link against fuse2 and fuse3 respectively, but I'll leave that up to the maintainers.

Installing fuse3 manually works as a workaround and the newer mount.fuse operates on fuse2-based filesystems, as far as I could tell in my testing.

Additional info:
* package version(s)
fuse-common 3.3.0-1
fuse2 2.9.8-1

I also tested fuse-common 3.4.1-1 from testing, but that is a regular upgpkg and the changes there will not fix this.

* config and/or log files etc.
Output of 'ldd /usr/bin/mount.fuse':
linux-vdso.so.1 (0x00007ffcf0d39000)
libfuse3.so.3 => not found
libc.so.6 => /usr/lib/libc.so.6 (0x00007f02a7b7d000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f02a7d6c000)

Steps to reproduce:
Install fuse-common, attempt to run mount.fuse:
% mount.fuse
mount.fuse: error while loading shared libraries: libfuse3.so.3: cannot open shared object file: No such file or directory
This task depends upon

Closed by  Anatol Pomozov (anatolik)
Tuesday, 28 July 2020, 18:52 GMT
Reason for closing:  Implemented
Comment by Guilherme (GUiHKX) - Monday, 14 January 2019, 09:57 GMT
I had to manually install fuse3 to fix this issue I was having with mounting shared folders in VMware.


$ journalctl -b -u mnt-hgfs.mount
-- Logs being at Sun 2018-04-22 00:57:23 -03, end at Mon 2019-01-14 07:43:40 -02. --
Jan 14 07:36:42 arch systemd[1]: mounting /mnt/hgfs...
Jan 14 07:36:42 arch mount[301]: /usr/bin/mount.fuse: error while loading shared libraries: libfuse3.so.3: cannot open shared object file: No such file or directory
Jan 14 07:36:42 arch systemd[1]: mnt-hgfs.mount: Mount process exited, code=exited, status=127/n/a
Jan 14 07:36:42 arch systemd[1]: mnt-hgfs.mount: Failed with result 'exit-code'.
Jan 14 07:36:42 arch systemd[1]: Failed to mount /mnt/hgfs.
Comment by Adam Nielsen (Malvineous) - Sunday, 24 February 2019, 09:01 GMT
Just upgraded my system and it wouldn't boot (dumping me in maintenance mode) because it was unable to mount my filesystems.

Problem turned out to be because mount.fuse couldn't run:

mount.fuse: error while loading shared libraries: libfuse3.so.3: cannot open shared object file: No such file or directory

I had upgraded to fuse-common 3.4.1-1 and it's still linking against libfuse3 which isn't installed as a dependency:

$ ldd /usr/bin/mount.fuse
linux-vdso.so.1 (0x00007ffff55e3000)
libfuse3.so.3 => not found
libc.so.6 => /usr/lib/libc.so.6 (0x00007f61a12df000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f61a14ce000)

After installing the "fuse3" package my system was able to boot again and the filesystems could all be mounted. Thanks @puchno for the workaround until this package gets fixed!
Comment by Anatol Pomozov (anatolik) - Sunday, 24 February 2019, 13:45 GMT
what filesystem type you are trying to mount?
Comment by Adam Nielsen (Malvineous) - Sunday, 24 February 2019, 14:32 GMT
I have a FUSE unionfs mount for my home directory, but the mount.fuse command fails when run with no arguments so this problem doesn't seem to depend on what the filesystem type is.
Comment by Anatol Pomozov (anatolik) - Sunday, 24 February 2019, 17:04 GMT
FYI: related discussion https://github.com/libfuse/sshfs/issues/92

fuse decision to move 'mount' binary (that suppose to work both with fuse2 and fuse3) into common package and make the binary depending to fuse3 is a bit weird. https://github.com/libfuse/libfuse/blob/fuse_3_0_bugfix/ChangeLog.rst

We can add fuse-common->fuse3 dependency but it will create a cyclic dependency which is not good.
Comment by Adam Nielsen (Malvineous) - Sunday, 24 February 2019, 22:30 GMT
Interesting, thanks for the links. The changelog says that mount.fuse is now mount.fuse3, so is it possible that the wrong mount.fuse version ended up in fuse-common? If mount.fuse requires fuse3 then it would seem to make some sense to call it mount.fuse3 and move it to the fuse3 package, but I'm not sure what dependency issues that would create.
Comment by DeLord (DeLord) - Wednesday, 10 July 2019, 14:02 GMT
Hoi, this issue is still existing. Is there any real solution available, or should we just stick to manually installing fuse3 when we encounter this problem?
Comment by Jason Croy (Lantorax) - Sunday, 18 August 2019, 23:01 GMT
Just noting that this is still an issue, and the fuse3 workaround still does work.
Comment by Hugo Arpin (hugoarpin) - Friday, 06 September 2019, 12:44 GMT
Why is the mount.fuse binary shipped within fuse-common. It seems to me fuse2 should ship mount.fuse and fuse3 should ship mount.fuse3, both of them are removed inside their PKGBUILD.
From what I read in https://github.com/libfuse/libfuse/blob/fuse_3_0_bugfix/ChangeLog.rst only the man page for mount.fuse (not the binaries) should be used in common.
The only downside I can see is that this would require users who use fuse3 to modify their fstab (fuse.xyz -> fuse3.xyz), but this would be the correct syntax anyway.
I don't understand how mount.fuse (which is linked against libfuse3) can work for fuse2 mounts (but it does). Shouldn't mount.fuse use libfuse.so and mount.fuse3 use libfuse3?
Is libfuse3 ABI compatible with libfuse? Anyway let me know if I'm wrong.
Comment by Anatol Pomozov (anatolik) - Friday, 13 September 2019, 17:42 GMT
Changing the mount binary and type from "fuse" to "fuse3" means that users need to update their scripts and fstab every time any of the filesystem migrates from libfuse2 to libfuse3. Which is ugly and I personally think upstream goes a wrong way here.
Comment by Anatol Pomozov (anatolik) - Monday, 16 September 2019, 00:08 GMT
Alright,

while I am not fully agree what upstream does we still want to stick with the direction where the go to. I just moved the mount binaries back to fuse/fuse3. Please check 'fuse2-2.9.9-2' 'fuse3-3.6.2-2' in [testing] repo and let me know if you see any issues with it.

After this refactoring 'fuse-common' contains only '/etc/fuse.conf'.
Comment by Hugo Arpin (hugoarpin) - Monday, 16 September 2019, 11:26 GMT
I tested with the testing repo and it works for me, I can uninstall fuse3 and fuse2 mounts works. I have not tested fuse3 mounts.
I agree with you that it is very irritating that the user has to know and update his fstab/scripts depending on the version, but that's the way they went upstream.

Loading...