Sshfs Is Orphaned | Hacker News Reader

Sshfs Is Orphaned

github.com

191 pointshakunin98 comments

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. :-(

Yes, definitely reasonable.

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?

> Isn't this considered mostly finished at some point?

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.

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.

Hey that's awesome thaks! Seems to have been there for decades. How could I miss this?

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.

Weird, I've been using it for like 10 years maybe? No issue on Linux and OSX, aside from the occasional disconnect, which is actually my ISP's fault.

There’s no need to use libfuse on macOS. You can use https://mountainduck.io/ instead or write a FileProvider for Finder (macOS) / Files (iOS / iPadOS) https://developer.apple.com/videos/play/wwdc2021/10182/

A really good example of File Provider API is the Secure ShellFish app on iOS / iPadOS - https://secureshellfish.app .

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.

https://github.com/andy0130tw/sshfs

Well, there is "gio mount sftp://USER@XYZ" after which you can access the files under "/run/user/1000/gvfs/sftp:host=XYZ,user=USER/SOME_PATH/…"

In my latest experience, this handles disconnects due to laptop sleep pretty roughly.

Far better than nothing though, and is integrated in many GUI tools that use GTK.

Wait!!!, I always thought SFTP was just FTP server with SSL.

Wow, thanks!

SFTP is totally different from FTP (and FTPS) -- it's an ssh protocol extension, and is commonly enabled and served by your sshd.

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)

Yeah, SFTP is a silly name because it has no relation to FTP.

You're thinking of FTPS which is FTP+TLS.

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.

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?

satisifed user of rclone here

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.

Additionally, there's a wide semantic gap between "make the remote tree appear local" and "make a local copy of the entire remote tree".

Why wouldn’t you just.. scp?

I don't know. How faster can scp make this workflow?

1. Open the terminal and mount sshfs.

2. Open Dolphin and Ctrl+Click 10 files among tens.

3. Cut, paste locally.

4. Unmount sshfs.

SSHFS and Syncthing are so different from each other, almost the only thing they have in common is that they talk on a network.

Very different tools for very different use cases.

True. I was addressing both of the GP's use cases.

NFS is more flexible in dynamic mapping of new users; sshfs will take a mapfile at startup but it cannot be changed unless the service is restarted.

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...

> 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.

Yea, NFS processes can get into an uninterruptible and unkillable sleep state where then only way to clean up is to reboot.

So glad/validated to see this thread. I always inevitably end up ranting about this when NFS comes up.

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.

Instead of rebooting, try a lazy unmount on Linux.

  umount -l /stuck/directory

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'.

Soft mount no?

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.

https://lsyncd.github.io/lsyncd/

I had the same problem when I first started using sshfs. I found that adding the following to my sshfs invocation did the trick:

-o reconnect -o ServerAliveInterval=5

Can put those in the ssh user config file

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.

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

I usually add sth. like

ServerAliveCountMax=5,ServerAliveInterval=2,ConnectTimeout=2

to avoid it hanging for too long if the network goes away, works like a charm.

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.

We used it for PyCharm to overcome its limitation with remote editing support.

In the past, I also used it as an alternative to Samba or NFS.

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.

I use it with my NAS.

SSHFS is used by KDE Connect to see files on the other device

I don't think that's true.

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.

I used it a lot when I was running a Linux desktop and deploying random things on vps.

Nowadays I mainly use docker-machine (can't say I recommend it, but it does the job)

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.

Oh wow, inspired by the stunnel above I just successfully used

    $ ssh -Nf -L2049:my-nas:2049 my-gw
    $ sudo mount -t nfs -o vers=4 localhost:/mnt/somewhere/username /home

to mount my home (5,000 miles from where I currently sit) over ssh (over zerotier) without needing SSHFS. I'm going to use this going forward.

Beware, you may need to do a significant amount of sysctl tuning/mount option tweaking to get fast NFS performance over high latency networks.

Thanks, got pointers?

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.

I use winfsp/sshfs-win to remotely access my Haiku system, which works extremely well.

rclone will also mount sftp as a drive https://rclone.org/sftp/

I've found rclone 2-3x faster for large file transfers, personally.

Switched off of sshfs after that.

We changed the URL from https://github.com/libfuse/sshfs/commit/c91eb9a9a992f1a36c49..., which is hard to follow, to the project page which seems to say the same thing.

Nice project hand-over policy actually, that sounds very reasonable.

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).

> 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.

NFS doesn't do great on high-latency connections, but it really shines on (and was designed for) a high-speed LAN.

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.

> Don't even ask.

Do you did it for her? https://i.pinimg.com/736x/58/12/f6/5812f6951b3016edbb5b19697...

'previous workplace' says otherwise, I made an escape ;)

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.

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

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?

To find active forks: https://techgaun.github.io/active-forks/index.html

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.

There's this fork. I don't know how it differs from the original.

MacSSHFS. Mac Version of Sshfs

https://news.ycombinator.com/item?id=31502068

Submitted by tormodw | 26 days ago | 1 point

Maybe that it only works on Mac?

"Works" is a bit optimistic.

Looking at the commit history, I only see documentation changes.

What did I miss?

I think it's a port, because they couldn't use the FUSE backend (Linux specific)

That's a shame. I'm running sshfs + borg for backups to rsync right now. Sounds like I'll have to figure out a workaround for it soon.

What does sshfs do in this setup? I'm asking because Borg can use SSH directly.

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)

I love KDE connect and it uses sshfs in the background. I hope it gets a new owner soon. Hmmm, maybe I should volunteer...

Is this some kind of networked filesystem? Not particularly familiar with sshfs

It's a fuse mount of a remote filesystem over the ssh protocol.

Sort of. Sshfs is a FUSE file system that locally mounts a directory on a remote server using an SSH connection as the only necessary transport.

>ninja

>meson

I hate this kind of development.

Why?

From README.rst:

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.

Why are you copy/pasting the first sentences of the linked page here without any added content?

Excerpt.

Why not? It’s for emphasis.

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.

Reply on news.ycombinator.com