Mounting a Remote Filesystem with sshfs

by Jeremy Jones

I recently had need (actually, more of a want thing) to mount a remote server from my laptop. The server in question has NFS running, so I figured it would be easy to mount my home directory on the server to some location on my laptop. It was simple. But when I mount it, all the files in my home directory were owned by some user which does not exist on my laptop. I thought I had tackled this problem in the past and found a way to map IDs from one system to another system when you NFS mount. Googling around turned up "idmap", but I didn't find clear documentation on how to configure it to do what I wanted, particularly when I only own the client side.

Then a friend recommended I look at sshfs. (Thanks, Michael!) Basically, if you have SSH access to a server, you can mount a directory on that server and access it locally. All I had to do on my Ubuntu laptop was to install the "sshfs" package. sshfs uses FUSE, so it installs all the FUSE dependencies it needs.

The command I use to mount the remote server looks like this:

sudo sshfs {{user id}}@{{server hostname}}:{{desired remote share}} {{desired local mount point}} -o idmap=user -o allow_other -o uid={{local user id}} -o gid={{local group id}}

This will not only mount the remote share, but will resolve any user id mismatches with the ones you specify with the uid and gid options. The performance is pretty good when both machines have a good network connection between them. But when I mount a directory on my server at home (meaning over a DSL connection), it lags noticeably. I think this is a great option for mounting a remote system when all you have is SSH access to it. It even works well when you don't feel like fighting through user id/host mismatches. If anyone has a client-side only fix for the NFS user id mismatch, I'd love to read about it!


2006-11-20 08:33:38
Has anyone had any luck with this with Mac OS X?
2006-11-20 09:09:59
sshfs is great, and I'd love to use it a lot more, but the one thing I've discovered the hard way is that it doesn't allow hardlinks. I haven't cared enough to look at whether this is a limitation of sshfs, the underlying libraries, or just the fact that it's all going over ssh, but it ends up being a killer for me, as one of the things I'd most like to mount is ~/.jpilot/, and JPilot uses hardlinks extensively when you hotsync a Palm PDA and files haven't changed from the last sync time...
Dick Davies
2006-11-20 10:08:16
ubuntu (well, nautilus) already does this out of the box:

on your desktop , choose 'ctrl-l'

then enter 'ssh://user@host' in the dialogue box, and gnome-vfs mounts the server as a drive.

Matthew Sporleder
2006-11-20 10:10:24
NFS relies on assertion for identity of remote hosts, so allowing a client to map a uid isn't appropriate without another layer of authorization and/or authentication. (in your case, provided by ssh. Andrew File System uses kerberos for this..)

FUSE are more filesystem-look-alikes than real filesystems, which is why this works. Any sort of uid mapping would have to be done on the server side if you relied on taditional nfs assertion methods, and would be host-specific.

This method would probably be faster than a FUSE system because there's less translation in-between layers.

FUSE is linux-specific, so it's not going to work on osx. NetBSD recently added Pass-to-Userspace Framework FileSystem (puffs), and I don't know about freebsd, which would be where os x would get this sort of functionality.

Jeremy Jones
2006-11-20 10:20:29

AFAIK, connecting to an SSH server from Nautilus doesn't "mount" it exactly. It provides a Nautilus interface to the files on that server, but I don't think it lets you bring up an xterm and navigate it. I just did it and don't see the connection under "df -k".

Jeremy Jones
2006-11-20 10:28:34

Thanks for the input regarding NFS, uids, and what-not. I figured I may not be able to mount and map an NFS volume properly for the reasons you lay out.

2006-11-20 17:31:09
This works on FreeBSD. There is a port for it, and other FUSE filesystems.

2006-11-20 17:34:54
KDE has this feature also (similar to GNOME VFS), but it isn't the same; it doesn't mount anything, it just connects when used. It's even more fake than FUSE, though it's convenient.

Another alternative to NFS is SFS, which is sort of in between SSHFS and NFS.

Tracy R Reed
2006-11-20 20:05:19
sshfs is indeed cool. I use it to be able to use my emacs session on my local system to be able to edit files on remote systems. I was a little disappointed to see that processes that are not beneath my authenticated ssh-agent process were able to access the sshfs mounted system as well. A good reason not to keep things mounted all the time when they do not need to be mounted or a compromise of your local system could turn into a compromise of every system you have mounted.
Jeremy Jones
2006-11-21 04:48:35

Excellent security warning! Fortunately, I'm mounting from my laptop, so I can't leave mounts open indefinitely. And even if I could, if someone compromises my laptop, I'm hosed anyway. But this is an excellent observation. Well worth keeping in mind.

2006-11-21 06:21:50
The guys over at have some nice tutorials on sshfs for Linux and FreeBSD 6.x at

2006-11-21 14:59:13
Another alternative is SFS, the "Self-certifying File System". It's somewhere in between NFS and SSHFS.
Scott Walsh
2006-11-27 05:25:13
As someone mentioned, KDE has this functionality, it's built into the kio_slave package(unsure if sshfs in involved, as it runs a perl process on the remote server to set up parts of the session). You don't get access to the CLI with this, but you have the correct permissions. The format for connecting is fish://username@host. I find this very handy for web dev when using Kate.

2007-01-15 15:10:47
Support for SSHFS on Mac OS X is now available (as of January 11, 2007) via MacFUSE:

More info:

Install instructions (unofficial, but the one I preferred):