[HN Gopher] Sshfs Is Orphaned
___________________________________________________________________
Sshfs Is Orphaned
Author : hakunin
Score : 157 points
Date : 2022-06-20 16:45 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fritigern wrote:
| I love KDE connect and it uses sshfs in the background. I hope it
| gets a new owner soon. Hmmm, maybe I should volunteer...
| turminal wrote:
| 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.
| benbristow wrote:
| 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.
| justsomehnguy wrote:
| > Don't even ask.
|
| Do you did it for her?
| https://i.pinimg.com/736x/58/12/f6/5812f6951b3016edbb5b19697...
| dang wrote:
| 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.
| goombacloud wrote:
| 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/..."
| bityard wrote:
| 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.
| nine_k wrote:
| 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.
| madacol wrote:
| Wait!!!, I always thought SFTP was just FTP server with SSL.
|
| Wow, thanks!
| abeyer wrote:
| SFTP is totally different from FTP (and FTPS) -- it's an ssh
| protocol extension, and is commonly enabled and served by
| your sshd.
| palunon wrote:
| 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)
| bityard wrote:
| Yeah, SFTP is a silly name because it has no relation to FTP.
|
| You're thinking of FTPS which is FTP+TLS.
| arthurcolle wrote:
| Is this some kind of networked filesystem? Not particularly
| familiar with sshfs
| mikepurvis wrote:
| It's a fuse mount of a remote filesystem over the ssh protocol.
| astine wrote:
| 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.
| qbane wrote:
| 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
| gourneau wrote:
| rclone will also mount sftp as a drive https://rclone.org/sftp/
| murph wrote:
| I've found rclone 2-3x faster for large file transfers,
| personally.
|
| Switched off of sshfs after that.
| midislack wrote:
| >ninja
|
| >meson
|
| I hate this kind of development.
| wazzaps wrote:
| Why?
| yuuta wrote:
| 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.
| bityard wrote:
| NFS doesn't do great on high-latency connections, but it really
| shines on (and was designed for) a high-speed LAN.
| FullyFunctional wrote:
| 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).
| justsomehnguy wrote:
| > 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.
| [deleted]
| kzrdude wrote:
| Nice project hand-over policy actually, that sounds very
| reasonable.
| sigmonsays wrote:
| 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?
| mistrial9 wrote:
| satisifed user of rclone here
| woogley wrote:
| 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
| NackerHughes wrote:
| 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
| djbusby wrote:
| Can put those in the ssh user config file
| gralx wrote:
| 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.
| bigpeopleareold wrote:
| 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.
| FullyFunctional wrote:
| 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.
| FullyFunctional wrote:
| 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.
| Filligree wrote:
| 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.
| ASalazarMX wrote:
| 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.
| dTal wrote:
| Additionally, there's a wide semantic gap between "make the
| remote tree appear local" and "make a local _copy_ of the
| entire remote tree ".
| bityard wrote:
| 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.
| Jach wrote:
| I use it with my NAS.
| Perz1val wrote:
| SSHFS is used by KDE Connect to see files on the other device
| bityard wrote:
| 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.
| chasil wrote:
| 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...
| mickeyp wrote:
| > 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.
| __turbobrew__ wrote:
| Yea, NFS processes can get into an uninterruptible and
| unkillable sleep state where then only way to clean up is
| to reboot.
| bravetraveler wrote:
| 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.
| chasil wrote:
| Instead of rebooting, try a lazy unmount on Linux.
| umount -l /stuck/directory
| vetrom wrote:
| 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'.
| alexnewman wrote:
| Soft mount no?
| chasil wrote:
| 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.
| rollcat wrote:
| > 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.
| boulos wrote:
| 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).
| vetrom wrote:
| 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.
| dj_gitmo wrote:
| 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/
| ndsipa_pomu wrote:
| 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.aut
| omount,_netdev,user,idmap=user,follow_symlinks,reconnect,transf
| orm_symlinks,identityfile=/root/.ssh/id_rsa,allow_other,default
| _permissions,uid=1000,gid=1000
| catdog wrote:
| 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.
| jessikat wrote:
| I use winfsp/sshfs-win to remotely access my Haiku system,
| which works extremely well.
| usr1106 wrote:
| 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.
| albertzeyer wrote:
| 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.
| jokethrowaway wrote:
| 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)
| ASalazarMX wrote:
| 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.
| djbusby wrote:
| 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.
| djbusby wrote:
| 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?
| DavideNL wrote:
| To find active forks: https://techgaun.github.io/active-
| forks/index.html
| djhaskin987 wrote:
| 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 :)
| JoshTriplett wrote:
| 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.
| iforgotpassword wrote:
| 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. :-(
| albertzeyer wrote:
| 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?
| tessela wrote:
| 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 .
| IshKebab wrote:
| > 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.
| Groxx wrote:
| 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.
| moralestapia wrote:
| 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.
| iforgotpassword wrote:
| 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.
| nybble41 wrote:
| 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.
| viraptor wrote:
| 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.
| feet wrote:
| 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
| angrygoat wrote:
| 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.
| [deleted]
| bzxcvbn wrote:
| Why are you copy/pasting the first sentences of the linked page
| here without any added content?
| ncmncm wrote:
| Excerpt.
| WalterGR wrote:
| 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
| kzrdude wrote:
| I think it's a port, because they couldn't use the FUSE backend
| (Linux specific)
| benbristow wrote:
| Maybe that it only works on Mac?
| Filligree wrote:
| "Works" is a bit optimistic.
| WalterGR wrote:
| Looking at the commit history, I only see documentation
| changes.
|
| What did I miss?
___________________________________________________________________
(page generated 2022-06-20 23:01 UTC)