A currently maintained fork of SSHFS
github.com
github.com
I use it a lot when I am accessing files from my server on my MacBook Pro .
Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the file over, and then usually SSH back into the system.
Naive question: why the need to kill the ssh session? Can't you just open another terminal window or tab (or tmux/screen tab if that's part of your workflow)
Also, looks like sshfs used in Slackware is abandoned.
https://github.com/libfuse/sshfs
A quote from the link, I wonder if this project will be the 'one':
>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.
I also wonder if it was abandoned due to the RHEL re-orgs like what happened to bluetooth.
As a side note, OpenSSH is quite independent of the Linux ecosystem. It is developed as part of OpenBSD.
openssh-portable is provided as a standalone software package that is broadly POSIX-compliant.
Yes, glad the OpenBSD folks do this. Linux people could learn a lot from OpenBSD Developers (looking directly at Wayland).
It's a neat trick but it's always going to be something that someone bolted on to a solution because they didn't want to deal with a proper file server. Part of the appeal might be that NFS (3 or 4, take your pick) is still the best we've been able to come up with and neither is really that great for basic installation. Still SSHFS is a mess to deal with in a production setup. Some of the messiest production systems I've de-tangled over years have frequently been relying on SSH and SSHFS to do stuff assumes a permanent connection.
But relying on SSHFS in production... Yeah, that's insane.
I have transitioned from years of macfuse + sshfs on Mac to just installing the excellent “mountain duck” tool which gives you finder and mount point access to an sftp endpoint.
Very nice software and indispensable for me.
Libfuse / SSHFS for MacOS started becoming a real burden to try and use a ome years back and it lead me to mountain duck as well.
It also implements more filesystem functionality, as a "df" report will correctly reflect the remote filesystem's usage.
EDIT: NFSv4 also offers "delegations," which give complete control of a file to a client in an expiring lease; the latest NFS clients also have "polite delegations," which tacitly extend the lease period.
SSHFS is very handy for a "quick and dirty" mount, though, with minimal configuration.
Switched from sshfs to NFSv4+wireguard few years back. Works great!
Etymology: “Borrowed from Latin vividus (“animated, spirited”), from vivere (“to live”), akin to vita (“life”), Ancient Greek βίος (bíos, “life”).”
I like it!
Note that SFTP uses an SSH connection for its file transfers, so I have not seen an UI difference from SSHFS
I don’t remember…
Yes it does. You can find it in /run/user/$(id -u)/gvfs/
As an example, my phone has some systemd services which run `gio mount` for an SMB share and an SFTP share, when I'm connected to my home WiFi. I've got symlinks in my home folder to their associated gvfs directories, which become dangling when I'm not at home.
umount -f ~/mounts/fooserver
sshfs -o kill_on_unmount,reconnect,allow_other,defer_permissions,direct_io username@server:/ ~/mounts/fooserver -ovolname=foo
> -o reconnect,cache=no,defer_permissions
So, I add "cache=no"; and omit "kill_on_unmount", "allow_other" and "direct_io". Looks like "kill_on_remount" is a cleanup option; "allow_other" allows other users to mount the same drive (I don't need that) and "direct_io" is similar to "cache=no". FYI...
I think long files are solely caused by somebody incapable of software design at any level. They just keep typing and never think about structure or separation of duties or whatever.
I recall the WindowsCE DHCP service was one large file. An enormous busted-ass straightline pile of garbage code that didn't handle most errors. Written by some intern. I re-wrote it for our platform and removed all the issues.
Microsoft of course didn't want my code because, arrogance.
But I don't think compilation times explain the size of the source files. This hasn't been a problem for such a long time that I cannot even remember when it could have possibly been a problem.
I had seen the reverse problem, but not with C... rather with Python source files. The older parser used to be very bad and would start using too much memory if the source file was in the thousands of LOC. I had to witness this firsthand with SWIG-generated Python bindings. I don't remember this kind of problem with C compilers / other utilities though.
https://github.com/9front/9front/blob/front/sys/src/cmd/sshf...
Assuming this is true--and I think it is fair to trust the author of the statement when judging the same author--this doesn't sound like a project that needs a fork, as it apparently in fact does have an active maintainer; if you want to help contribute to sshfs, you thereby can do that without forking it and causing a mess for everyone having to decide which one to use/ship and without the bad blood inherent in resorting to the four-letter F-word of open source project management.
> 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.
FTP is close to such a thing, but it is somewhat archaic, slow and not sure about its security.
Match Group sftponly
ForceCommand internal-sftp -l INFO -f LOCAL6
AllowTcpForwarding no
AllowAgentForwarding no
GatewayPorts no
X11Forwarding noIs there some way to specify that nothing except internal-sftp is allowed, as opposed to setting each option explicitly to "no"? The latter way seems error-prone, one is bound to miss some obscure option there.
And I wonder why do you suggest using the LOCAL6 log facility? In sftp-server, the default is AUTH...
Looks like the most recent issues and PRs are just junk typo / grammar fixes
But if the maintainer doesn't take the pull request and make a release, then the effort of fixing it is wasted, and every single user has to workaround/suffer from that bug into the future.
There are loads of projects in that state - unmerged PR's from years ago with sensible fixes, no new release, and no forks that are distributed to users.
Next to the "Download zip" button on github, they should add a "Download built .deb" and "Download built .exe" - and those buttons should work on any fork, branch, PR, etc. And they should add all the necessary build infrastructure to achieve that.
It turns out that at scale, build infrastructure is pretty cheap to run, since caching is so incredibly effective and there is only a need to rebuild a file once per (human) edit to a file or its dependencies.
There are a load os SaaS companies that do that allow you to make multiple targets though, so perhaps some integrations there would work.
My point is, there is no way github could add a fully automatic "build and package this release" button. It would require tons of configuration (and trial and error...) from the user.
But good news! If you _are_ willing to figure out how, you can make a github pipeline that compiles and packages your code (producing an "artifact"). Several projects I follow do exactly this. A complex problem like this essentially requires a bespoke solution, and to be fair github does give you tools to automate said solution. The problem is not the infrastructure but the complexity of build systems.
I do agree there should be more ready-made pipelines to aid this process. When I tried to release a python program to work on linux, windows, and macOS, I quickly realized I wasn't interested in figuring out how to make a working pipeline (after spending a weekend getting it to build on each OS in the first place). But surely that's because python is particularly bad at package management... Well, most languages are particularly bad at it
- Cryptographically-verified, content-addressed storage (e.g. IPFS) is preferable to downloading random EXEs from "github and other code hosters". Indeed, for sources too! (I learned this lesson when Microsoft bought GitHub, and many projects jumped ship; that caused an outbreak of 404s for anything that was hard-coding github.com URLs!)
- Rather than relying on someone else having produced opaque blobs for us, it's better for everyone to be capable of building things, if needed. Nix (and Guix) are good for this, since they're source-based, ensuring that the full build instructions are available (they will automatically download binaries, if available and signed by a trusted key; but the option of building ourselves is always there). This is also crucial if we want to validate those binaries for ourselves (I recall the "trustix" project is trying to crowd-source such validation too)
- Another advantage of the Nix/Guix approach is that build instructions can be parameterised, e.g. by the source. This allows anyone to plug in any version of the code they like (whether a git commit, or a local folder, or an IPFS URL, etc.). Again, if someone else has already built that combination (and someone we trust has signed it) then their existing binary will be fetched.
This sort of approach doesn't require any buy-in from hosting platforms, maintainers, DNS authorities, etc.
It may not be just security too, as this integrates FUSE and SSH then there will be bitrot and API drift etc over the years.
> 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.
I saw that there are some semi-active forks focusing on different aspects: a rust rewrite, a persistent cache support version, or a bug fixing only version.
The issue is that most software has bugs and vulnerabilities which has not been discovered yet while the software is not maintained. It means the problems will exist without a solution for the future. Open source software maintainers have been a significant part of our overall IT environment [0] but voluntary contributions are subject to human resource limits. SSHFS is one of those projects relying on a single maintainer which has ended up being archived. The packages on many distributions repositories are stuck as is. The several semi-active forks are also owned by a single person without a proper community. I'm not sure if any of the distro communities would pick one of those and package it to be the next version.
So, the users of these software on their own, with the single, cross platform, ultimately portable packaging solution: the source code.
I also don't really understand what your last sentence is getting at--I may be daft.
See: https://rclone.org/commands/rclone_mount/#mounting-on-macos
If your workflow relies on a VFS that isn't NFS/SMB then don't use MacOS. fuse-t is kind of clever in that it spins up a TCP server that transpiles NFS requests into FUSE requests, but it comes with a bit of a cost and eats a TCP port. The one benefit is that you can actually mount and use a file system entirely in userspace this way, which you can't do on Linux without sandboxing (fusermount3 is SUID to get around this).
I have never heard of someone running out of TCP ports on a personal computer since, well, the invention of TCP on personal computers.
FUSE-T seems more future proof (no kext) and probably less likely to completely hang your Mac, but could potentially be even slower since it’s another abstraction layer in between.
It’s odd that there aren’t any great open source SFTP solutions for the Mac. CyberDuck and FileZilla are barely passable.
I think what hangs the Mac isn't the remote file system as such, but rather some local app or (more likely) low-level OS service assuming that all mounted filesystems are local (or at least low-latency and highly available).
TIL, thank you!
I'm really sad about losing native SSHFS capabilities on macOS (via FUSE, due to the kernel extension deprecation/ban).
I could even get behind the idea of banning all network file systems, but the fact that I can now use SMB and WebDAV(!), but not the one that I actually use all the time, is quite frustrating.
Wasabi seems like the most expensive here, with the caveat that Hetzner requires ordering discrete steps of storage rather than the 'pay-as-you-go' model of the other two
Hetzner is the cheapest; however, your data is stored in Germany or Finland. They have free bandwidth, but you are limited to 10 connections at a time.
Backblaze B2 has 4 regions across the globe, storage is $5/mo, there is no minimun retention time, but does have a cost for API Calls(transactions), and in addition charges for egress data(downloads), so your $5/TB is a variable factor, and if you use your data, you may not achieve $5/TB, the cost will grow depending on the use case(there are free levels of transactions and egress)
Wasabi is $7/TB and has 13 regions across the globe, with free egress and no api charges. It does have 90-day minimum storage charge, which means you are billed for every object for 90 days regardless of if you delete it before 90 days. In addition, the free egress has limits to prevent system abuse. There is a 30-day deleted storage charge available if you purchase in bulk with their RCS(reserved capacity) storage plan. It's good if you want to store a lot of data that does not need deletion.
I have accounts with all 3 of these for different use cases.
I'm pretty disappointed overall by the price increase for storage. Compared to when they launched B2, they now need 1/4 as many servers with 1/2 the upfront cost to store each petabyte.
rclone mount :sftp,host=example.com:path/to/dir /tmp/mountpoint
Sometimes you can manage to get things to use the ssh_config again (e.g. with xpra you can do "--ssh=ssh" but other times I've not yet figured a workaround.