Mount Remote Directory with SSHFS on Linux & Windows

Use SSHFS when you want a remote Linux folder to appear as a normal directory on your laptop. To mount a remote directory means making it show up at a local folder such as ~/remote-mount. After that, programs open that local path even though the files live on another server. You can edit files in an editor, drag folders in a file manager, or run scripts against live data without copying everything first.

You need working SSH login to the remote host before any mount will succeed. The walkthrough below uses a regular Linux user for mounts, fusermount3 -u to disconnect, and current Windows SSHFS-Win path prefixes (.r, .k, .kr) when you map a network drive.

What is SSHFS?

SSHFS (SSH Filesystem) presents a remote directory through the SSH/SFTP subsystem. FUSE (Filesystem in Userspace) lets a normal program provide a filesystem without putting that driver inside the Linux kernel. SSHFS uses FUSE so remote SFTP files appear under a normal local directory.

You run sshfs on your local machine; the remote server only needs a normal SSH daemon with SFTP enabled — no extra server package.

SSHFS mounts a filesystem. It is not a replacement for scp or rsync when you only need to copy a file once and disconnect.

SSHFS fits admin work, log inspection, light editing on a remote app server, or giving a Windows desktop a drive letter to a Linux path — as long as you accept SSH latency and encryption overhead.

SSHFS vs SCP vs SFTP vs rsync

All of these ride on SSH, but the workflow differs:

• SSHFS — persistent mount; apps use normal open(), read(), write() on a local path.
• SCP / SFTP — session-based copy or interactive transfer; no mount point.
• rsync — compares and synchronizes trees; ideal for backups and deploys, not live editing through a mount.

Pick SSHFS when the remote tree should stay visible under one local path. Pick scp or rsync when you are moving a known set of files and done.

How SSHFS works

When a program opens a file inside ~/remote-mount, FUSE passes that request to SSHFS. SSHFS sends the request securely over SSH/SFTP to the remote server and returns the file data to your program.

  ┌──────────────┐     ┌─────────┐     ┌──────────────┐     ┌────────────────┐
  │ Local apps   │ ──► │  FUSE   │ ──► │ sshfs client │ ──► │ sshd / SFTP    │
  │ (vim, cp, …) │     │ mount   │     │ over SSH     │     │ remote path    │
  └──────────────┘     └─────────┘     └──────────────┘     └────────────────┘
        ▲                      │
        └──── ~/remote-mount ──┘

The mount point is an ordinary directory on your machine until you unmount it. Permissions on the remote side still apply — SSHFS does not bypass chmod, ownership, or SELinux on the server.

Prerequisites

Before you install SSHFS, confirm the basics:

• SSH login works for the account you plan to mount as (password or key). If login fails, run the layered checks in test SSH connection before debugging SSHFS.
• The remote sshd exposes the SFTP subsystem (default on OpenSSH).
• Your workstation has FUSE 3 and the sshfs client package.
• The remote server does not need SSHFS installed — only OpenSSH server.

Create a local mount point owned by your user:

mkdir -p ~/remote-mount

mkdir prints nothing on success; the directory should exist and be writable by you.

Install SSHFS on Linux

RHEL 10, Rocky Linux, and AlmaLinux

On RHEL 10 family systems, fuse-sshfs ships in EPEL. Enable EPEL if you have not already, then install the client:

sudo dnf install -y epel-release

EPEL installs quietly when the repository is already configured.

Install the SSHFS client package:

sudo dnf install -y fuse-sshfs

Sample output:

Installed:
  fuse-sshfs-3.7.3-10.el10_0.x86_64    openssh-askpass-9.9p1-25.el10_2.x86_64
Complete!

Confirm the client version:

sshfs --version

Sample output:

SSHFS version 3.7.3
FUSE library version 3.16.2
fusermount3 version: 3.16.2

The fusermount3 line confirms the FUSE 3 unmount helper you will use later.

RHEL 9 family

Use the same EPEL workflow on RHEL 9, Rocky 9, and AlmaLinux 9:

sudo dnf install -y epel-release
sudo dnf install -y fuse-sshfs

Package names match RHEL 10; only the EPEL release package version differs by major OS.

Ubuntu and Debian

On Debian-based systems the client package is named sshfs:

sudo apt update
sudo apt install -y sshfs

Verify with sshfs --version after install.

Fedora

Fedora includes fuse-sshfs in the main repositories:

sudo dnf install -y fuse-sshfs

Mount a remote directory with SSHFS

Basic SSHFS syntax

The mount command shape is:

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

Run sshfs on the machine where you want the folder to appear — not on the remote server.

Mount a specific remote directory

Replace deploy and vm2.lab.example with your SSH user and host. Mount /var/www/app at ~/remote-mount:

sshfs deploy@vm2.lab.example:/var/www/app ~/remote-mount

If key-based login is configured, the mount succeeds without a password prompt. Otherwise SSH asks for the remote account password once.

Mount the remote home directory

Omit the path after the colon to mount the remote user’s home directory:

sshfs deploy@vm2.lab.example: ~/remote-mount

List the mount to confirm you see that user’s home contents:

ls -la ~/remote-mount

Sample output:

total 32
drwx------. 1 deploy deploy 118 Sep 24 12:27 .
drwx------. 6 dev    dev    124 Sep 24 12:27 ..
-rw-r--r--. 1 deploy deploy  18 Oct 29  2024 .bash_logout
-rw-r--r--. 1 deploy deploy 144 Oct 29  2024 .bash_profile
drwxr-xr-x. 1 deploy deploy  22 Sep 24 11:00 projects

Use a non-default SSH port

Pass the port with -p or -o port=:

sshfs -p 2222 deploy@vm2.lab.example:/var/www/app ~/remote-mount

The same port must answer when you test SSH connectivity before SSHFS will connect.

Mount with a specific SSH private key

Point SSHFS at an identity file when it is not your default key:

sshfs deploy@vm2.lab.example:/var/www/app ~/remote-mount -o IdentityFile=~/.ssh/deploy_ed25519

For passwordless automation, set up SSH key authentication on the client and authorize the public key on the server first.

Verify the SSHFS mount

findmnt shows the FUSE target and source in one line:

findmnt ~/remote-mount

Sample output:

TARGET            SOURCE                                      FSTYPE     OPTIONS
/home/dev/remote-mount deploy@vm2.lab.example:/var/www/app fuse.sshfs rw,nosuid,nodev,relatime,user_id=1001,group_id=1001

mount filters the same information:

mount | grep remote-mount

Sample output:

deploy@vm2.lab.example:/var/www/app on /home/dev/remote-mount type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)

df reports space using the remote filesystem’s statistics:

df -h ~/remote-mount

Sample output:

Filesystem                               Size  Used Avail Use% Mounted on
deploy@vm2.lab.example:/var/www/app       25G   22G  3.9G  85% /home/dev/remote-mount

Access and modify files through the mount

Once mounted, treat ~/remote-mount like any local folder. Reads, creates, edits, and deletes go over SFTP; the server enforces permissions on every operation.

List existing files:

ls -l ~/remote-mount

Sample output:

total 4
-rw-r--r--. 1 deploy deploy 19 Sep 24 12:00 readme.txt

Create a file from the client:

echo 'written from laptop' > ~/remote-mount/from-client.txt

echo returns silently; confirm on the mount:

cat ~/remote-mount/from-client.txt

Sample output:

written from laptop

The same file appears on the server at /var/www/app/from-client.txt with ownership and mode determined by the remote deploy account and directory ACLs — not by your local username alone.

SSHFS permissions and ownership

How SSHFS permissions work

SSHFS forwards file operations to SFTP. What you can read or write depends on the remote UID’s rights on each path. A mount owned by your local user still shows remote user:group in ls output.

default_permissions

By default, SSHFS relies mainly on the permissions enforced by the remote server for the SSH account you connected with. It does not normally enforce an additional set of local Unix permission checks on the mounted view.

-o default_permissions tells FUSE to also let the local kernel check file permissions before sending the operation to the remote server.

This matters most with allow_other, because other local users can access the mount. Upstream SSHFS recommends combining allow_other with default_permissions in that case.

allow_other

-o allow_other lets users other than the mounter access the mount. Before you use it, confirm /etc/fuse.conf on the client contains an uncommented line:

user_allow_other

If that line is missing, add it with sudo, then mount with both allow_other and default_permissions:

sshfs deploy@vm2.lab.example:/var/www/app ~/remote-mount -o allow_other,default_permissions

If user_allow_other is still missing when you mount, SSHFS returns:

fusermount3: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf

Only enable allow_other when you understand the exposure — any local user could reach the remote tree through your SSH session.

UID and GID mapping

Linux identifies file owners with numeric user IDs (UIDs) and group IDs (GIDs). Your laptop and the remote server may use different numbers for their users, so ownership shown through SSHFS can look unexpected.

By default, SSHFS does not translate those IDs (idmap=none). For a simple single-user mount, use:

sshfs deploy@vm2.lab.example:/var/www/app ~/remote-mount -o idmap=user

idmap=user maps files owned by the remote SSH user to the local user who ran sshfs. The upstream manual also documents idmap=file when you need a mapping file; most readers can skip that unless numeric ownership mismatches persist after idmap=user.

Keep the SSHFS connection alive

SSH sessions drop when NAT firewalls or idle timeouts close the channel. Pass OpenSSH keepalive options through SSHFS:

sshfs deploy@vm2.lab.example:/var/www/app ~/remote-mount -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3

-o reconnect asks SSHFS to re-establish after a dropped connection (with brief I/O pauses). ServerAliveInterval and ServerAliveCountMax send periodic SSH keepalives so middleboxes do not treat the session as idle.

Inspect active options:

findmnt -no OPTIONS ~/remote-mount

Sample output:

rw,nosuid,nodev,relatime,user_id=1001,group_id=1001

Keepalive values appear in the option list when you pass them at mount time. If a mount hangs after Wi-Fi drops, unmount and remount — see kill or disconnect a hung SSH session when the underlying SSH channel is stuck.

Persistent SSHFS mount

Should you use /etc/fstab?

/etc/fstab suits workstations or servers that must attach a remote tree at boot. SSHFS over fstab needs the network up, valid authentication without prompts, and realistic expectations — boot will block or fail if the remote host is down unless you combine _netdev with automount.

Interactive laptops often prefer a manual sshfs command or a user systemd unit instead of a global fstab line.

SSHFS /etc/fstab syntax

A typical entry:

deploy@vm2.lab.example:/var/www/app  /mnt/app  fuse.sshfs  _netdev,noauto,x-systemd.automount,IdentityFile=/home/dev/.ssh/id_ed25519,UserKnownHostsFile=/home/dev/.ssh/known_hosts,allow_other,default_permissions,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3  0  0

Field notes:

• _netdev — marks the filesystem as network-dependent so systemd orders it with network-related mounts. It does not by itself guarantee that the remote SSH server is already reachable.
• noauto — do not mount at boot without automount; pairs with x-systemd.automount on systemd systems.
• IdentityFile= — absolute path to a key the mount process can read; required for non-interactive boot when password login is disabled.
• UserKnownHostsFile= — optional but useful when you want the automount to use the same host-key store as user dev, not root's empty known_hosts.
• allow_other — only with user_allow_other in /etc/fuse.conf; pair with default_permissions when other local users need access.

Reload systemd after editing fstab on systems that use automount units:

sudo systemctl daemon-reload

Key-based authentication for persistent mounts

Password prompts block fstab and automount. Configure the same key-based login you set up for interactive mounts, then point fstab at that key with an absolute IdentityFile= path. If interactive login works but fstab fails with Host key verification failed, add UserKnownHostsFile= as in the example above or pre-populate the host key for the user context systemd actually uses.

Restrict the key if the mount runs from a shared system account.

systemd automount and network-online

Ensure network-online.target is active before SSHFS automount units run. On RHEL and Fedora, NetworkManager-wait-online.service is the usual prerequisite. Test with systemctl is-active network-online.target after boot before relying on a production fstab line.

Unmount an SSHFS filesystem

As a regular user, prefer fusermount3:

fusermount3 -u ~/remote-mount

The command exits silently when the mount is gone. Confirm nothing still lists the mount point:

mount | grep remote-mount

An empty result (no output) means the SSHFS filesystem is fully disconnected.

umount ~/remote-mount also works when you own the mount or run with sufficient privilege.

If unmount fails with target is busy, close editors and shells whose working directory is inside the mount, then retry. lsof +D ~/remote-mount lists processes still holding the path open.

SSHFS through an SSH jump host

When the remote host is only reachable through a bastion, reuse your SSH config ProxyJump stanza. SSHFS honors -F and OpenSSH config if the host alias is defined:

sshfs app@private-host:/home/app/data ~/remote-mount -F ~/.ssh/config

Or pass options inline:

sshfs deploy@10.10.10.20:/var/www/app ~/remote-mount -o ProxyJump=bastion@jump.lab.example

For multi-hop topology, bastion accounts, and scp -J patterns, see SSH through a jump host. Keep jump configuration in SSH config so both ssh and sshfs share the same host blocks.

SSHFS on Windows

The Linux sshfs -o ProxyJump=... example above does not apply directly to SSHFS-Win mapped drives. SSHFS-Win documents jump-host access through a separate Windows OpenSSH tunnel to the target (then map localhost!PORT).

Windows has no built-in SSHFS client. Install WinFsp (FUSE for Windows) and SSHFS-Win, then map a UNC path as a network drive.

Current SSHFS-Win requirements

• WinFsp — Windows File System Proxy
• SSHFS-Win — maps \\sshfs\… UNC paths to SSHFS

Both support current Windows 10 and Windows 11 releases.

Install with WinGet

Open PowerShell or Windows Terminal:

winget install --exact --id WinFsp.WinFsp

When WinFsp finishes, install SSHFS-Win:

winget install --exact --id SSHFS-Win.SSHFS-Win

The SSHFS-Win package may pull WinFsp as a dependency, but installing WinFsp explicitly first avoids partial installs.

Map a Linux directory as a Windows network drive

In File Explorer choose This PC → Map network drive, or use net use:

net use X: \\sshfs\deploy@vm2.lab.example

Enter the SSH password when prompted. Explorer shows X: as the remote home directory for deploy.

SSHFS-Win UNC prefixes

SSHFS-Win supports four path prefixes:

Examples:

\\sshfs\deploy@vm2.lab.example
\\sshfs.r\deploy@vm2.lab.example\var\www\app
\\sshfs.k\deploy@vm2.lab.example\projects
\\sshfs.kr\deploy@vm2.lab.example\etc\nginx

Password vs SSH-key authentication

Password mounts use \\sshfs\ or \\sshfs.r\. Key-based mounts use \\sshfs.k\ or \\sshfs.kr\ with a private key at %USERPROFILE%\.ssh\id_rsa (or a host alias in %USERPROFILE%\.ssh\config). SSHFS-Win supports keys without a passphrase; passphrase-protected keys are not supported.

Map a non-default SSH port

Insert !PORT before the path segment:

\\sshfs.r\deploy@vm2.lab.example!2222\var\www\app

Disconnect a mapped drive

In Explorer, right-click the drive under This PC and choose Disconnect, or run:

net use X: /delete

Common SSHFS errors

SSHFS performance and limitations

SSHFS is still useful for personal remote access and light admin work, but upstream development is limited. For shared production storage, databases, or workloads where many systems access the same files, use something designed for that job, such as NFS, Samba, or a dedicated storage service.

SSHFS encrypts every read and write. That is excellent for security over the internet but slower than NFS or Samba on a low-latency LAN.

Expect pain with:

• Many small files (metadata round-trips add up)
• Random I/O heavy databases on the mount (use local disk or proper network storage)
• Long offline periods (the mount stalls until SSH reconnects or you unmount)

Treat SSHFS as a convenient remote workspace, not a cluster filesystem. For multi-user production shares, plan NFS, Samba, or object storage instead.

Summary

SSHFS turns a remote directory into a local mount point by tunneling file operations through SSH/SFTP. You install fuse-sshfs on RHEL family systems from EPEL, run sshfs user@host:/path ~/mount as a normal user, and disconnect with fusermount3 -u.

By default, SSHFS enforces remote server permissions; add -o default_permissions when you also need local kernel checks, especially with allow_other. Persistent /etc/fstab mounts run as the system, not your login user, so use absolute IdentityFile= paths and plan host-key trust separately from interactive sshfs.

On Windows, WinFsp plus SSHFS-Win and WinGet provide current path prefixes — \\sshfs.r\ for absolute paths, \\sshfs.k\ and \\sshfs.kr\ for key-based login, and !PORT for non-default SSH ports. Jump hosts on Linux use ProxyJump; on Windows, tunnel with OpenSSH first, then map through localhost.

References

• SSHFS manual (man7.org)
• SSHFS project (GitHub)
• FUSE manual (man7.org)
• SSHFS-Win (GitHub)
• WinFsp (GitHub)