Ja, das war ja schon mit Deiner Antwort im zweiten Posting gelöst.... und das funktionier alles prima. Es ist ja auch gar nicht das Problem einen zusätzlichen Knopf zu installieren, der irgendwas macht, z.B. WLAN deaktivieren oder so..... aber imho ist das gar nicht notwendig, das WLAN vor dem shutdown zu deaktivieren. Und wenn man es trotzdem wollte, sieht die vollständige Job-Kette eines solchen Knopfes m.E. so aus:habakug hat geschrieben: Du wolltest doch eigentlich, dass der User Netzwerkgeräte ein- und ausschalten darf.
1. umount -a -f
2. nmcli device disconnect wlan0
3. shutdown -h now
Aber ich denke, auf Punkt 2 könnte man eigentlich auch verzichten.... 'umount' zuerst, dann direkt 'shutdown'. Den "Disconnect wlan0" übernimmt dann ganz sicher systemd beim poweroff. Das Problem liegt jetzt bei Punkt 1. Jeder Job, egal von wem aufgerufen (systemd, network-dispatcher oder Knopf), scheitert an diesem Punkt ... denn der Anwender ist schlichtweg nicht dazu berechtigt. Und damit läuft der shutdown nicht mehr sauber ab. Entweder gibt der Anwender das root-PWD ein, dann klappt es mit dem umount und der shutdown läuft. Oder er machts nicht (weil er es nicht kennt) und der shutdown hängt mit den Messages "stop-job *irgendwas* 120 seconds" und "Cifs VFS *irgendwas* reconnect 120 seconds" .
Ich suche jetzt ne Lösung, wie ich den Anwender mit vorhandenen (!) Bordmitteln zum umount berechtigen kann (ohne sudo zu installieren), damit der wlan0-Disconnect beim shutdown kein Chaos wegen der vorhandenen mounts auslöst.
Genau das ist das einzige Problem.... denn der Anwender ist nicht zum umount berechtigt. .... .... moment mal.... jetzt gerade beim Schreiben macht da was "click"..... nmcli device disconnect wlan0 wird vom User aufgerufen. Und der dadurch ausgelöste Dispatcher-Job dann mit root-rechten? ... ... dann wäre das ja wirklich die Lösung.... sofern der disconnect dann nicht sofort wieder persistent wäre. Das probiere ich morgen.Das geht jetzt und du brauchst dich um die Rechte beim unmounten nicht zu sorgen.