Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A currently maintained fork of SSHFS

github.com

Post reply on HN
Print view View original

101–110 of 144 posts

Re: A currently maintained fork of SSHFS

#101

Post by feldrim »

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

0. https://xkcd.com/2347/

Re: A currently maintained fork of SSHFS

#102

Post by dpatterbee »

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…

Note that in October B2 is removing egress costs and increasing storage prices to $6/TB.

Re: A currently maintained fork of SSHFS

#103

Post by duped »

callalex wrote: post #85
duped wrote: post #74

Earlier quoted context omitted.

VFS on MacOS is a minefield. You either need to use a kext (bad option, for many reasons), a network file system (NFS or SMB) and pretend your VFS is a remote server, or create a FileProvider system extension (which cannot actually function as a VFS). 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 FU…

>but it comes with a bit of a cost and eats a TCP port I have never heard of someone running out of TCP ports on a personal computer since, well, the invention of TCP on personal computers.

No, but port conflicts do happen.

Re: A currently maintained fork of SSHFS

#104

Post by kpw94 »

Zambyte wrote: post #62
zitterbewegung wrote: post #34

If you want something in user land and you don't mind emacs there is TRAMP “Transparent Remote (file) Access, Multiple Protocol”. https://www.gnu.org/software/tramp/ I use it a lot when I am accessing files from my server on my MacBook Pro .

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. 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 f…

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

Re: A currently maintained fork of SSHFS

#105

Post by jmspring »

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.

Mountain Duck has been my goto as well. That said, for VSCode the Remote SSH extenion from Microsoft helps greatly in working with repositories on VMs and other remote machines.

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.

Re: A currently maintained fork of SSHFS

#106

Post by koito17 »

Zambyte wrote: post #62
zitterbewegung wrote: post #34

If you want something in user land and you don't mind emacs there is TRAMP “Transparent Remote (file) Access, Multiple Protocol”. https://www.gnu.org/software/tramp/ I use it a lot when I am accessing files from my server on my MacBook Pro .

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. 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 f…

TRAMP is amazing. Whenever I need to edit configuration files or code on a remote server, I get to keep the exact same Emacs setup as if I were doing things locally. There are noticeable delays in opening and saving files on slow connections, but it's good enough that I can't remember the last time I have used nano or vi in a remote server.

Re: A currently maintained fork of SSHFS

#107

Post by Dylan16807 »

dpatterbee wrote: post #102
ph4te wrote: post #92

Earlier quoted context omitted.

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…

Note that in October B2 is removing egress costs and increasing storage prices to $6/TB.

* removing egress costs up to 3x your amount of stored data

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.

Re: A currently maintained fork of SSHFS

#108

Post by lxgr »

duped wrote: post #74
Filligree wrote: post #49

Earlier quoted context omitted.

Does the FUSE mount work on OSX?

VFS on MacOS is a minefield. You either need to use a kext (bad option, for many reasons), a network file system (NFS or SMB) and pretend your VFS is a remote server, or create a FileProvider system extension (which cannot actually function as a VFS). 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 FU…

> fuse-t is kind of clever in that it spins up a TCP server that transpiles NFS requests into FUSE requests

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.

Re: A currently maintained fork of SSHFS

#109

Post by lxgr »

tambourine_man wrote: post #95
duped wrote: post #74

Earlier quoted context omitted.

VFS on MacOS is a minefield. You either need to use a kext (bad option, for many reasons), a network file system (NFS or SMB) and pretend your VFS is a remote server, or create a FileProvider system extension (which cannot actually function as a VFS). 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 FU…

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

Re: A currently maintained fork of SSHFS

#110

Post by artificialLimbs »

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

Post reply on HN