New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install mount.sshfs symlink #92

Closed
anatol opened this Issue Sep 10, 2017 · 18 comments

Comments

Projects
None yet
3 participants
@anatol
Contributor

anatol commented Sep 10, 2017

Here is a follow-up for Arch discussions

https://bugs.archlinux.org/task/55564
https://bbs.archlinux.org/viewtopic.php?id=229656

Fuse 3.0 release documentation states there should be two separate mount binaries: mount.fuse and mount.fuse3. As such any fuse filesystem that is linked against fuse3 package (like current Arch sshfs) should be mounted in /etc/fstab with filesystem type fuse3.sshfs. This in turn requires changes to user configs. Is it something sshfs/fuse developers did intentionally? Is there any chance to have just one mount.fuse binary?

If you suggest fuse3.sshfs then it seems has another problem:

$ mount /media
/bin/sh: fuse3.sshfs: command not found
@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 11, 2017

Contributor

The issue is that fuse 2.x and fuse 3.x are fundamentally incompatible, and that file systems designed for fuse 2.x are expected to stay around for a long time. So the only way to use fuse 2.x and 3.x file systems at the same time is for fuse 3.x to use new names for the binaries.

Symlinking mount.fuse to mount.fuse3 is a bad idea and will lead to trouble sooner or later.

If SSHFS is designed for libfuse3 but installs as fuse.sshfs, that's a bug in SSHFS. But I believe SSHFS installs simply as sshfs. Is maybe something in Arch creating a symlink from fuse.sshfs?

Unfortunately I do not see a way to avoid changing entries in fstab.

Contributor

Nikratio commented Sep 11, 2017

The issue is that fuse 2.x and fuse 3.x are fundamentally incompatible, and that file systems designed for fuse 2.x are expected to stay around for a long time. So the only way to use fuse 2.x and 3.x file systems at the same time is for fuse 3.x to use new names for the binaries.

Symlinking mount.fuse to mount.fuse3 is a bad idea and will lead to trouble sooner or later.

If SSHFS is designed for libfuse3 but installs as fuse.sshfs, that's a bug in SSHFS. But I believe SSHFS installs simply as sshfs. Is maybe something in Arch creating a symlink from fuse.sshfs?

Unfortunately I do not see a way to avoid changing entries in fstab.

@Nikratio Nikratio closed this Sep 11, 2017

@majewsky

This comment has been minimized.

Show comment
Hide comment
@majewsky

majewsky Sep 11, 2017

Unfortunately I do not see a way to avoid changing entries in fstab.

How? As said above, a filesystem type of fuse3.sshfs in fstab does not work.

majewsky commented Sep 11, 2017

Unfortunately I do not see a way to avoid changing entries in fstab.

How? As said above, a filesystem type of fuse3.sshfs in fstab does not work.

@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 11, 2017

Contributor

I believe with a standard sshfs installation, a fuse.sshfs entry never worked either. There's some magic in the Arch packaging that made it work, and that magic needs to be adjusted.

Contributor

Nikratio commented Sep 11, 2017

I believe with a standard sshfs installation, a fuse.sshfs entry never worked either. There's some magic in the Arch packaging that made it work, and that magic needs to be adjusted.

@anatol

This comment has been minimized.

Show comment
Hide comment
@anatol

anatol Sep 12, 2017

Contributor

@Nikratio would it be possible to make mount.fuse handle both fuse2 and fuse3? The fact whether filesystem linked with library v2 or v3 is really an implementation detail and should not be dumped on users. Having a single filesystem name would simplify the migration.

Contributor

anatol commented Sep 12, 2017

@Nikratio would it be possible to make mount.fuse handle both fuse2 and fuse3? The fact whether filesystem linked with library v2 or v3 is really an implementation detail and should not be dumped on users. Having a single filesystem name would simplify the migration.

@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 12, 2017

Contributor

