i've always wanted to use sshfs but never id. I used to set it up and get hung mounts all the time (typically from transient failures) so it was really annoying to use.
For the most part scp or rsync gets the job done for me, which is strange considering a real file system should be way more useful.
What are peoples use cases for sshfs and is there alternative workflows?
I used to use SSHFS to have access to remote files in the OS file browser. But I moved onto WebDAV (via lighttpd) because I like managing the auth outside of PAM and also OS file browsers (including Win/Mac) have good support for it
You mount the remote file system as a volume and traverse it as part of the local file system. Super convenient for comparing contents of a local folder to a remote in the command line, using local tools on the remote FS, batch copying both ways, all that good stuff.
The hung file systems can be a buttpain, enough that I wrote a Bash script that calls `mount` to get the hung FS IDs and `umount` them with the results. After that easy peasy.
I wish sshfs worked for me and hope it gets attention for someone knowledgeable. The primary issue I had was when resuming my laptop is that it would freeze the system waiting to reconnect.
A (better?) alternative to sshfs is Syncthing, which works somewhat like a self-hosted Dropbox; it automatically synchronizes a subtree between computers. I've used it for years, with no problems at all. Maybe it won't handle concurrent edits to the same file well, but that's not something I do.
Meanwhile, the hung mount problem in sshfs can be more or less fixed by giving it the right mount options; perhaps something along the lines of https://github.com/Baughn/machine-config/blob/041e2151dffd8e... will be helpful. Unfortunately these aren't the default.
I use both, and while SyncThing is beautiful, it doesn't cover the use cases of sshfs, where you don't even need to install anything. I'm not going to install SyncThing on a server when I just want to patch a python file or copy some log archives.
> NFS is also more tolerant to breaking and resuming the TCP connection; this is fatal to sshfs.
Except when...
- The kernel driver crashes, resulting in unkillable processes and orphaned, mounted files that, if accessed, result in those very processes also being unresponsive and unkillable. The solution? Reboot your machine.
- There is packet loss on the network which can greatly compromise the stability of the NFS client. The solution? Don't have packet loss.
- The RPC daemon somehow goes out of lockstep with the kernel, causing hanging and crashes. The solution? Don't let the RPC daemon get out of lockstep --- somehow.
- You foolishly misconfigure the mount options, causing NFS to hang or time out if there's even a minor issue. Woe betide you if you muck up the timeout, retrans, etc. flags. The solution? Know the arcana and all your needs ahead of time, or be prepared for days of debugging.
NFS sure is convenient and useful, but it's also terrible and antiquated.
You still get stuck processes on D state which can be locking other resources. Maybe the kernel could use an alternate kill api for this, as being able to kill a D state process normally is problematic in many apps and should never be possible 'accidentally'.
You might be correct about NFSv2. However, there was significant exchange between NFSv4 and SMB versions 2 and 3. Neither is perfect, but they have practical uses.
As far as packet loss is concerned, TCP is more robust, and is the default on Linux starting with NFSv3.
When using NFSv4, rpc.portmap is not necessary, so it cannot "go out of lockstep with the kernel" because it is not running.
As far as "foolish misconfiguration," solving a problem between the keyboard and the chair is not in the current features. Maybe the next release.
p.s. NFS over UDP can cause silent corruption over gigabit ethernet - see "man 5 nfs" for details (search for "Using NFS over UDP on high-speed links"). This is one reason why TCP is the default.
> As far as packet loss is concerned, TCP is more robust
Somehow I always felt using UDP as a basis for a file access protocol had more potential. You shouldn't care about packets arriving in the correct order, only that the (likely, concurrent) read/write operations are completed. If I request a 1MB read, I don't need it to come in 1500b sequential chunks, I can wait for the read call to return me a full 1MB buffer.
It could also enable better throughput on high-latency (but otherwise speedy) links, like moving files between datacenters across the pond.
Sun RPC / XDR doesn't have consistency checking like that built in. So you definitely can't bolt this onto older NFS protocols, but they could have for NFS v4 (and didn't).
oof, the situation can be even rougher than that. At 9000 MTU on IPv4, you have a 'safe' NFS-over-UDP data rate of roughly 18 megabytes/second. Plenty of room at 1GbE, but not enough for 10GbE or greater. I suppose using krb5i/p mounts or some other integrity-providing GSSAPI/crypto implementation could help with this, but thats a different pile of worms. You would also get issues with not-strictly-necessary retransmits impacting your effective bandwidth.
Thankfully, IPV6 can help mitigate this problem by extending the fragment id length from 16 to 32 bits. This gets you up to roughly 1.18 trillion bytes of 'safe' NFS traffic/second. There's plenty of reasons why IPv6 adoption is still fragmentary, but if you're running a high throughput network, this is certainly a motivator to move at least part of it to IPv6.
If you just want light-weight mirroring I recommend lsyncd. For example work if you want to work on code locally and have it mirrored on a remote host. It's more reliable because it just mirrors files rather than mounting file systems or block devices.
Lsyncd uses a filesystem event interface (inotify or fsevents) to watch for changes to local files and directories. Lsyncd collates these events for several seconds and then spawns one or more processes to synchronize the changes to a remote filesystem. The default synchronization method is rsync. Thus, Lsyncd is a light-weight live mirror solution. Lsyncd is comparatively easy to install and does not require new filesystems or block devices. Lysncd does not hamper local filesystem performance.
I use it for browsing/copying/editing files on remote servers. Once you've got ssh passwordless authentication set up with the server, then it's easy to add in a systemd automount for it in your /etc/fstab. I like the authentication and encryption compared to NFS though it is slower, so more for accessing specific files.
The use case for sshfs that you can quickly get access to all the files accessible to you in some machine without needing to be root either local or remotely.
I have had very stable networks for over 10 years in most of my work, so I don't think I haver ever suffered from hangups.
It does not fail gracefully when you read or write bigger files than your connection can decently handle. But I don't know which system would behave better under such conditions.
I use it for temporary connections for file management since a few years ago, and it always has been very stable. Never left it connected for more than 24 hours, though.
I have sshfs connections open for weeks at a time (except when network interrupts). Works awesome. Just remount and keeps going. I don't have open handles to files there for weeks, just mounts - then open file, edit, close and it again, 100s of times a day. I love sshfs.
NFSv4 (not NFSv3 or earlier) is the most efficient network FS protocol (beats SMB in all my testing), but I frequently access work machines over VPN and can't use NFS because of many reasons in which case SSHFS is very convenient.
ADD: Some might not be aware that NFSv4 is a MAJOR change from the earlier versions and has many radical changes, including: time-expiring lease-based coherency, bundled requests (do much more in each NFSv4 network packet), locking built-in to the protocol. Don't don't base your assumptions of NFS on NFSv3.
Some on this thread suggests Syncthing, scp, rsync, etc, but this not really the same.
When the file system is enormous and you need to commit your changes back - it would be impractical to sync everything (many TiB of data) and a pain to try to remember which things changed.
The situation on macOS has been a bit sad; Mac Homebrew refuse to install sshfs as Mac FUSE is not open source (because the author got fed up with commercial abuse of his work).
I sympathize, but that still leaves me in limbo.
Ideally, Apple should just include a FUSE like facility in macOS as it's so useful.
It already works very well (seat-of-the-pants feels comparable to or better than my sshfs recollection); I managed to build Rust projects over it (with target on local FS).
Googling around suggest bumping the TCP transfer window but I don't see that as option in macOS's man mount_nfs, or any other useful option for that matter.
Requiring six months of reasonable activity before handing over the reins is a neat and novel way to ensure the new maintainer doesn't have crypto mining bot nets in mind :)
Yeah, I saw that as well, and I was immediately struck by how reasonable and responsible that seemed.
Not ideal if you're a Linux distribution trying to figure out which fork to pick up, but ideal if you're an upstream maintainer trying to find someone responsible.
I hope that works out, more often than not, if there's no official new maintainer, distros keep doing what they do best: not talk to each other and over the years start to collect different patches for the same issues that might pop up eventually. :-(
However, I wondered about how much activity there still is on this. Isn't this considered mostly finished at some point?
I can understand that there might be some more development on libfuse but that is independent anyway. As far as I remember, the MacOS state of libfuse was somewhat unclear?
Similar results for me too, also on a Mac. I've had it basically work a few times in trial runs, and it's pretty convenient (the concept is excellent), but it has been horrifically slow and flaky basically every time (e.g. takes upwards of a minute to list a directory with like 100 items in it, sometimes just silently gives up and doesn't list anything, etc). I'm not really sure why.
Has been working fine for me for years on Linux. I wish it had some convenience features like automatic reconnect, but other than that it's fine. Just don't expect any performance miracles compared to NFS or cifs.
It has automatic reconnect: "-o reconnect". You'll need to use key-based authentication with an SSH agent, since it won't be able to prompt you for the password while running in the background.
That might mean it needs better surfacing in the docs, if you have the time it may be worth having a quick look at the docs - it's possible a PR could help aid discoverability.
That seems impossible until a new maintainer is found. The current issue tracker however contains an issue that suggests making automatic reconnects the default. I hope I remember this when eventually (hopefully) this project is picked up by someone else.
This project is no longer maintained or developed. Github issue tracking and pull requests have therefore been disabled. The mailing list (see below) is still available for use.
If you would like to take over this project, you are welcome to do so. Please fork it and develop the fork for a while. Once there has been 6 months of reasonable activity, please contact Nikolaus@rath.org and I'll be happy to give you ownership of this repository or replace with a pointer to the fork.
The article link was originally to a commit diff of the `AUTHORS` file, and hence my comment offered some information that was missing. Later on the link was flipped to something more useful, and my comment became less useful.
This has been coming for a number of years now, but the maintainer was just active enough that nobody seemed to care about their wishes to hand over the software. Hopefully this will lead to someone actually taking over now.
Used sshfs a lot at a previous workplace that had us do all development on a remote (very out of date) Debian box as there was no way of running the codebase locally. Don't even ask.
Great tool though, Sublime Text worked great alongside it and allowed me to be somewhat productive.
Thank you. I'm using sshfs every day to remotely access my computer and servers from my laptop. Although it's slow, it works. I'm considering to switch to NFS instead.
All machines (~ 10 highly diverse) in my home lab mounts my $HOME over NFSv4 from a TrueNAS server. Works very well. I can saturate 10 GbE easily (and have 100 GbE point-to-point to the main compute server). SSHFS is just crazy slow in comparison, has tremendous CPU load, doesn't have reliable coherency semantics (well it can, but then it's even slower). However, creating an ad-hoc sshfs mount is trivial unlike with NFSv4. Also, SSHFS is of course encryped on the wire unlike NFSv4.
TL;DR: both have valid use cases, but for a home file server I'd definitely choose NFSv4 for Unix (*BSD, Linux, macOS) hosts (know nothing about Windows).
TL;DR: If your shares are on the Windows machine just use SMB, *nix SMB clients work fine. NFS Server works on Windows, but depending on the client it works fine or you would preferred it didn't work at all.
Shameless plug: I used sshfs at work for about 3 years, and I made a fork for myself, featuring a persistent cache layer on metadata caches... I really appreciate the project, but I am not confident enough to maintain it.
Not at all, SFTP (SSH File Transfer Protocol, an SSH2 protocol extension) doesn't have anything to with FTP (outside of the name), and only require an ssh server that supports it - OpenSSH does for example. You might be confusing it with FTPS (FTP Secure, or FTP over SSL/TLS).
(To add to the confusion, there are some FTP servers that also support SFTP - so they act as SSH servers)
It's reasonable to be confused. SFTP is both Simple File Transfer Protocol, and later Secure File Transfer Protocol, and also there is FTPS, which would be FTP over SSL.
Is there a way to mount only a particular remote directory? If I specify a path after the host, it always mounts the whole remote machine's filesystem which is almost never what I want.
Not SSHFS specific but is there a tool to crawl all these forks and find which ones are at least not behind? Or which are ahead? Something easy to browse?
I'm really surprised Github doesn't leverage their data for better discovery. Instead you get forks that are second-class citizens and should never be used for active development. For example, they don't get watched by default and their code is not searchable.
I hope they can find a maintainer. sshfs is such an awesome tool, I can set up network file shares super easily when I don't need some crazy robust storage solution
I found it faster with sshfs when the repo is far away. On the local network I don't see a difference. (I checked at last a couple of years ago, things might have changed)
100 comments
[ 4.4 ms ] story [ 177 ms ] threadFor the most part scp or rsync gets the job done for me, which is strange considering a real file system should be way more useful.
What are peoples use cases for sshfs and is there alternative workflows?
The hung file systems can be a buttpain, enough that I wrote a Bash script that calls `mount` to get the hung FS IDs and `umount` them with the results. After that easy peasy.
Meanwhile, the hung mount problem in sshfs can be more or less fixed by giving it the right mount options; perhaps something along the lines of https://github.com/Baughn/machine-config/blob/041e2151dffd8e... will be helpful. Unfortunately these aren't the default.
1. Open the terminal and mount sshfs.
2. Open Dolphin and Ctrl+Click 10 files among tens.
3. Cut, paste locally.
4. Unmount sshfs.
Very different tools for very different use cases.
NFS is also more tolerant to breaking and resuming the TCP connection; this is fatal to sshfs.
Encrypting NFS is a bit of a Rube-Goldberg machine, which I covered here:
https://www.linuxjournal.com/content/encrypting-nfsv4-stunne...
Except when...
- The kernel driver crashes, resulting in unkillable processes and orphaned, mounted files that, if accessed, result in those very processes also being unresponsive and unkillable. The solution? Reboot your machine.
- There is packet loss on the network which can greatly compromise the stability of the NFS client. The solution? Don't have packet loss.
- The RPC daemon somehow goes out of lockstep with the kernel, causing hanging and crashes. The solution? Don't let the RPC daemon get out of lockstep --- somehow.
- You foolishly misconfigure the mount options, causing NFS to hang or time out if there's even a minor issue. Woe betide you if you muck up the timeout, retrans, etc. flags. The solution? Know the arcana and all your needs ahead of time, or be prepared for days of debugging.
NFS sure is convenient and useful, but it's also terrible and antiquated.
The frustrating thing is, a shocking number of people either don't realize it or simply can't.
I've lost weeks of my life to D-state. All TCP, all new protocol revisions. Datacenter wide deployment with redundant ports, paths, everything.
As far as packet loss is concerned, TCP is more robust, and is the default on Linux starting with NFSv3.
When using NFSv4, rpc.portmap is not necessary, so it cannot "go out of lockstep with the kernel" because it is not running.
As far as "foolish misconfiguration," solving a problem between the keyboard and the chair is not in the current features. Maybe the next release.
p.s. NFS over UDP can cause silent corruption over gigabit ethernet - see "man 5 nfs" for details (search for "Using NFS over UDP on high-speed links"). This is one reason why TCP is the default.
Somehow I always felt using UDP as a basis for a file access protocol had more potential. You shouldn't care about packets arriving in the correct order, only that the (likely, concurrent) read/write operations are completed. If I request a 1MB read, I don't need it to come in 1500b sequential chunks, I can wait for the read call to return me a full 1MB buffer.
It could also enable better throughput on high-latency (but otherwise speedy) links, like moving files between datacenters across the pond.
Thankfully, IPV6 can help mitigate this problem by extending the fragment id length from 16 to 32 bits. This gets you up to roughly 1.18 trillion bytes of 'safe' NFS traffic/second. There's plenty of reasons why IPv6 adoption is still fragmentary, but if you're running a high throughput network, this is certainly a motivator to move at least part of it to IPv6.
-o reconnect -o ServerAliveInterval=5
Example /etc/fstab line:
root@remote:/ /mnt/sshfs/remote fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,reconnect,transform_symlinks,identityfile=/root/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=1000
ServerAliveCountMax=5,ServerAliveInterval=2,ConnectTimeout=2
to avoid it hanging for too long if the network goes away, works like a charm.
I have had very stable networks for over 10 years in most of my work, so I don't think I haver ever suffered from hangups.
It does not fail gracefully when you read or write bigger files than your connection can decently handle. But I don't know which system would behave better under such conditions.
In the past, I also used it as an alternative to Samba or NFS.
On my GNOME system GSConnect uses GIO. I don't have a KDE system to look at right now but I would eat my hat if they're using SSHFS instead of KIO.
Nowadays I mainly use docker-machine (can't say I recommend it, but it does the job)
ADD: Some might not be aware that NFSv4 is a MAJOR change from the earlier versions and has many radical changes, including: time-expiring lease-based coherency, bundled requests (do much more in each NFSv4 network packet), locking built-in to the protocol. Don't don't base your assumptions of NFS on NFSv3.
Some on this thread suggests Syncthing, scp, rsync, etc, but this not really the same. When the file system is enormous and you need to commit your changes back - it would be impractical to sync everything (many TiB of data) and a pain to try to remember which things changed.
The situation on macOS has been a bit sad; Mac Homebrew refuse to install sshfs as Mac FUSE is not open source (because the author got fed up with commercial abuse of his work). I sympathize, but that still leaves me in limbo. Ideally, Apple should just include a FUSE like facility in macOS as it's so useful.
It already works very well (seat-of-the-pants feels comparable to or better than my sshfs recollection); I managed to build Rust projects over it (with target on local FS).
Googling around suggest bumping the TCP transfer window but I don't see that as option in macOS's man mount_nfs, or any other useful option for that matter.
Not ideal if you're a Linux distribution trying to figure out which fork to pick up, but ideal if you're an upstream maintainer trying to find someone responsible.
However, I wondered about how much activity there still is on this. Isn't this considered mostly finished at some point?
I can understand that there might be some more development on libfuse but that is independent anyway. As far as I remember, the MacOS state of libfuse was somewhat unclear?
I consider it buggy and unusable. At least on Mac. Definitely not finished.
I gave up on it and switched to using VSCode's remote development extension.
A really good example of File Provider API is the Secure ShellFish app on iOS / iPadOS - https://secureshellfish.app .
This project is no longer maintained or developed. Github issue tracking and pull requests have therefore been disabled. The mailing list (see below) is still available for use.
If you would like to take over this project, you are welcome to do so. Please fork it and develop the fork for a while. Once there has been 6 months of reasonable activity, please contact Nikolaus@rath.org and I'll be happy to give you ownership of this repository or replace with a pointer to the fork.
MacSSHFS. Mac Version of Sshfs
https://news.ycombinator.com/item?id=31502068
Submitted by tormodw | 26 days ago | 1 point
What did I miss?
Great tool though, Sublime Text worked great alongside it and allowed me to be somewhat productive.
Do you did it for her? https://i.pinimg.com/736x/58/12/f6/5812f6951b3016edbb5b19697...
TL;DR: both have valid use cases, but for a home file server I'd definitely choose NFSv4 for Unix (*BSD, Linux, macOS) hosts (know nothing about Windows).
TL;DR: If your shares are on the Windows machine just use SMB, *nix SMB clients work fine. NFS Server works on Windows, but depending on the client it works fine or you would preferred it didn't work at all.
https://github.com/andy0130tw/sshfs
Switched off of sshfs after that.
Far better than nothing though, and is integrated in many GUI tools that use GTK.
Wow, thanks!
(To add to the confusion, there are some FTP servers that also support SFTP - so they act as SSH servers)
You're thinking of FTPS which is FTP+TLS.
>meson
I hate this kind of development.