ubuntuusers.de

Hallo Zusammen, ich habe ein Skript in /usr/local/bin

Inhalt:

1
2
3
4
5
6
7
8

#! /bin/bash
#
OUTPUTFILE=/var/log/sshfs_connect.log
echo $(date) >> $OUTPUTFILE
echo $USER >> $OUTPUTFILE
sshfs $USER@Servername:/home/ /home/Servername

exit 0

Wenn ich das im Terminal aufrufe, dann wird nach Passworteingabe das Verzeichnis schön per sshfs gemountet und bleibt gemountet, auch wenn ich das Terminal beende.

Nun hatte ich die Idee einen Starter einzurichten, sodass ich nur auf dem Desktop doppelklicken muss, Passwort eingeben, Mount erledigt. (In Terminal ausführen angeklickt.)

Wenn der Starter doppelgeklickt wird, dann scheint aber nichts gemountet zu werden.

Wenn man ein sleep 30s hinter dem sshfs-Aufruf eingefügt, dann kann man feststellen, dass tatsächlich gemountet wird. Der Mount bleibt nur so lange erhalten, wie das Skript läuft.

Warum wird der Mount beendet? Wie kann man das umgehen?

Inhalt des Starters:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[Desktop Entry]
Version=1.0
Type=Application
Name=Server_verbinden
Comment=Server verbinden
Exec=/usr/local/bin/sshfs-Servername.sh
Icon=applications-arcade
Path=
Terminal=true
StartupNotify=true
Categories=System;Utility

Hallo Lichtmacher, meiner Meinung nach müsste die Exec=Zeile im Starter ein »sh« enthalten, also so:

Exec=sh /usr/local/bin/sshfs-Servername.sh

Bei mir funktioniert jedenfalls auf diese Weise der Aufruf von Skripten aus .desktop-Dateien.

Ne, das hilft nichts. Habe auch mal /bin/bash davor geschrieben.

Das Skript läuft ja. Das, was mich wundert ist, dass der Mount wieder aufgehoben wird. Ist das eine Besonderheit von sshfs/fuse? Wenn ich ein touch auf eine Datei mache, dann wird sie nach Ende des Skripts ja auch nicht wieder automatisch gelöscht.

Normalerweise wird der Mount-Befehl ausgeführt und der Vorgang ist damit beendet. Hier irgendwie nicht... 🙄

Ich habe inzwischen

1
2
3

Exec=xfce4-terminal -hold -e /usr/local/bin/sshfs-LTS4.sh

Exec=xterm -hold -e /usr/local/bin/sshfs-LTS4.sh

oder direkt

1

Exec=sshfs admini@LTS4:/home/ /home/LTS4

ausprobiert, oder auch einen Eintrag in der /etc/fstab gemacht. Immer mit dem Ergebnis, dass nach beenden des Skripts der Mount wieder gelöst wird.

Getestet, ob es an der Laufzeit des Skripts liegt:

1

Exec=xterm -e "/usr/local/bin/sshfs-LTS4.sh ; echo Hier ; sleep 10s ; echo Dort"

Mit dem Ergebnis, dass der Mount solange besteht, wie die Exec-Zeile ausgeführt wird.

Habe einen Softlink angelegt:

1
2

user@Rechner:~$ ll Schreibtisch/sshfs-LTS4.sh 
lrwxrwxrwx 1 user user 28 Mai 24 11:40 Schreibtisch/sshfs-LTS4.sh -> /usr/local/bin/sshfs-LTS4.sh*

Wenn ich den direkt aufrufe, dann bleibt der Mount erhalten

1

user@Rechner:~$ Schreibtisch/sshfs-LTS4.sh

Wenn ich den so aufrufe, (oder grafisch "öffnen mit terminal")

1

user@Rechner:~$ xfce4-terminal -e Schreibtisch/sshfs-LTS4.sh 

dann wird er wieder gelöst.

Irgendwas macht die Option -e (Starter machen es wohl gleich), was fuse veranlasst den Mount wieder zu lösen.

Hallo!

Dein Aufruf öffnet eine Subshell und führt dort sshfs aus. Wenn die Hauptshell beendet wird, werden die Kindprozesse mit beendet. Also um es grafisch auszudrücken: Wenn du ein Terminal mit Ctrl-d „beendest“ (was exit entspricht) laufen die Kindprozesse weiter. Klickst du auf das [X] zum schließen, werden sie mitbeendet.

