SSHFS steht für Secure SHell FileSystem und ist ein Netzwerk-Dateisystem, das Dateien und Verzeichnisse entfernter Rechner per SFTP in das eigene Dateisystem einhängt. Dazu wird auf dem lokalen Rechner FUSE (Filesystem in Userspace) verwendet. SSHFS steht nicht nur für Linux, sondern auch für FreeBSD, OpenBSD, OpenSolaris, macOS und Android zur Verfügung. Auf dem entfernten Rechner muss dafür kein Netzwerkdienst wie CIFS oder NFS bereitstehen. Das verwendete SFTP (SSH File Transfer Protocol) ist eine Protokollerweiterung von SSH und hat außer dem etwas irreführenden Namen nichts mit FTP zu tun.
Auf GitHub archiviert
Mit der Veröffentlichung von SSHFS 3.7.3 hat der Entwickler Nikolaus Rath das Projekt als verwaist erklärt und des Repository auf GitHub als archiviert markiert. Lediglich die Mailing-Liste verbleibt für den Moment aktiv. Zu den Gründen für seinen Schritt erklärt Rath auf GitHub:
SSHFS wird von allen großen Linux-Distributionen ausgeliefert und ist seit vielen Jahren auf einer Vielzahl von Systemen im Einsatz. Zurzeit hat SSHFS jedoch keine aktiven, regelmäßigen Mitwirkenden und es gibt eine Reihe von bekannten Problemen (siehe Bugtracker). Der derzeitige Betreuer kümmert sich weiterhin um Pull-Requests und veröffentlicht regelmäßig neue Versionen, hat aber leider keine Kapazitäten, um weitere Entwicklungen vorzunehmen, die über die Behebung von schwerwiegenden Problemen hinausgehen.
Nikolaus Rath
Maintainer gesucht
Wenn sich ein Maintainer findet, der das Projekt übernehmen möchte, kann er es forken und mit der Entwicklung beginnen. Nach einem halben Jahr zielgerichteter Entwicklung ist Rath bereit, das Repository zu übertragen oder einen Link auf den Fork zu setzen. Findet sich kein Nachfolger, wird dieses nützliche Tool mit der Zeit aus den Distributionen verschwinden.
Bildquelle: Wikipedia

Ich hab mir den Bugtracker mal angesehen, die meisten Bugs sind eher exotisch zu fixen. Aber ich versuche mich mal an ein zwei. Die Pullrequest scheinen aber nicht recht regelmäßig bearbeitet zu werden. Statt das Projekt dicht zu machen könne man an die Linuxfoundation oder Apache schreiben ob man nicht eine Dachgesellschaft bekommt? Es ist auch nicht so klar erkenntlich was sich der Author von einem Fork erwartet. Ein comaintainer für den Anfang wäre vermutlich hilfreich? Gsoc Projekt?
Das wäre sehr schlecht! Ich bin begeisterter User von SSHFS und es ist die zuverlässigste und simpelste Lösung, die ich bisher für ein kleines Heimnetzwerk gefunden habe.
Das wäre in der Tat sehr schade, auch wenn ich das nicht nutze. Alternativ für ein Heimnetz kann ich nur NFS empfehlen. Arbeite ich seit über 15 Jahren mit und kann mich nicht Beschwerden. Klar, alles hat Vor- und Nachteile. Samba gibt es ja auch noch aber ja, wäre nicht gut.
Vergleiche zwischen Äpfeln und Birnen helfen in diesem Falle aber nicht viel. Denn sshfs bringt einen entscheidenden Vorteil gegenüber der angeführten Protokolle mit.
Ich habe keinen Vergleich gezogen und wollte das auch nicht.
Es ging mir lediglich um eine Alternative.
Von welchem Vorteil spricht du? Einfachheit, Performance bei Verschlüsselung, …
Im übrigen ist NFS nicht die schlechteste Alternative für zu Hause wie der kleine Bericht zeigt: https://blog.ja-ke.tech/2019/08/27/nas-performance-sshfs-nfs-smb.html
Finde das auf jeden Fall einen guten Ausgangspunkt.
Mich überzeugen ein paar bunte Bildchen nicht wirklich. Auch, weil es immer auf die saubere Implementierung ankommt. Aber nicht einmal damit kann dieser Blogger vorzeigen. Man merkt immer wieder, wir spielen nicht in derselben Liga. Du hast Dich, wenn überhaupt, doch nur sehr oberflächlich mit dem Thema beschäftigt. Deswegen hat es auch wenig Sinn, mit Dir über das Thema zu sprechen. Was Du mit Deiner Rückfrage auch gleich bestätigst. Aber sicherlich für Dein zu Hause-Netz mag das ausreichen.
Was ich an dir so mag, ist deine charmante Art, die Überheblichkeit, (upsi, stop, Netiquette) … Ich habe nie behauptet mich tiefer mit dem Thema beschäftigt zu haben und zum 100x: Ich bin kein ITler und habe auch beruflich nichts damit zu tun …und trotzdem darf ich hier meine Meinung äußern und Hinweise liefern. Ob du die gut oder nicht gut findest, interessiert weder mich noch vermutlich andere hier (spekulativ). Lass die Kirche im Dorf und halt das runde Ding mal flach. Mahlzeit!
sshfs kommt regelmäßig nicht nur in kleinen Netzwerken zum Einsatz, ich kenne ganze Infrastrukturprojekte, die darauf setzen. Das Protokoll ist recht robust, weswegen es so gern eingesetzt wird. Aber da der ssh-Maintainer weiß, dass dieses Protokoll oft zum Einsatz kommt und diesen Schritt bewusst, trotz seines Wissens gegangen ist, wird diesem Protokoll nun hoffentlich genügend Aufmerksamkeit und Pflege geschenkt und die bestehenden Probleme können behoben werden.
Allerdings ist es fraglich, wieso der ssh-Maintainer die ihm bekannten Probleme in sshfs nicht bereits angegangen, oder zumindest früher nach Hilfe fragte, ohne gleich einen so drastischen Schritt zu gehen? Nachdem ich mir aber die Issues angeschaut habe, die wirklich nicht trivial sind, kann gesagt werden, dass der Maintainer wohl wirklich kompetente Hilfe benötigt.
Das “außer dem” im zitiertem Text sollte berichtigt werden und könnte durch ein “ansonsten” ersetzt werden, dann klingt der Satz besser.
Naja fuse ist nicht FSTP und deswegen nicht ssh. sshfs ist eine implemnetierung von sftp über fuse. SSH kommt von openbsd fuse von Linux. fuse gibts auch in openbsd und der sshfs ist dort leider nur in den ports. Die Hoffung wäre dass sshfs von openbds gepflegt wird. Ist leider eher unwarscheinlich. https://openports.se/sysutils/sshfs-fuse
Mittlerweile ist auch für mich sshfs unentbehrlich, da es für mich folgende Vorteile hat: