Digital Garden

Recent Notes

SSH file system share

2 min read

SSH file system share

Mounting a remote directory over SSH with sshfs is a convenient way to make remote files directly accessible on a Linux workstation or admin host without opening a broader network filesystem surface.

Command

sshfs [options] <user>@<host>:<source_path> <mount_point>

Usage

sshfs -o ro -o allow_other user@host:/remote/path /local/mount/point

When to reach for it

It fits occasional administrative access, inspecting remote data, and browsing a filesystem you do not want to set up NFS or SMB for. The appeal is that it needs nothing on the remote host beyond the SSH access you already have — no server to install, no export to configure, no firewall rule to request.

The trade is performance. Every filesystem operation becomes an SSH round trip, so latency dominates: listing a large directory or reading many small files is slow in a way that a local filesystem never prepares you for. It is fine for reading a config file on a remote host and wrong for anything touching a dataset — copy that with rsync and work locally.

The other caveat is that mounts do not survive a dropped connection gracefully. A stale mount blocks processes that touch it, sometimes unkillably, and fusermount -u is the thing to know before it happens rather than after.

Automation

  • Add to /etc/fstab to mount on startup:

    • file system: <user>@<host>:<path>
    • mount point: <mount_point>
    • type: fuse.sshfs
    • options: e.g identityFile=<path>, allow_other, defaults, default_permissions, idmap=user etc.
    • dump: 0
    • pass: 0

    Example

    • user@host:/remote/path /mnt/remote fuse.sshfs identityfile=/home/user/.ssh/id_ed25519,allow_other,defaults,default_permissions,idmap=user 0 0

Design cautions

  • sshfs favors convenience over performance.
  • Startup automation should account for network availability and key-management hygiene.
  • Shared access via allow_other deserves careful local permission handling.

Graph View

Backlinks