Du müsstest also deinen Aufruf bspw. mit nohup starten, um diese Verbindung zu lösen → nohub /usr/local/bin/sshfs-LTS4.sh &

Was den Unterschied zwischen direkt aufrufen und über eine Desktopdatei aufrufen angeht: Deine Umgebungsvariablen unterscheiden sich. Teste das Script mit bspw. sh --noprofile, um sowas auszuschließen.

Hallo ChickenLipsRfun2eat, danke für Deine Hilfe.

Wenn du ein Terminal mit Ctrl-d „beendest“ (was exit entspricht) laufen die Kindprozesse weiter. Klickst du auf das [X] zum schließen, werden sie mitbeendet.

Wenn ich ein Terminal öffnen, dort das Skript starte und dann das Terminal mit einem Klick auf das [X] beende, dann bleibt der Mount aber erhalten.

Was den Unterschied zwischen direkt aufrufen und über eine Desktopdatei aufrufen angeht: Deine Umgebungsvariablen unterscheiden sich. Teste das Script mit bspw. sh --noprofile, um sowas auszuschließen.

Ein

1

xfce4-terminal -x /bin/bash --noprofile /usr/local/bin/sshfs-LTS4.sh

ändert nichts sichtbares.

Du müsstest also deinen Aufruf bspw. mit nohup starten, um diese Verbindung zu lösen → nohup /usr/local/bin/sshfs-LTS4.sh &

Jaaaa, das hatte ich auch schon ausprobiert, scheiterte daran, dass ich dann kein Passwort beim sshfs eingeben konnte.

Habe das jetzt passwortlos (sshkeygen ...) eingerichtet und nochmal probiert. Dann funktioniert es.

Wenn man das nohup direkt in den Starter schreibt, dann gibt es keine Ausgaben mehr zu sehen. Wenn man es in das Skript vor das sshfs .. schreibt, dann kann man halt kein Passwort mehr eingeben.

Der Versuch das mit disown zu umgehen scheiterte:

1

sshfs $USER@Servername:/home/ /home/Servername & disown -h

Mount wird gelöst.

Lichtmacher schrieb:

Wenn ich ein Terminal öffnen, dort das Skript starte und dann das Terminal mit einem Klick auf das [X] beende, dann bleibt der Mount aber erhalten.

Möglich. Kommt ja ein wenig auf die Implementierung an, wo die Kindprozesse laufen. Du kannst dir die Elternprozesse anzeigen lassen

ps -o ppid= -p $(pgrep sshfs)

Bei mir ist das (über Yakuake/Alacritty gestartet) immer systemctl --user, daher bleibt der Prozess bestehen, wenn ich die Terminals schließe. Dürfte dann beim xfce-terminal auch so sein. Allerdings führt das vom Thema weg 😉

Also im Starter Exec=/tmp/script und /tmp/script gehört dem Nutzer und enthält

#!/bin/bash
/usr/bin/sshfs -o reconnect -o allow_other -o idmap=user -o uid=1002 -o gid=1010 daten@heimknecht.ck:sam/ /home/common/Sammelmappe/ -o IdentityFile=/home/common/.ssh/K_daten

heimknecht ist mein lokaler Server, /home/common ein für meine Nutzer gemeinsames Verzeichnis (Gruppe 1010). Dürfte in dem Fall aber irrelevant sein. Das ausschlaggebende ist hier -o reconnect. Könntest du also auch benutzen, wenn das in deinem Anwendungsfall sinnvoll ist. Ohne reconnect kommen wir zum direkten disconnect, wie in deinem Fall. Mit nohup funktioniert es, wie du gemerkt hast. Ähnlich wäre es mit su - $USER -c /usr/bin/sshfs…. Kommt auf den Anwendungsfall an. Ich nutze immer reconnect, da ich auch bei Netzwerkwechsel & Co die Verbindung erhalten will und es durch den gemeinsamen Ordner egal ist mit welchem meiner Logins ich einhänge.

Wenn du sowieso ein Passwort eingibst, wieso legst du dir dann nicht einfach einen Alias an und sparst dir das ganze gerödel? SSH-key halte ich aber eh für Pflicht bei sshfs. Im rein lokalen Netz nehme ich NFS

