sshfs

How to mount remote machine’s directory on current host?

This question originally came up when I wanted to use Kate to edit a configuration file on macOS. I normally ssh into macOS, cd to that directory, and then type kate <file> to try opening the file for editing. But huh? There’s no kate command. Oh right, because I’m in the macOS environment, of course there’s no kate! But this is a problem - am I restricted to only using vi to edit remote files? I see Asahi Lina smoothly using Kate to open projects and files across multiple Mac machines around her to edit back and forth during development. There must be some way to make this work.

Turns out there’s a command called sshfs that can mount a remote directory onto the current localhost. Then you can normally cd to that mount point in the local environment , and use local editors like Kate, VS Code, or vi/vim to edit files and so on. All the operations are still happening on the remote, even if it looks like I’m editing a local file in a local directory.

Using sshfs mount remote directory at $USER directories (under $HOME).

sshfs <user>@<ipaddr>:/Users/thom/ ~/Desktop/remote-filesystem/

After running this, the remote filesystem will be accessible locally at ~/Desktop/remote-filesystem/. It can be unmounted using either fusermount -u remote-filesystem or sudo umount remote-filesystem.

After mounting with sshfs, the user and group for directory ~/Desktop/remote-filesystem will change to 501 and games. Here is the explaination of this from Claude.ai:

The user and group IDs you are seeing (501 and games) correspond to the user and primary group ownership of the mounted Mac directory on the Linux side.

On macOS, each user is assigned a UID (user ID) and GID (group ID). The first user created gets UID/GID 501 by default. And the primary group for users is normally the staff group, which has the GID of 20.

However, when you mount the Mac directory onto your Linux system using SSHFS, it does not map the macOS user and group names to Linux users and groups. Instead, it just exposes the raw numeric IDs from macOS.

So the user ID 501 and group ID games (which is probably 20) simply represent the macOS owner and group of the mounted directory. The names are shown as the numeric values since your Linux system does not have equivalently named users or groups defined.

This is expected behavior with SSHFS. The ownership stays the same numerically, but the names do not map over. Everything should still work properly, but you just see the raw IDs instead of translated names in the Linux listing.

Just be aware that the user and group will differ from what you may expect based on your local filesystem.

sshfs <user>@<ipaddr>:/Users/thom/ ~/Desktop/remote-filesystem/ -d

Adding the -d flag will enable debug mode and print debugging information, consequently blocking the current terminal session as long as the process is running. The debugging info looks like this:

$ sshfs mbp:/Users/thom/Desktop/ ~/Desktop/remote-filesystem/ -d
SSHFS version 3.7.3
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <mbp> <-s> <sftp>
Server version: 3
Extension: posix-rename@openssh.com <1>
Extension: statvfs@openssh.com <2>
Extension: fstatvfs@openssh.com <2>
Extension: hardlink@openssh.com <1>
Extension: fsync@openssh.com <1>
Extension: lsetstat@openssh.com <1>
Extension: limits@openssh.com <1>
Extension: expand-path@openssh.com <1>
Extension: copy-data <1>
Extension: home-directory <1>
Extension: users-groups-by-id@openssh.com <1>
[00001] EXTENDED
[00002] EXTENDED
  [00001] EXTENDED_REPLY       97bytes (5ms)
  [00002] EXTENDED_REPLY       97bytes (5ms)
[00003] LSTAT
  [00003]          ATTRS       41bytes (87ms)
[00004] LSTAT
  [00004]         STATUS       33bytes (8ms)
[00005] LSTAT
  [00005]         STATUS       33bytes (4ms)
[00006] LSTAT
  [00006]         STATUS       33bytes (5ms)
[00007] OPENDIR
  [00007]         HANDLE       17bytes (33ms)
...

You can still use fusermount -u remote-filesystem and sudo umount remote-filesystem to unmount it, once you unmount it, the debug info printing will stop:

...
[00015] LSTAT
  [00015]         STATUS       33bytes (5ms)

sent:               15 messages, 485 bytes
received:           15 messages, 1613 bytes
rtt min/max/avg:    4ms/106ms/16ms
num connect:        1

Additionally, you can pass -v to it: sshfs mbp:/Users/thom/ ~/Desktop/remote-filesystem/ -d -v. According to man sftp, the effect of -v is:

-v Raise logging level. This option is also passed to ssh.

Let’s dig more deep, take a closer look at the ssh man page man ssh:

-v Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3.

But anyway, it is doubtful whether this flag is effective in this case.

Using sshfs mount remote directory at /mnt (root directory)

It can also be used (without requiring sudo) to mount a remote directory at /mnt:

sshfs <user>@<ipaddr>:/Users/thom/ /mnt/remote-filesystem/

But even if I did not give it the allow_other flag: -o allow_other, at the mount point (in this case the /mnt/remote-filesystem/ directory) I can still cd into it as a normal user: cd /mnt/remote-filesystem.

Still, the user and group for /mnt/remote-filesystem is 501 and games.

The reason you can use fusermount -u remote-filesystem and sudo umount remote-filesystem to unmount remote filesystem…What’s the relationship between sshfs and FUSE filesystem?

man sshfs:

To mount a filesystem:

    sshfs [user@]host:[dir] mountpoint [options]

To unmount it:

    fusermount3 -u mountpoint   # Linux
    umount mountpoint           # OS X, FreeBSD

man mount.fuse:

FUSE filesystems are unmounted using the fusermount(1) command (fusermount -u mountpoint).

Some reference man page deserve to be further investigate:

• man sshfs
• man sftp
• man mount.fuse
• man fusermount