I've never worked with this part of the code before, but looking at mount.fuse.c it seems that this is really just a wrapper that, when called for fuse.foo attempts to exec foo instead. So it should be possible to extend this to work with fuse3.foo. But there is a problem: how do we guarantee that mount.fuse exists? If we ship it with libfuse2 and libfuse3, they conflict again. If we ship it in only one version, it may be missing on systems that only have the other version.

Contributor

Nikratio commented Sep 12, 2017

I've never worked with this part of the code before, but looking at mount.fuse.c it seems that this is really just a wrapper that, when called for fuse.foo attempts to exec foo instead. So it should be possible to extend this to work with fuse3.foo. But there is a problem: how do we guarantee that mount.fuse exists? If we ship it with libfuse2 and libfuse3, they conflict again. If we ship it in only one version, it may be missing on systems that only have the other version.

@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 12, 2017

Contributor

An alternative solution (that would have to be implemented for every filesystem though) is for SSHFS simply to install not just the sshfs binary, but also a symlink from mount.fuse.sshfs.

Contributor

Nikratio commented Sep 12, 2017

An alternative solution (that would have to be implemented for every filesystem though) is for SSHFS simply to install not just the sshfs binary, but also a symlink from mount.fuse.sshfs.

@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 12, 2017

Contributor

Actually, I think the cleanest solution in the long-term is for SSHFS to install a mount.sshfs symlink and require users to put sshfs instead of fuse.sshfs into /etc/fstab. That way, there's no dependency on the FUSE version.

Contributor

Nikratio commented Sep 12, 2017

Actually, I think the cleanest solution in the long-term is for SSHFS to install a mount.sshfs symlink and require users to put sshfs instead of fuse.sshfs into /etc/fstab. That way, there's no dependency on the FUSE version.

@Nikratio Nikratio self-assigned this Sep 12, 2017

@Nikratio Nikratio changed the title from Using sshfs in /etc/fstab causes confusing with "mount.fuse" to Install mount.sshfs symlink Sep 12, 2017

@anatol

This comment has been minimized.

Show comment
Hide comment
@anatol

anatol Sep 12, 2017

Contributor

it seems that this is really just a wrapper

Yes, and that is why I think it should be shared and user config changes should be avoided.

If we ship it with libfuse2 and libfuse3, they conflict again.

fuse2 and v3 already ship conflicting files. https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 states:

However, some files will be installed by both libfuse 2 and libfuse 3 (e.g. /etc/fuse.conf, the udev and init scripts, and the
mount.fuse(8) manpage).

It makes sense to include fuse.mount to the list as well.

Arch Linux resolves the conflict by having fuse-common package with common files. Other distros have similar solution. If you confirm that fuse.mount is going to be shared between the versions then I'll make Arch Linux changes and it will fix the original issue.

Contributor

anatol commented Sep 12, 2017

it seems that this is really just a wrapper

Yes, and that is why I think it should be shared and user config changes should be avoided.

If we ship it with libfuse2 and libfuse3, they conflict again.

fuse2 and v3 already ship conflicting files. https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 states:

However, some files will be installed by both libfuse 2 and libfuse 3 (e.g. /etc/fuse.conf, the udev and init scripts, and the
mount.fuse(8) manpage).

It makes sense to include fuse.mount to the list as well.

Arch Linux resolves the conflict by having fuse-common package with common files. Other distros have similar solution. If you confirm that fuse.mount is going to be shared between the versions then I'll make Arch Linux changes and it will fix the original issue.

@anatol

This comment has been minimized.

Show comment
Hide comment
@anatol

anatol Sep 12, 2017

Contributor

And the same question applies to fusermount binary. The binary does not use libfuse shared library. In this case does the binary need to be duplicated in fuse2 and fuse3?

Contributor

anatol commented Sep 12, 2017

And the same question applies to fusermount binary. The binary does not use libfuse shared library. In this case does the binary need to be duplicated in fuse2 and fuse3?

@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 12, 2017

Contributor

The interface between the shared object and fusermount will change (actually, it might have already - not sure what I committed when), so there needs to be one fusermount per so version.

Contributor

Nikratio commented Sep 12, 2017

The interface between the shared object and fusermount will change (actually, it might have already - not sure what I committed when), so there needs to be one fusermount per so version.

@Nikratio Nikratio reopened this Sep 12, 2017

@anatol

This comment has been minimized.

Show comment
Hide comment
@anatol

anatol Sep 12, 2017

Contributor

The interface between the shared object and fusermount

What kind of changes is it? Is it possible for fusermount to detect the fuse version and handle differences internally? Having only one fusermount version that works the same way for all fuse filesystems would definitely improve user experience.

Contributor

anatol commented Sep 12, 2017

The interface between the shared object and fusermount

What kind of changes is it? Is it possible for fusermount to detect the fuse version and handle differences internally? Having only one fusermount version that works the same way for all fuse filesystems would definitely improve user experience.

@anatol

This comment has been minimized.

Show comment
Hide comment
@anatol

anatol Sep 12, 2017

Contributor

Also note that fusermount/fusermount3 does not link with libfuse shared library:

$ ldd /usr/bin/fusermount3
	linux-vdso.so.1 (0x00007ffe86cfe000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fa6dd144000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fa6dd703000)
Contributor

anatol commented Sep 12, 2017

Also note that fusermount/fusermount3 does not link with libfuse shared library:

$ ldd /usr/bin/fusermount3
	linux-vdso.so.1 (0x00007ffe86cfe000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fa6dd144000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fa6dd703000)
@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 12, 2017

Contributor

Almost anything is possible if someone does the work :-). For me, having fusermount be cross-version compatible is very low on the priority list. Yes, fusermount does not link against libfuse.so.

Contributor

Nikratio commented Sep 12, 2017

Almost anything is possible if someone does the work :-). For me, having fusermount be cross-version compatible is very low on the priority list. Yes, fusermount does not link against libfuse.so.

@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 12, 2017

Contributor

See libfuse/libfuse#77 for an example of the changes in the libfuse.so / fusermount interface.

Contributor

Nikratio commented Sep 12, 2017

See libfuse/libfuse#77 for an example of the changes in the libfuse.so / fusermount interface.

@anatol

This comment has been minimized.

Show comment
Hide comment
@anatol

anatol Sep 13, 2017

Contributor

Thanks for details.

What about mount.fuse binary? Could it be shared between different fuse versions? If yes it would simplify user's life.

Contributor

anatol commented Sep 13, 2017

Thanks for details.

What about mount.fuse binary? Could it be shared between different fuse versions? If yes it would simplify user's life.

@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 14, 2017

Contributor

Technically it would be easy enough since it's just a wrapper. Not sure if I like the idea of two packaging installing the same binary though. Configuration files are different.

Contributor

Nikratio commented Sep 14, 2017

Technically it would be easy enough since it's just a wrapper. Not sure if I like the idea of two packaging installing the same binary though. Configuration files are different.

@majewsky

This comment has been minimized.

Show comment
Hide comment
@majewsky

majewsky Sep 14, 2017

What about doing the same thing that Arch is already doing in their packaging, and putting the common parts in a fuse-common repository with a separate release tarball? It's probably too late to make this a dependency of Fuse 2, but it could be a dependency of Fuse 3 and all later versions.

majewsky commented Sep 14, 2017

What about doing the same thing that Arch is already doing in their packaging, and putting the common parts in a fuse-common repository with a separate release tarball? It's probably too late to make this a dependency of Fuse 2, but it could be a dependency of Fuse 3 and all later versions.

@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio Sep 14, 2017

Contributor

Could be done, but I am not sure if the extra work is worth the gain.

Contributor

Nikratio commented Sep 14, 2017

Could be done, but I am not sure if the extra work is worth the gain.

@Nikratio Nikratio closed this in 82dfbeb Sep 20, 2017

Nikratio added a commit that referenced this issue Sep 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment