How to Mount Remote Directories with SSHFS on Arch Linux

This article explains how to use SSHFS to mount remote directories on Arch Linux.

Remote file system access is a common need for system administrators, developers, and anyone working with servers or multiple systems. SSHFS (SSH Filesystem) is a user-space filesystem that allows you to mount a remote directory over SSH as if it were a local directory. On Arch Linux, SSHFS is an elegant, secure, and powerful tool for managing remote files without the overhead of traditional network filesystems like NFS or SMB.

In this article, we’ll walk through the process of setting up and using SSHFS on Arch Linux, step by step. By the end, you’ll be able to securely access remote directories, manipulate files as if they were on your local machine, and even automate mounts for convenience.


What Is SSHFS?

SSHFS is built on top of FUSE (Filesystem in Userspace) and SSH (Secure Shell). It allows non-privileged users to create and manage their own mounts, and because it uses SSH, data transfers are encrypted and secure.

Advantages of SSHFS:

  • Encryption: Data is transferred securely over SSH.
  • No Root Required: Users can mount remote directories without elevated privileges.
  • Ease of Use: If you have SSH access to a remote machine, you can use SSHFS.
  • Firewall-Friendly: Uses standard SSH port (usually 22), so it avoids complex firewall configurations.

Step 1: Installing SSHFS on Arch Linux

On Arch Linux, SSHFS is available via the official repositories and can be installed with pacman.

sudo pacman -S sshfs

This command installs both SSHFS and its FUSE dependency.

You can confirm the installation by checking the version:

sshfs -V

Step 2: Ensuring SSH Access to the Remote Server

Before mounting, you need to make sure you can connect to the remote system via SSH. For example:

ssh username@remote_host

If this connection works, you’re good to go. If not, you might need to:

  • Install and start the SSH daemon on the remote system: sudo systemctl start sshd
  • Ensure port 22 (or your custom SSH port) is open
  • Configure ~/.ssh/config for connection shortcuts (optional, but helpful)

Optional: Create an SSH Key Pair

If you want password-less access for mounts, create an SSH key pair and copy the public key to the remote server:

ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id username@remote_host

Step 3: Mounting a Remote Directory Using SSHFS

Now let’s perform a basic mount. Here’s the syntax:

sshfs username@remote_host:/remote/path /local/mountpoint

Example

mkdir -p ~/remote_server
sshfs user@192.168.1.10:/home/user/data ~/remote_server

You’ll be prompted for your SSH password (unless you set up key-based authentication). Once authenticated, the remote directory will appear locally.


Step 4: Working with the Mounted Filesystem

Once mounted, the remote files and directories will behave like local files. You can:

  • Open and edit files
  • Copy or move files
  • Use standard CLI tools like ls, cp, rsync, etc.

Example

ls ~/remote_server
nano ~/remote_server/notes.txt
cp ~/remote_server/image.png ~/Pictures/

Important: File operations might be slower than local filesystem access, especially over slow networks.


Step 5: Unmounting the Remote Directory

Once you’re done, unmount the SSHFS filesystem with the fusermount3 tool:

fusermount3 -u ~/remote_server

Or with the classic FUSE unmount (still supported):

fusermount -u ~/remote_server

If the mount becomes unresponsive (e.g., due to network failure), use the -z option to force unmount:

fusermount -uz ~/remote_server

Step 6: Advanced Options and Configuration

SSHFS provides many mount options to tweak performance, compatibility, and usability.

Commonly Used Options

OptionDescription
-o reconnectAutomatically reconnect if the connection drops
-o allow_otherAllows users other than the mounter to access the mount (requires FUSE config)
-o IdentityFile=~/.ssh/id_ed25519Specify a custom SSH key
-o compression=yesEnable SSH compression
-o follow_symlinksFollow symbolic links on the remote host

Example with Options

sshfs -o reconnect,compression=yes,IdentityFile=~/.ssh/id_ed25519 user@remote:/data ~/remote_data

Step 7: Allowing Non-Root Users to Use allow_other

By default, the allow_other option is disabled for security. To enable it:

  1. Edit the FUSE configuration file:
sudo nano /etc/fuse.conf
  1. Uncomment or add the line:
user_allow_other

Now users can use the -o allow_other mount option, allowing other users to access the mounted directory.


Step 8: Automating Mounts (via fstab or systemd)

You can automate SSHFS mounts on boot or login.

Option 1: Using fstab

FUSE-based filesystems can be added to /etc/fstab, but it’s a bit tricky. First, install sshfs-mounter if you want to use fstab in a cleaner way. Otherwise, you can use autofs or systemd.

⚠️ Direct fstab usage is not recommended with SSHFS due to dependency on network state.

Option 2: Using systemd Mount Units

Systemd is more robust for this use case.

Step-by-Step

  1. Create a local mount point:
mkdir -p ~/remote_server
  1. Create a systemd user unit file:
nano ~/.config/systemd/user/remote_server.mount
  1. Add the following content:
[Unit]
Description=Mount remote server via SSHFS
After=network.target

[Mount]
What=user@remote_host:/home/user/data
Where=%h/remote_server
Type=fuse.sshfs
Options=IdentityFile=%h/.ssh/id_ed25519,allow_other,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3

[Install]
WantedBy=default.target
  1. Enable and start the mount:
systemctl --user daemon-reexec
systemctl --user enable --now remote_server.mount

Troubleshooting Tips

Mount Fails With Permission Denied

  • Check your SSH credentials and permissions
  • Try verbose output: sshfs -o sshfs_debug,loglevel=debug user@host:/path /mountpoint

Slow Performance

  • Enable compression: -o compression=yes
  • Use reconnect, ServerAliveInterval=15 to keep connections alive

Files Not Accessible by Other Users

  • Use -o allow_other and enable it in /etc/fuse.conf

Unresponsive Mount

  • Use fusermount -uz to force unmount

Security Considerations

  • Always use SSH key authentication for better security
  • Avoid allow_other unless absolutely necessary
  • Consider using dedicated SSH users with limited permissions

Alternatives to SSHFS

While SSHFS is great for many use-cases, there are scenarios where you may consider alternatives:

ToolDescription
rsyncGreat for one-time or scheduled syncs
scpSimpler file copying over SSH
NFSBetter for large-scale persistent mounts
SyncthingPeer-to-peer continuous file synchronization

Conclusion

SSHFS is a powerful and flexible way to mount remote directories securely over SSH on Arch Linux. With just a few commands, you can interact with remote files as if they were on your local system. Whether you’re a developer managing codebases on a server, a sysadmin syncing config files, or just someone needing remote access, SSHFS can be a solid and efficient solution.

By combining SSHFS with systemd or scripting, you can automate and customize the experience further, bringing you closer to a seamless, connected Linux environment.


Further Reading: