Ssh – Remount an SSHFS mount without umounting it

Have you tried "killall sshfs"? That always works for me. Of course if you have more than one, you might want to narrow it down (ps -ef f) + (kill ###). You might need to kill[all] "-9" ###.

I've found that certain unclean umounts leave the process running and tie up the sshfs system (or at least that directory) until the process is killed. (Sometimes, there's an "ssh" job forked from an sshfs, identifiable by a number of command line parameters including "ClearAllForwardings", as well as sshfs jobs)

Fractal

The question was answered in a linux mailing list; I post a translated answer here for completeness.

Solution

The solution is not to used both the options default_permissions and allow_other (which I didn't try in my original experiments).

Explanation

The problem seems to be quite simple. When you give the option default_permissions in fusermount then fuse's permission control of the fuse mount is handled by the kernel and not by fuse. This means that the REMOTE_USER's uid/gid aren't mapped to the LOCAL_USER (sshfs.c IDMAP_NONE). It works the same way as a simple nfs fs without mapping.

So, it makes sense to prohibit the access, if the uid/gid numbers don't match.

If you have the option allow_other then this dir is writable only by the local user with uid 699, if it exists.

From fuse's man:

'default_permissions'

   By default FUSE doesn't check file access permissions, the
   filesystem is free to implement its access policy or leave it to
   the underlying file access mechanism (e.g. in case of network
   filesystems).  This option enables permission checking, restricting
   access based on file mode.  It is usually useful together with the
   'allow_other' mount option.

'allow_other'

   This option overrides the security measure restricting file access
   to the user mounting the filesystem.  This option is by default only
   allowed to root, but this restriction can be removed with a
   (userspace) configuration option.