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 :)
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?
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.
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.
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?
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.
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.
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.
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 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.
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 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
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.
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.
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).
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.
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?
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.
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 [email protected] and I'll be happy to give you ownership of this repository or replace with a pointer to the fork.
[+] [-] djha-skin|3 years ago|reply
[+] [-] albertzeyer|3 years ago|reply
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?
[+] [-] JoshTriplett|3 years ago|reply
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.
[+] [-] qbane|3 years ago|reply
https://github.com/andy0130tw/sshfs
[+] [-] goombacloud|3 years ago|reply
[+] [-] sigmonsays|3 years ago|reply
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?
[+] [-] dj_gitmo|3 years ago|reply
[+] [-] FullyFunctional|3 years ago|reply
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.
[+] [-] chasil|3 years ago|reply
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...
[+] [-] usr1106|3 years ago|reply
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.
[+] [-] Filligree|3 years ago|reply
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.
[+] [-] NackerHughes|3 years ago|reply
-o reconnect -o ServerAliveInterval=5
[+] [-] ndsipa_pomu|3 years ago|reply
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
[+] [-] gralx|3 years ago|reply
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.
[+] [-] woogley|3 years ago|reply
[+] [-] bigpeopleareold|3 years ago|reply
[+] [-] ASalazarMX|3 years ago|reply
[+] [-] jokethrowaway|3 years ago|reply
Nowadays I mainly use docker-machine (can't say I recommend it, but it does the job)
[+] [-] albertzeyer|3 years ago|reply
In the past, I also used it as an alternative to Samba or NFS.
[+] [-] jessikat|3 years ago|reply
[+] [-] Perz1val|3 years ago|reply
[+] [-] Jach|3 years ago|reply
[+] [-] mistrial9|3 years ago|reply
[+] [-] gourneau|3 years ago|reply
[+] [-] murph|3 years ago|reply
Switched off of sshfs after that.
[+] [-] dang|3 years ago|reply
[+] [-] kzrdude|3 years ago|reply
[+] [-] yuuta|3 years ago|reply
[+] [-] bityard|3 years ago|reply
[+] [-] FullyFunctional|3 years ago|reply
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).
[+] [-] benbristow|3 years ago|reply
Great tool though, Sublime Text worked great alongside it and allowed me to be somewhat productive.
[+] [-] justsomehnguy|3 years ago|reply
Do you did it for her? https://i.pinimg.com/736x/58/12/f6/5812f6951b3016edbb5b19697...
[+] [-] turminal|3 years ago|reply
[+] [-] feet|3 years ago|reply
[+] [-] djbusby|3 years ago|reply
[+] [-] DavideNL|3 years ago|reply
[+] [-] akvadrako|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] WalterGR|3 years ago|reply
MacSSHFS. Mac Version of Sshfs
https://news.ycombinator.com/item?id=31502068
Submitted by tormodw | 26 days ago | 1 point
[+] [-] kzrdude|3 years ago|reply
[+] [-] benbristow|3 years ago|reply
[+] [-] viraptor|3 years ago|reply
[+] [-] npteljes|3 years ago|reply
[+] [-] fritigern|3 years ago|reply
[+] [-] arthurcolle|3 years ago|reply
[+] [-] astine|3 years ago|reply
[+] [-] mikepurvis|3 years ago|reply
[+] [-] midislack|3 years ago|reply
>meson
I hate this kind of development.
[+] [-] wazzaps|3 years ago|reply
[+] [-] angrygoat|3 years ago|reply
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 [email protected] and I'll be happy to give you ownership of this repository or replace with a pointer to the fork.