SSHFS and Remote File Access

SSHFS lets you mount a remote directory over SSH as if it were a local filesystem. There is no server-side configuration beyond a working SSH daemon -- the FUSE (Filesystem in Userspace) driver on the client does all the work. This makes SSHFS the simplest way to browse, edit, and manage remote files interactively.

This guide covers installation, mounting, fstab entries, reconnect and caching options for performance, unmounting, and a comparison with NFS and SMB for different use cases.

Part of the VPN and SSH guide series. See also: rsync Over SSH | SSH Tunneling | OpenVPN Guide

Installation

# Debian / Ubuntu
sudo apt update
sudo apt install sshfs

# RHEL / Fedora
sudo dnf install fuse-sshfs

# macOS (via Homebrew + macFUSE)
brew install macfuse
brew install gromgit/fuse/sshfs-mac

On Linux the user must belong to the fuse group (or run as root):

sudo usermod -aG fuse $USER
# Log out and back in for the group change to take effect.

Basic Mount

mkdir -p ~/remote-server

sshfs [email protected]:/var/www ~/remote-server

The remote /var/www is now accessible under ~/remote-server. You can ls, cp, edit files with your local editor -- everything works transparently.

Mount with specific SSH options

sshfs user@server:/data ~/mnt/data \
    -p 2222 \
    -o IdentityFile=~/.ssh/id_ed25519 \
    -o reconnect \
    -o ServerAliveInterval=15

Commonly Used Options

Option	Purpose
`-o reconnect`	Automatically reconnect if the SSH session drops.
`-o ServerAliveInterval=N`	Send a keepalive every N seconds (prevents idle disconnects).
`-o ServerAliveCountMax=N`	Disconnect after N missed keepalives.
`-o IdentityFile=PATH`	SSH private key to use.
`-o compression=yes`	Enable SSH compression (beneficial on slow links).
`-o allow_other`	Allow other users to access the mount (requires `user_allow_other` in `/etc/fuse.conf`).
`-o default_permissions`	Let the kernel enforce file permissions instead of the FUSE daemon.
`-p PORT`	Connect to a non-standard SSH port.

Performance Tuning with Caching

SSHFS is inherently slower than local filesystems because every operation crosses the network. Caching options reduce the number of round trips.

sshfs user@server:/data ~/mnt/data \
    -o reconnect \
    -o cache=yes \
    -o cache_timeout=300 \
    -o attr_timeout=300 \
    -o entry_timeout=300 \
    -o kernel_cache \
    -o large_read \
    -o [email protected]

Option details

Option	Effect
`cache=yes`	Enable the SSHFS internal cache (default in recent versions).
`cache_timeout=300`	Cache file contents for 300 seconds.
`attr_timeout=300`	Cache file attributes (size, permissions) for 300 seconds.
`entry_timeout=300`	Cache directory entries for 300 seconds.
`kernel_cache`	Use the kernel page cache. Avoids re-reading unmodified files.
`large_read`	Issue larger read requests (improves throughput for sequential reads).
`[email protected]`	Faster cipher (if the CPU supports AES-NI).

Trade-off: aggressive caching improves speed but means local changes on the server may take up to cache_timeout seconds to appear. For collaborative editing, lower these values or disable caching.

Persistent Mounts via fstab

Add an entry to /etc/fstab so the mount is re-established at boot:

user@server:/data  /mnt/data  fuse.sshfs  _netdev,user,idmap=user,reconnect,IdentityFile=/home/user/.ssh/id_ed25519,ServerAliveInterval=15,allow_other  0  0

Key fstab flags:

Flag	Purpose
`_netdev`	Wait for the network before mounting.
`user`	Allow non-root users to mount.
`idmap=user`	Map the remote user's UID to the local user's UID.

Then mount with:

sudo mount /mnt/data
# or
sudo mount -a

Using systemd automount

For on-demand mounting (mount only when accessed), create two systemd units.

/etc/systemd/system/mnt-data.mount:

[Unit]
Description=SSHFS mount of server:/data
After=network-online.target
Wants=network-online.target

[Mount]
What=user@server:/data
Where=/mnt/data
Type=fuse.sshfs
Options=_netdev,reconnect,IdentityFile=/home/user/.ssh/id_ed25519,ServerAliveInterval=15,allow_other

[Install]
WantedBy=multi-user.target

/etc/systemd/system/mnt-data.automount:

[Unit]
Description=Automount SSHFS server:/data

[Automount]
Where=/mnt/data
TimeoutIdleSec=600

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mnt-data.automount

The mount activates the first time /mnt/data is accessed and automatically unmounts after 600 seconds of inactivity.

Unmounting

# Standard unmount
fusermount -u ~/remote-server

# Force unmount if the connection is dead (Linux)
fusermount -uz ~/remote-server

# macOS
umount -f ~/remote-server

-z (lazy) detaches the filesystem immediately; pending operations finish in the background.

SSHFS vs NFS vs SMB (CIFS)

Feature	SSHFS	NFS (v4)	SMB (CIFS)
Server setup	None (just sshd)	NFS server + exports	Samba server + shares
Encryption	Built-in (SSH)	Kerberos or VPN wrapper	Optional (SMB3 encryption)
Performance	Moderate	High (kernel-level)	High (kernel-level)
Multi-user	Limited (FUSE)	Native	Native
Cross-platform	Linux, macOS, Windows (via WinFsp)	Linux, macOS (limited)	All major OSes
Best for	Ad-hoc single-user access	Permanent LAN shared storage	Windows-integrated environments

When to choose SSHFS:

You need quick, encrypted access without configuring a server.
The use case is a single user editing files remotely.
The connection crosses the internet (SSH encryption is non-negotiable).

When to choose NFS or SMB:

Multiple users or services need concurrent, high-throughput access.
The network is trusted (LAN) or already encrypted (VPN).
You need POSIX-compatible locking (NFS) or Windows ACLs (SMB).

Troubleshooting

Symptom	Fix
`fuse: device not found`	Load the FUSE kernel module: `sudo modprobe fuse`.
`Permission denied` on mount	Add user to the `fuse` group; check `user_allow_other` in `/etc/fuse.conf`.
Hangs after network interruption	Use `-o reconnect` and `ServerAliveInterval`. Force-unmount with `fusermount -uz`.
Slow performance	Enable caching options; switch to a faster cipher; check network latency.
Files owned by wrong user	Use `-o idmap=user` or `-o uid=N,gid=N`.

Return to the VPN and SSH hub for more guides, or continue with rsync Over SSH.