How to Mount Remote Directories with SSHFS on Arch Linux
Categories:
5 minute read
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
Option | Description |
---|---|
-o reconnect | Automatically reconnect if the connection drops |
-o allow_other | Allows users other than the mounter to access the mount (requires FUSE config) |
-o IdentityFile=~/.ssh/id_ed25519 | Specify a custom SSH key |
-o compression=yes | Enable SSH compression |
-o follow_symlinks | Follow 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:
- Edit the FUSE configuration file:
sudo nano /etc/fuse.conf
- 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
- Create a local mount point:
mkdir -p ~/remote_server
- Create a systemd user unit file:
nano ~/.config/systemd/user/remote_server.mount
- 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
- 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:
Tool | Description |
---|---|
rsync | Great for one-time or scheduled syncs |
scp | Simpler file copying over SSH |
NFS | Better for large-scale persistent mounts |
Syncthing | Peer-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:
man sshfs
man fusermount
- Arch Wiki on SSHFS
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.