A currently maintained fork of SSHFS • Hacker News Board

Re: A currently maintained fork of SSHFS

#121

Post by jjrh » Tue, Sep 05, 2023, 11:31 PM UTC

fragmede wrote: post #112

epcoa wrote: post #67

Earlier quoted context omitted.

No it’s a horrible fit. OpenSSH is focused on a high quality, secure implementation of a rather complex protocol. And OpenSSH is not a core piece of Linux infrastructure any more than say gcc is. These projects serve other, greater ends. A FUSE driver is a bunch of baggage that is poorly suited to be maintained with it.

Given than fusefs provides FUSE support on BSDs, it seems more than "a bunch of baggage", given how useful it is.

I don't think the person was intending to say it's not useful, only out of scope.

Re: A currently maintained fork of SSHFS

#122

Post by mappu » Tue, Sep 05, 2023, 11:51 PM UTC

ph4te wrote: post #92

FredFS456 wrote: post #75

Earlier quoted context omitted.

Backblaze B2 is $5/TB/month, Hetzner is $4.08/TB/month for 1TB, Wasabi is $6.99/TB/month 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

They are all OK to use, and each provider has pros and cons, depending on the use case. 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 egr…

Regarding Hetzner Storage Box's 10 connection limit, Hetzner also has Storage Share (Nextcloud hosting) at basically the same price point (~3 EUR/TB at the 10TB+ size), only it comes with 200 connections. Rclone supports WebDAV for Nextcloud just as well.

Re: A currently maintained fork of SSHFS

#123

Post by tambourine_man » Wed, Sep 06, 2023, 12:24 AM UTC

lxgr wrote: post #109

tambourine_man wrote: post #95

Earlier quoted context omitted.

MacFUSE always seems unbearably slow to me. Specially in the Finder. Has it improved? 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.

> less likely to completely hang your Mac 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).

That too, but I remember having straight kernel panics. Granted, that was more than a decade ago.

Re: A currently maintained fork of SSHFS

#124

Post by dtgriscom » Wed, Sep 06, 2023, 12:52 AM UTC

artificialLimbs wrote: post #110

the-alchemist wrote: post #39

Anyone try rclone or sshfs on Mac OS X with macfuse/osxfuse?

I use Macfuse to localfolder all of my servers. Works great. Have a little script for each server: mount_fooserver.sh: umount -f ~/mounts/fooserver sshfs -o kill_on_unmount,reconnect,allow_other,defer_permissions,direct_io username@server:/ ~/mounts/fooserver -ovolname=foo

Interesting. I use

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

Re: A currently maintained fork of SSHFS

#125

Post by mbirth » Wed, Sep 06, 2023, 1:24 AM UTC

rsync wrote: post #52

A note … 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.

Just for the record: for macOS there’s now https://www.fuse-t.org/ which works without a kext (by spawning a local NFS server in the background and having macOS connect to it) and also has a sshfs implementation listed on https://github.com/macos-fuse-t/fuse-t/wiki#sample-filesyste... .

Re: A currently maintained fork of SSHFS

#126

Post by jmclnx » Wed, Sep 06, 2023, 1:35 AM UTC

johnvaluk wrote: post #87

mrweasel wrote: post #66

Earlier quoted context omitted.

I kinda doubt it, SSH already have SFTP and SSHFS is .... quite honestly a tool that has no business existing. 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 i…

SSHFS provides enormous value precisely because it doesn't rely on configuring a file server or elevated privileges. It's convenient, secure and performs well. The ability to create ad hoc mounts for any remote location I can access via SSH is awesome (though I prefer rsync or scp for file transfers). But relying on SSHFS in production... Yeah, that's insane.

I use sshfs at work to mount some AIX Dirs on my Linux Workstation, very convenient.

Re: A currently maintained fork of SSHFS

#127

Post by computersuck » Wed, Sep 06, 2023, 2:04 AM UTC

Is it google summer of code or some similar event right now?

Looks like the most recent issues and PRs are just junk typo / grammar fixes

Re: A currently maintained fork of SSHFS

#128

Post by computersuck » Wed, Sep 06, 2023, 2:15 AM UTC

chrkl wrote: post #9

Unfortunately, this fork does not look very vivid. Last commit in March, almost not activity in terms of PRs and issues. I would not bet on it.

"Vivid" is the javascript definition of touching shit when it works and breaking it

Re: A currently maintained fork of SSHFS

#129

Post by arthur2e5 » Wed, Sep 06, 2023, 5:04 AM UTC

qbane wrote: post #58

I think SFTP is a good but underrated protocol, when mirroring a file tree bidirectionally makes more sense than cloning one to another. Having forked and studied from SSHFS' code, I am currently maintaining a list of resources and some personal thoughts on https://hackmd.io/@q/sftp-over-ws .

SFTP is a major step up from FTP, but there's a lot of unrealized potential on the server side, so you can't just work on better clients. Both OpenSSH and the GNU lsh server only offer an old version of the protocol -- v2, I think. That oldness is intentional: https://marc.info/?l=openssh-unix-dev&m=168488976013498&w=2

Re: A currently maintained fork of SSHFS

#130

Post by fyrabanks » Wed, Sep 06, 2023, 5:16 AM UTC

feldrim wrote: post #101

> This repository has been archived by the owner on May 26, 2022. It is now read-only. > 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 r…

I have nothing but respect for Nikolaus, and SSHFS is absolutely a cornerstone of IT, but if you think the original project was protecting you from vulnerabilities.. I have a bridge to sell you.

I also don't really understand what your last sentence is getting at--I may be daft.