alias srv='sshfs -o[…] user@$host:ordner/ /lokaler/einhängepunkt -o IdentityFile=~/.ssh/schlüssel'

Dann brauchste nur srv ins Terminal tippern. Fragt dann auch nach dem Passwort, wenn du keinen Schlüssel hast.

Die Passworteingabe habe ich jetzt so gelöst (War nochmals ein Klimmzug.):

sshfs hat nämlich keinen Schalter wo man das Passwort direkt übergeben könnte.

Im Skript das Passwort mit zenity abfragen und per <<< "here string" (ist mir vollkommen neu) übergeben.

1
2

PASS=$(zenity --entry --hide-text --text="Passwort eingeben:")
nohup sshfs admini@LTS4:/home $LTS4 -o password_stdin <<< $PASS

Denn wenn man nohup verwendet, dann kann man aber nicht einfach "pipen", da die dann an nohup geht.

1

echo $PASS | nohup sshfs admini@LTS4:/home $LTS4 -o password_stdin

Da haben sich unsere beiden Posts gerade überschnitten.

ChickenLipsRfun2eat schrieb:

Das ausschlaggebende ist hier -o reconnect. Könntest du also auch benutzen, wenn das in deinem Anwendungsfall sinnvoll ist.

Bei reconnect fragt mein openssh-Authenticator ein zweites Mal nach dem Passwort... . Irgendwie klar. Die Verbindung bleibt dann stehen. Gut.

Die manpage zu sshfs zur Option reconnect:

1
2

-o reconnect
              reconnect to server

weniger Inhalt geht kaum. Die Option scheint mir aber interessant.

Mit nohup funktioniert es, wie du gemerkt hast. Ähnlich wäre es mit su - $USER -c /usr/bin/sshfs….

Bei

1

su - $USER -c sshfs $USER@Servername:/home/ /home/Servername

kommt bei mir nach der Passworteingabe von su

1
2

missing host
see `sshfs -h' for usage

Warum auch immer.

Wenn du sowieso ein Passwort eingibst, wieso legst du dir dann nicht einfach einen Alias an und sparst dir das ganze Gerödel?

Im jugendlichen Leichtsinn dachte ich mir, machste mal kurz einen Starter - Doppelklick, Passwort, fertig... .

Zudem brauchen den Link andere Nutzer, die das Terminal nicht kennen. Da bei denen die Schlüssel eingerichtet sind, wird da die Option reconnect funktionieren.

Nagel mich da jetzt nicht drauf fest, aber soweit ich das verstehe, wird sshfs ausgeführt und gibt nach erfolgreicher Ausführung sein „Ende“ bekannt → das Terminal bekommt das SIGCHLD-Signal und arbeitet im Script weiter. Sobald das Script fertig ist, beendet sich das Terminal und räumt alles in seiner „Scope“ auf. Da FUSE im Nutzerbereich stattfindet, wird die Verbindung einfach mit aufgeräumt, daher musst du da drumherum arbeiten. nohup trennt den Prozess vom Terminal, verhindert also das aufräumen. reconnect veranlasst den erneuten Funktionsaufruf, sobald die Verbindung unterbrochen wurde, ein Eintrag in der fstab oder das Aufrufen einer separaten Shell könn(t)en das auch verhindern.

missing host

klingt nach falschem/fehlenden Quoting. Verwende -c 'sshfs…'

Welche Info zu reconnect fehlt dir denn? Im Prinzip wird versucht die Verbindung auf biegen und brechen wiederherzustellen, egal ob durch Netzwerkfehler oder Abschießen des Prozesses — so lange bis ein fusermount -u das Aushängen anordnet.

Danke für Deine Unterstützung.

ChickenLipsRfun2eat schrieb:

Sobald das Script fertig ist, beendet sich das Terminal und räumt alles in seiner „Scope“ auf. Da FUSE im Nutzerbereich stattfindet, wird die Verbindung einfach mit aufgeräumt, daher musst du da drumherum arbeiten.

Das war halt für mich etwas überraschend, da ich so etwas bei mount noch nicht erlebt habe. Ist aber nachvollziehbar.

nohup trennt den Prozess vom Terminal, verhindert also das aufräumen.

Klar. Warum disown das nicht tut, ist mir nicht ganz klar. Das macht doch etwas ähnliches?!

reconnect veranlasst den erneuten Funktionsaufruf, sobald die Verbindung unterbrochen wurde, ein Eintrag in der fstab oder das Aufrufen einer separaten Shell könn(t)en das auch verhindern. Welche Info zu reconnect fehlt dir denn? Im Prinzip wird versucht die Verbindung auf biegen und brechen wiederherzustellen, egal ob durch Netzwerkfehler oder Abschießen des Prozesses — so lange bis ein fusermount -u das Aushängen anordnet.

Genau das wäre schon etwas mehr Info, die dazu führt, dass man eine Ahnung erhält, was diese Option macht.

missing host klingt nach falschem/fehlenden Quoting. Verwende -c 'sshfs…'

So ist es.

1

su - $USER -c 'sshfs $USER@Servername:/home/ /home/Servername'

Allerdings geht es nicht, wenn das Passwort abgefragt werden muss. Dann versagt su:

1

read: Connection reset by peer

Ich vermute, dass die Meldung von der Shell kommt, die STDIN nicht verwenden kann?

Wie auch immer das eigentliche Anliegen ist geklärt, das andere war lernen drum rum.

Lichtmacher schrieb:

Das war halt für mich etwas überraschend, da ich so etwas bei mount noch nicht erlebt habe. Ist aber nachvollziehbar.

Passiert auch nur mit FUSE und im Nutzerkontext. Ich bin da seinerzeit schon mal drübergestolpert, aber es war nicht SSH… Komme aber auch nicht mehr drauf, FUSE kann ja für einiges herhalten.

Klar. Warum disown das nicht tut, ist mir nicht ganz klar. Das macht doch etwas ähnliches?!

disown ist bash-intern (siehe man bash) und nohup aus den core-utils. Wenn du disown verwendest, musst du also sicherstellen, das auch wirklich bash ausgeführt wird, nicht sh, dash, ash, etc. pp. Eigentlich™ sollten die das gleiche tun, disown hat aber andere Argumente und ich habe dessen Verwendung ehrlich gesagt bisher immer vermieden 😀 Nohup tut es ja, in den seltenen Fällen, in denen ich das mal brauche.

…reconnect…

Genau das wäre schon etwas mehr Info, die dazu führt, dass man eine Ahnung erhält, was diese Option macht.

Ehrlich gesagt, ich habe keine Ahnung wieso deine Manpage nicht mehr hergibt. Meine sieht so aus: Manpage:sshfs. Wollte eben mal nachgucken, was da genau steht und musste feststellen, das es da große Unterschiede gibt, wenn man im Netz auf andere Seiten guckt. Lokal solltest du aber auch die „größere“ Manpage haben, die hat sogar mein angestaubtes Debian auf dem Raspi. Falls nicht, solltest du mal mandb aktualisieren.

missing host klingt nach falschem/fehlenden Quoting. Verwende -c 'sshfs…'

Allerdings geht es nicht, wenn das Passwort abgefragt werden muss…

Also in meinem Fall bleibt das Fenster offen, allerdings steht da keine Info und ich muss mein Benutzer-PW blind und ohne Aufforderung eintippen. (In der Desktop-Datei ist Terminal=true gesetzt).

Ich vermute, dass die Meldung von der Shell kommt, die STDIN nicht verwenden kann?

Kann sie eigentlich schon. Versuche mal im Script set -x mitzugeben, vielleicht hast du dann mehr Details. Du brauchst ja irgendwo die Schnittstelle zur Passwort-Eingabe. Also entweder vorher, wie in deinem Zenity-Beispiel oder mit Terminal=true und Eingabefeld.

Wie auch immer das eigentliche Anliegen ist geklärt, das andere war lernen drum rum.

Das ist ja gerade das spannende… 😉

Danke.

Zu man sshfs

Wie oben steht ist es Xubuntu 20.04 und ich habe sshfs so installiert:

1

sudo apt install sshfs

und dann bekommt man diese Manpage 😬 http://manpages.ubuntu.com/manpages/focal/man1/sshfs.1.html

...
  SSHFS options:
       -p PORT
              equivalent to '-o port=PORT'

       -C     equivalent to '-o compression=yes'

       -F ssh_configfile
              specifies alternative ssh configuration file

       -1     equivalent to '-o ssh_protocol=1'

       -o reconnect
              reconnect to server

       -o delay_connect
              delay connection to server

...

Anliegen ist gelöst.