I just pushed fuse2/fuse3 update to [testing]. Please try it.
]]>$ mount /media
/bin/sh: fuse3.sshfs: command not found
I expect this part works. Could you please run it with 'strace -f mount /media' and post the logs here?
]]>I was initially reluctant to file a bug because the issue looked like a PEBKAC, so thanks @GenkiSky for confirming that it is indeed a problem with the sshfs package (or maybe even with fuse3). Your workaround works for me as well, by the way, so thanks for that as well.
]]>First, about filesystem types, note you can run 'mount' with no arguments to see how a filesystem is mounted. So e.g. 'mount | grep sshfs' should show you that when you are able to successfully mount your sshfs folder using sshfs directly, the filesystem type is still fuse.sshfs.
Anyway, by running 'strace mount /mnt/sshfs', I see that it looks for: /sbin/mount.fuse.sshfs, /sbin/mount.fuse, /sbin/fs.d/mount.fuse.sshfs, /sbin/fs.d/mount.fuse, /sbin/fs/mount.fuse.sshfs, /sbin/fs/mount.fuse, /usr/bin/mount.fuse.sshfs, and /usr/bin/mount.fuse . In other words, none of them are we want it to find . So a workaround then is to run 'ln -s /usr/bin/mount.fuse3 /usr/bin/mount.fuse'; I confirmed this makes mount(1) work correctly.
Anyway, regardless of the workaround, there's a bug somewhere in the stack (or documentation...) here. I'm not wanting to spend more time looking now as I don't use sshfs, but your best bet is probably to email the fuse3 packagers: https://git.archlinux.org/svntogit/pack … s/fuse3#n2
]]>$ mount /media
mount: /media: wrong fs type, bad option, bad superblock on stefan@10.0.0.1:/media, missing codepage or helper program, or other error.
This is the fstab entry, for reference: (some parts redacted)
<username>@<remote-ip>:/media /media fuse.sshfs noauto,user,_netdev,idmap=user,transform_symlinks,IdentityFile=/home/<username>/.ssh/id_<keyname>,allow_other,default_permissions,uid=<numeric-id>,gid=<numeric-id>,reconnect 0 0
Just to clarify, "user_allow_other" is set in /etc/fuse.conf. This used to work until today. A quick looking around the logs turned up this as the issue:
$ grep fuse /var/log/pacman.log
...
[2017-09-03 18:38] [ALPM] removed fuse2 (2.9.7-3)
This was removed as part of my regular cleanup operations, i.e.
$ sudo pacman -Rns $(pacman -Qqdtt)
And indeed, package sshfs depends only on package fuse3, not on fuse2. sshfs itself confirms this:
$ sshfs --version
SSHFS version 3.1.0
FUSE library version 3.1.1
using FUSE kernel interface version 7.26
fusermount3 version: 3.1.1
And in fact, using the sshfs command directly works perfectly:
$ sshfs <remote-ip>:/media /media -o <bunch-of-options>
$ echo $?
0
I can make "mount /media" work again by reinstalling fuse2, but that's obviously not a sustainable solution. I looked around the fuse2 and fuse3 packages and saw this:
$ pacman -Ql fuse2 | grep bin/mount
fuse2 /usr/bin/mount.fuse
$ pacman -Ql fuse3 | grep bin/mount
fuse3 /usr/bin/mount.fuse3
Which lead me to making an educated guess that I could maybe coerce mount(1) into using fuse3 by setting the FS type to "fuse3.sshfs" (instead of "fuse.sshfs") in the fstab. Doesn't work, though:
$ mount /media
/bin/sh: fuse3.sshfs: command not found
Any idea what is going wrong? The wiki page on SSHFS shows an fstab entry that is basically identical to what I'm doing, so I'm going to guess that it has not yet been touched since fuse2 was superseded by fuse3. I have the mild suspicion that this is a packaging error (i.e. package sshfs is missing some integration bit that's needed for it to work with fuse3 when mounting happens via mount(1) and fstab), but I don't yet feel qualified to make that judgment.
]]>