Hallo, bei mir - Desktop Xfce - ist das Handling von verschlüsselten Festplatten/USB-Sticks/SD-Karten denkbar einfach. In den Rechner stecken, es erscheint ein Desktopicon, das anklicken, die Passwortabfrage (richtig) beantworten. Danach geht der Dateiverwalter Thunar auf, und gut ist. Nicht so mit KDE! Es erscheint zwar in dieser Geräteverwaltung ein "xxxGBit verschlüsseltens Laufwerk", wobei das Label der Festplatte/USB-Stick/SD-Karte schon mal ignoriert wird. Ein Klick auf diesen Eintrag bewirkt - nichts. Wie bekomme ich nun so einen Datenträger geöffnet? -- FloriDie
Am 07.07.21 um 18:14 schrieb Florian Dietzsch:
Hallo,
bei mir - Desktop Xfce - ist das Handling von verschlüsselten Festplatten/USB-Sticks/SD-Karten denkbar einfach. In den Rechner stecken, es erscheint ein Desktopicon, das anklicken, die Passwortabfrage (richtig) beantworten. Danach geht der Dateiverwalter Thunar auf, und gut ist. Nicht so mit KDE! Es erscheint zwar in dieser Geräteverwaltung ein "xxxGBit verschlüsseltens Laufwerk", wobei das Label der Festplatte/USB-Stick/SD-Karte schon mal ignoriert wird. Ein Klick auf diesen Eintrag bewirkt - nichts. Wie bekomme ich nun so einen Datenträger geöffnet?
"Hier" Leap 15.2 (KDE), ging es fast genauso. Datenträger anstecken; Die Geräteüberwachung geht auf und zeigt ein verschlüsseltes Laufwerk; Draufklicken; Passwort eingeben; Zugriff auf die Partition ist möglich. Jetzt (Ich hatte das schon länger nicht mehr probiert) zeigt die Geräteüberwachung an das ich keine Berechtigung zum Einhängen des Gerätes habe. Im Dolphin ist die Partition(!) aber trotzdem zu sehen und zu bearbeiten. Evtl. klickst Du nicht auf das Icon rechts, sondern auf den ganzen Eintrag? Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Am 07.07.21 um 22:36 schrieb Bernd Nachtigall:
Am 07.07.21 um 18:14 schrieb Florian Dietzsch:
Hallo,
bei mir - Desktop Xfce - ist das Handling von verschlüsselten Festplatten/USB-Sticks/SD-Karten denkbar einfach. In den Rechner stecken, es erscheint ein Desktopicon, das anklicken, die Passwortabfrage (richtig) beantworten. Danach geht der Dateiverwalter Thunar auf, und gut ist. Nicht so mit KDE! Es erscheint zwar in dieser Geräteverwaltung ein "xxxGBit verschlüsseltens Laufwerk", wobei das Label der Festplatte/USB-Stick/SD-Karte schon mal ignoriert wird. Ein Klick auf diesen Eintrag bewirkt - nichts. Wie bekomme ich nun so einen Datenträger geöffnet?
"Hier" Leap 15.2 (KDE), ging es fast genauso. Datenträger anstecken; Die Geräteüberwachung geht auf und zeigt ein verschlüsseltes Laufwerk; Draufklicken; Passwort eingeben; Zugriff auf die Partition ist möglich.
Jetzt (Ich hatte das schon länger nicht mehr probiert) zeigt die Geräteüberwachung an das ich keine Berechtigung zum Einhängen des Gerätes habe. Im Dolphin ist die Partition(!) aber trotzdem zu sehen und zu bearbeiten.
Evtl. klickst Du nicht auf das Icon rechts, sondern auf den ganzen Eintrag?
Genau das ist es! in der Konsole sieht man dann mit "df" den Mountpoint. Das ganze müsste sich mit einem geeigneten Eintrag in fstab zu einem eingängigerem Mountpoint legen lassen. Peter
Am 08.07.21 um 14:01 schrieb Jan-Uwe Kögel:
Am Donnerstag, dem 08.07.2021 um 00:16 +0200 schrieb Peter McD:
Das ganze müsste sich mit einem geeigneten Eintrag in fstab zu einem eingängigerem Mountpoint legen lassen.
Das glaube ich nicht!
Und ich kann sagen, dass ich das schon probiert habe. Der fstab-Eintrag verschlüsselter externer Medien wird bei mir komplett ignoriert. Gruß, Michael
Am 08.07.21 um 14:01 schrieb Jan-Uwe Kögel:
Am Donnerstag, dem 08.07.2021 um 00:16 +0200 schrieb Peter McD:
Das ganze müsste sich mit einem geeigneten Eintrag in fstab zu einem eingängigerem Mountpoint legen lassen.
Das glaube ich nicht!
Verschiedenes ausprobiert: Wie es aussieht, hast glaubst Du das richtige:-( Peter
Am Sonntag, dem 11.07.2021 um 11:47 +0200 schrieb Peter McD: Hallo Peter
Verschiedenes ausprobiert: Wie es aussieht, hast glaubst Du das richtige:-(
Wenn ich mich richtig erinnere hatte ich das letzte mal Probleme mit dem selbstständigen mounten beliebiger, als auch verschlüsselter, Datenträger zu der Zeit als SuSE (open gab es damals nämlich noch nicht) als IMO einzige erwähnenswerte Distribution auf den HAL = Hardware Abstraction Layer gesetzt hat. Das war glauben ich zur Zeit von SuSE 9x, bis hinein nach 10x. Dieses Konzept hat sich dann recht schnell als "Broken by design" herausgestellt, aber was habe ich damals geflucht. Und endlos gebastelt! -- JUK
Am Donnerstag, dem 08.07.2021 um 00:16 +0200 schrieb Peter McD: Hallo Peter
Das ganze müsste sich mit einem geeigneten Eintrag in fstab zu einem eingängigerem Mountpoint legen lassen.
Wie geht das? Nach allem was ich mir zusammengesucht habe ist (sollte) das seit ungefähr 15 Jahren eigentlich nicht mehr so gemacht werden müssen. Vor 15 Jahren wusste ich nicht mal dass es auch andere Betriebssysteme außer $MS und Apple gibt. ;-) -- FloriDie
Am 10.07.21 um 17:14 schrieb Florian Dietzsch:
Am Donnerstag, dem 08.07.2021 um 00:16 +0200 schrieb Peter McD:
Hallo Peter
Das ganze müsste sich mit einem geeigneten Eintrag in fstab zu einem eingängigerem Mountpoint legen lassen.
Wie geht das? Nach allem was ich mir zusammengesucht habe ist (sollte) das seit ungefähr 15 Jahren eigentlich nicht mehr so gemacht werden müssen. Vor 15 Jahren wusste ich nicht mal dass es auch andere Betriebssysteme außer $MS und Apple gibt. ;-)
Unter 15.3 - KDE funktioniert es doch, trotz Fehlermeldung. Die wird vermutlich irgendwann beseitigt. Allerdings gefällt mir die Variante als root mit mount.crypt /dev/xyzN /mountpoint ein Laufwerk an einen beliebigen Mountpoint zu legen besser, der findet sich einfacher mit dem Dolphin. Peter
Am Sonntag, dem 11.07.2021 um 12:11 +0200 schrieb Peter McD:
Hallo Peter
Allerdings gefällt mir die Variante als root mit mount.crypt /dev/xyzN /mountpoint ein Laufwerk an einen beliebigen Mountpoint zu legen besser, der findet sich einfacher mit dem Dolphin.
Das ist in diesem Fall genau so n i c h t praktikabel wie das mehrfach notwendige ausführen der Befehle systemctl start "Demon" und systemctl enable "Deomon", damit diese Dienste im Hintergrund laufen. Denn der Demon von Spamassassin z.B. überlebt grundsätzlich keinen Reboot des installierten openSUSE Systemes. -- FloriDie
Am 11.07.21 15:40 schrieb Florian Dietzsch:
Am Sonntag, dem 11.07.2021 um 12:11 +0200 schrieb Peter McD: Hallo Peter
Allerdings gefällt mir die Variante als root mit mount.crypt /dev/xyzN /mountpoint ein Laufwerk an einen beliebigen Mountpoint zu legen besser, der findet sich einfacher mit dem Dolphin. Das ist in diesem Fall genau so n i c h t praktikabel wie das mehrfach notwendige ausführen der Befehle systemctl start "Demon" und systemctl enable "Deomon", damit diese Dienste im Hintergrund laufen. Denn der Demon von Spamassassin z.B. überlebt grundsätzlich keinen Reboot des installierten openSUSE Systemes.
Hallo Florian, wenn er "grundsätzlich kein reboot überlebt" wie kommt es dann, dass spamassassin bei mir (derzeit 15.2) seit Jahren immer läuft und läuft und läuft .... Kann mich nicht erinnern wann ich das letzte mal ein "systemctl enable/start spamd" abgesetzt habe. Muss Jahre her sein...
Am Sonntag, dem 11.07.2021 um 15:59 +0200 schrieb Norbert Zawodsky: Hallo Norbert
wenn er "grundsätzlich kein reboot überlebt" wie kommt es dann, dass spamassassin bei mir (derzeit 15.2) seit Jahren immer läuft und läuft und läuft .... Kann mich nicht erinnern wann ich das letzte mal ein "systemctl enable/start spamd" abgesetzt habe. Muss Jahre her sein...
Der Rechner ist neu, komplett andere Hardware als der ~15 Jahre alte Vorgänger. Und die Installation ist demzufolge auch neu. Da geht es eben nicht. Weder die Aktvierung mit Yast. Noch die mit den Befehlen. -- FloriDie
Am Sonntag, dem 11.07.2021 um 15:59 +0200 schrieb Norbert Zawodsky:
und läuft .... Kann mich nicht erinnern wann ich das letzte mal ein "systemctl enable/start spamd" abgesetzt habe. Muss Jahre her sein...
Bei neu installierten (open)SuSE-Systemen ist das nach meiner Erfahrung immer wieder ein Problem. Vor allem der sapmd zickt hier schon seit mehreren Generation immer wieder rum. -- JUK
Am Samstag, dem 10.07.2021 um 17:14 +0200 schrieb Florian Dietzsch:
Wie geht das? Nach allem was ich mir zusammengesucht habe ist (sollte) das seit ungefähr 15 Jahren eigentlich nicht mehr so gemacht werden müssen.
Das sollte es auch nicht. Vermutung von meiner Seite, weil ich mich in diesem Zusammenhang mal in der LUG mächtig neben den Stuhl gesetzt habe: Hat der Rechner 2 Festplatten, die beide einzeln verschlüsselt sind? Im gerade genannten Fall konnte da eine weitere verschlüsselte Festplatte nicht mehr eingehängt werden. Das war damals glaube ich ein (open)SuSE der 13ner-Reihe, also schon länger her. -- JUK
Am Dienstag, dem 13.07.2021 um 15:52 +0200 schrieb Jan-Uwe Kögel: Hallo Jan-Uwe
Hat der Rechner 2 Festplatten, die beide einzeln verschlüsselt sind? Im gerade genannten Fall konnte da eine weitere verschlüsselte Festplatte nicht mehr eingehängt werden. Das war damals glaube ich ein (open)SuSE der 13ner-Reihe, also schon länger her.
Ja, das sind 2 SSD drin, die beide einzeln verschlüsselt sind. Was anderes machen hat die Bekannte sich nicht getraut. Wobei, ihr bei zu bringen die ihre Installation auf diese Art zu sichern, schon ein besonderer Akt war. -- FloriDie
Am Mittwoch, dem 07.07.2021 um 22:36 +0200 schrieb Bernd Nachtigall: Hallo Bernd
Evtl. klickst Du nicht auf das Icon rechts, sondern auf den ganzen Eintrag?
Ein klein wenig tüttelig (wie man hier in Mecklenburg das nennt) bin ich sicher. ;-) Aber so sehr nun auch wieder nicht. Inzwischen wurde auf dem Rechner Xfce als 2. Desktop installiert. Der macht zum Thema ebenfalls nicht was erwartet wird. Allerdings gibt es eine Fehler? Meldung, mit der ich leider nicht viel beginnen kann. 128 GB verschlüsselt konnte nicht eingehängt werden No object for D-Bus interface Für einen Transcend USB-A/USB-C Stick. 1,0 TB verschlüsselt konnte nicht eingehängt werden No object for D-Bus interface Für einen Eigenbau aus einer Intel NVMe-SSD in einem USB-C Gehäuse. Beide Speicher sind in Ordnung und funktionieren bei mir. -- FloriDie
Am 07.07.21 um 22:36 schrieb Bernd Nachtigall:
Am 07.07.21 um 18:14 schrieb Florian Dietzsch:
Hallo,
bei mir - Desktop Xfce - ist das Handling von verschlüsselten Festplatten/USB-Sticks/SD-Karten denkbar einfach. In den Rechner stecken, es erscheint ein Desktopicon, das anklicken, die Passwortabfrage (richtig) beantworten. Danach geht der Dateiverwalter Thunar auf, und gut ist. Nicht so mit KDE! Es erscheint zwar in dieser Geräteverwaltung ein "xxxGBit verschlüsseltens Laufwerk", wobei das Label der Festplatte/USB-Stick/SD-Karte schon mal ignoriert wird. Ein Klick auf diesen Eintrag bewirkt - nichts. Wie bekomme ich nun so einen Datenträger geöffnet?
"Hier" Leap 15.2 (KDE), ging es fast genauso. Datenträger anstecken; Die Geräteüberwachung geht auf und zeigt ein verschlüsseltes Laufwerk; Draufklicken; Passwort eingeben; Zugriff auf die Partition ist möglich.
Das:
Jetzt (Ich hatte das schon länger nicht mehr probiert) zeigt die Geräteüberwachung an das ich keine Berechtigung zum Einhängen des Gerätes habe. Im Dolphin ist die Partition(!) aber trotzdem zu sehen und zu bearbeiten. kenne ich auch. Hab's auch schon mal hier gepostet. Überhaupt scheint die Geräteüberwachung in KDE irgendwie nicht mehr so genau zu wissen, was sie tun soll.
- bei verschlüsselten Datenträgern wird die Berechtigung wie oben erwähnt 'angezweifelt', dann das Gerät aber richtig eingebunden. - (unverschlüsselte) SD-Karten werden bei mir grundsätzlich nur schreibgeschützt gemountet, es sei denn ich stecke sie in den Kartenleser, der in meinem USB-3-Hub integriert ist. - auf meinem Laptop ist's (bei gleicher Installation) noch bunter: Da werden verschlüsselte Datenträger erst eingebunden, wenn ich neben dem Entschlüsselungs-Passwort auch noch das Root-Passwort eingebe; sie sind dann aber dem User zugänglich. Übrigens nicht erst seit 15.2. Das mit den verschlüsselten Datenträgern kenne ich so schon von 15.0. Aber es scheint mit jeder neuen Version schlimmer zu werden, denn penetrant reproduziertbar schreibgeschütztes Einbinden von (unverschlüsselten) SD-Karten kannte ich vor 15.2 nicht. Alles sehr komisch... Gruß, Michael
Am Samstag, dem 10.07.2021 um 18:26 +0200 schrieb Michael Eschweiler: Hallo Michael
kenne ich auch. Hab's auch schon mal hier gepostet. Überhaupt scheint die Geräteüberwachung in KDE irgendwie nicht mehr so genau zu wissen, was sie tun soll.
Das Problem scheint nicht auf KDE beschränkt zu sein, denn mit dem parallel als Test installierten Xfce (auch mit einem neuen User) funktioniert das Montieren von verschlüsselten Festplatten/Sticks ja auch nicht. Zusätzlich tauchen immer mehr andere, lästige Fehler auf, wie das starten von Diensten als Demon beim hoch fahren des Rechners. Nach den überschwänglichen Lobesbekundungen in diversen einschlägigen Print- und Internetmedien hatte ich mehr erwartet. -- FloriDie
Hallo Michael, hallo zusammen, Am Samstag, 10. Juli 2021, 18:26:32 CEST schrieb Michael Eschweiler:
- auf meinem Laptop ist's (bei gleicher Installation) noch bunter: Da werden verschlüsselte Datenträger erst eingebunden, wenn ich neben dem Entschlüsselungs-Passwort auch noch das Root-Passwort eingebe; sie sind dann aber dem User zugänglich.
Das könnte mit den PolicyKit-Einstellungen zusammenhängen. Wenn Du das nächste Mal nach dem root-Passwort gefragt wirst, klappe im Dialog die Details auf und verrate die angefragte Berechtigung (vermutlich "org.freedesktop.irgendwas"), dann lässt sich das Problem lösen. Gruß Christian Boltz --
mit ist aufgefallen, dass die SPF Records von mailbox.org ungültige Parameter enthalten. Psssst, was erlauben Urban! :) Das ist ja fast wie Gotteslästerung! [> Urban Loesch und Django in postfixbuch-users]
Hallo Christian, Am 11.07.21 um 20:59 schrieb Christian Boltz:
Hallo Michael, hallo zusammen,
Am Samstag, 10. Juli 2021, 18:26:32 CEST schrieb Michael Eschweiler:
- auf meinem Laptop ist's (bei gleicher Installation) noch bunter: Da werden verschlüsselte Datenträger erst eingebunden, wenn ich neben dem Entschlüsselungs-Passwort auch noch das Root-Passwort eingebe; sie sind dann aber dem User zugänglich.
Das könnte mit den PolicyKit-Einstellungen zusammenhängen. Wenn Du das nächste Mal nach dem root-Passwort gefragt wirst, klappe im Dialog die Details auf und verrate die angefragte Berechtigung (vermutlich "org.freedesktop.irgendwas"), dann lässt sich das Problem lösen.
Habe flux auf Details geklickt und bekomme Folgendes zu sehen: Aktion: Mount a filesystem on a system device Kennung: org.freedesktop.udisks2.filesystem-mount-system Hersteller: The Udisks Project polkit.subject-pid: (vierstellige Zahl) polkit.caller-pid: (vierstellige Zahl) Hier mal das root-Passwort einzugeben ist im Übrigen zwar lästig aber verschmerzbar, da danach alles klappt. Die Klimmzüge, um SD-Karten an meinem Desktop-Rechner schreibbar einzubinden, finde ich da ungleich blöder, zumal der Gerätemanager nicht davon sagt. Nur wenn ich mit dmesg nachschaue, sehe ich, sie schreibgeschützt gemountet sind. WTF! Gruß, Michael
Hallo Michael, hallo zusammen, Am Montag, 12. Juli 2021, 19:53:08 CEST schrieb Michael Eschweiler:
Am 11.07.21 um 20:59 schrieb Christian Boltz:
Am Samstag, 10. Juli 2021, 18:26:32 CEST schrieb Michael Eschweiler:
- auf meinem Laptop ist's (bei gleicher Installation) noch bunter: Da werden verschlüsselte Datenträger erst eingebunden, wenn ich neben dem Entschlüsselungs-Passwort auch noch das Root-Passwort eingebe; sie sind dann aber dem User zugänglich.
Das könnte mit den PolicyKit-Einstellungen zusammenhängen. Wenn Du das nächste Mal nach dem root-Passwort gefragt wirst, klappe im Dialog die Details auf und verrate die angefragte Berechtigung (vermutlich "org.freedesktop.irgendwas"), dann lässt sich das Problem lösen. Habe flux auf Details geklickt und bekomme Folgendes zu sehen:
Aktion: Mount a filesystem on a system device Kennung: org.freedesktop.udisks2.filesystem-mount-system Hersteller: The Udisks Project polkit.subject-pid: (vierstellige Zahl) polkit.caller-pid: (vierstellige Zahl)
Hier mal das root-Passwort einzugeben ist im Übrigen zwar lästig aber verschmerzbar, da danach alles klappt.
Falls Du es trotzdem passwortlos willst, sollte folgende Zeile in /etc/polkit-default-privs.local helfen: org.freedesktop.udisks2.filesystem-mount-system auth_admin:auth_admin:yes Danach /sbin/set_polkit_default_privs ausführen, damit die Änderung wirksam wird.
Die Klimmzüge, um SD-Karten an meinem Desktop-Rechner schreibbar einzubinden, finde ich da ungleich blöder, zumal der Gerätemanager nicht davon sagt. Nur wenn ich mit dmesg nachschaue, sehe ich, sie schreibgeschützt gemountet sind. WTF!
Das ist seltsam[tm]. Blöde Frage: Ist der Schreibschutz-Schieber an der Karte in der richtigen Position? Gruß Christian Boltz -- NO' and 'YES' are short words which need long thoughts. Most of the troubles in life are the result of saying 'YES' too soon or 'NO' too late !!!
Hallo Christian, hallo in die Runde, Am 12.07.21 um 20:56 schrieb Christian Boltz:
Am Montag, 12. Juli 2021, 19:53:08 CEST schrieb Michael Eschweiler:
Am 11.07.21 um 20:59 schrieb Christian Boltz:
Am Samstag, 10. Juli 2021, 18:26:32 CEST schrieb Michael Eschweiler:
- auf meinem Laptop ist's (bei gleicher Installation) noch bunter: Da werden verschlüsselte Datenträger erst eingebunden, wenn ich neben dem Entschlüsselungs-Passwort auch noch das Root-Passwort eingebe; sie sind dann aber dem User zugänglich.
Das könnte mit den PolicyKit-Einstellungen zusammenhängen. Wenn Du das nächste Mal nach dem root-Passwort gefragt wirst, klappe im Dialog die Details auf und verrate die angefragte Berechtigung (vermutlich "org.freedesktop.irgendwas"), dann lässt sich das Problem lösen. Habe flux auf Details geklickt und bekomme Folgendes zu sehen:
Aktion: Mount a filesystem on a system device Kennung: org.freedesktop.udisks2.filesystem-mount-system Hersteller: The Udisks Project polkit.subject-pid: (vierstellige Zahl) polkit.caller-pid: (vierstellige Zahl)
Hier mal das root-Passwort einzugeben ist im Übrigen zwar lästig aber verschmerzbar, da danach alles klappt.
Falls Du es trotzdem passwortlos willst, sollte folgende Zeile in /etc/polkit-default-privs.local helfen:
org.freedesktop.udisks2.filesystem-mount-system auth_admin:auth_admin:yes
Danach /sbin/set_polkit_default_privs ausführen, damit die Änderung wirksam wird.
Das werde ich machen!
Die Klimmzüge, um SD-Karten an meinem Desktop-Rechner schreibbar einzubinden, finde ich da ungleich blöder, zumal der Gerätemanager nicht davon sagt. Nur wenn ich mit dmesg nachschaue, sehe ich, sie schreibgeschützt gemountet sind. WTF!
Das ist seltsam[tm].
JA!
Blöde Frage: Ist der Schreibschutz-Schieber an der Karte in der richtigen Position?
Keine blöde Frage, und die Antwort ist ja, habe ich mehrfach kontrolliert - man ist ja nie gefeit davor, dass sich der Schalter mal unbemerkt verschiebt, weil man damit irgendwo hängengeblieben ist. Gruß, Michael
Am 12.07.21 um 21:41 schrieb Michael Eschweiler:
Hallo Christian, hallo in die Runde,
Blöde Frage: Ist der Schreibschutz-Schieber an der Karte in der richtigen Position?
Keine blöde Frage, und die Antwort ist ja, habe ich mehrfach kontrolliert - man ist ja nie gefeit davor, dass sich der Schalter mal unbemerkt verschiebt, weil man damit irgendwo hängengeblieben ist.
Da kommt sofort die nächste Frage: Wäre es möglich, dass der Schieber defekt ist? Peter
Hallo Peter,
Blöde Frage: Ist der Schreibschutz-Schieber an der Karte in der richtigen Position?
Keine blöde Frage, und die Antwort ist ja, habe ich mehrfach kontrolliert - man ist ja nie gefeit davor, dass sich der Schalter mal unbemerkt verschiebt, weil man damit irgendwo hängengeblieben ist.
Da kommt sofort die nächste Frage: Wäre es möglich, dass der Schieber defekt ist?
Ja, auch diese Frage kann man sich stellen, aber die Antwort ist eindeutig NEIN: Ich habe es überprüft und das Phänomen tritt nicht nur bei einer SD-Karte auf. Ich habe mehrere, eine aus einer Kamera; eine aus einem alten Tablet, mit dem ich in der Garage Musik höre; eine aus einem alten E-Book-Reader; mehrere Micro-SD-Karten, die ich mit Adapter benutze; etc. - bei ALLEN ist das Ergebnis beim Mounten gleich: Jeder Schreibvorgang schlägt fehl und dmesg sagt: 'read-only'. Also aus meiner Sicht eindeutig kein Hardwarefehler oder -defekt. Gruß, Michael
Hallo Christian, Am 12.07.21 um 21:41 schrieb Michael Eschweiler:
Hallo Christian, hallo in die Runde,
Am 12.07.21 um 20:56 schrieb Christian Boltz:
Am Montag, 12. Juli 2021, 19:53:08 CEST schrieb Michael Eschweiler:
Am 11.07.21 um 20:59 schrieb Christian Boltz:
Am Samstag, 10. Juli 2021, 18:26:32 CEST schrieb Michael Eschweiler:
- auf meinem Laptop ist's (bei gleicher Installation) noch bunter: Da werden verschlüsselte Datenträger erst eingebunden, wenn ich neben dem Entschlüsselungs-Passwort auch noch das Root-Passwort eingebe; sie sind dann aber dem User zugänglich.
Das könnte mit den PolicyKit-Einstellungen zusammenhängen. Wenn Du das nächste Mal nach dem root-Passwort gefragt wirst, klappe im Dialog die Details auf und verrate die angefragte Berechtigung (vermutlich "org.freedesktop.irgendwas"), dann lässt sich das Problem lösen. Habe flux auf Details geklickt und bekomme Folgendes zu sehen:
Aktion: Mount a filesystem on a system device Kennung: org.freedesktop.udisks2.filesystem-mount-system Hersteller: The Udisks Project polkit.subject-pid: (vierstellige Zahl) polkit.caller-pid: (vierstellige Zahl)
Hier mal das root-Passwort einzugeben ist im Übrigen zwar lästig aber verschmerzbar, da danach alles klappt.
Falls Du es trotzdem passwortlos willst, sollte folgende Zeile in /etc/polkit-default-privs.local helfen:
org.freedesktop.udisks2.filesystem-mount-system auth_admin:auth_admin:yes
Danach /sbin/set_polkit_default_privs ausführen, damit die Änderung wirksam wird.
Das werde ich machen!
Das habe ich genauso gemacht (Eintrag mit copy-paste in die polkit* in die genannte Datei eingefügt) und Befehl ausgeführt. Im Ergebnis hat das leider einem unerwünschten Effekt: Danach wurde zwar das Root-Passwort nicht mehr verlangt, dafür aber immer wieder (wohl bei jedem Zugriff) das Passwort für kwallet. Das ist ja noch lästiger... Hab's jetzt erst einmal wieder zurückgesetzt. Gruß, Michael
participants (8)
-
Bernd Nachtigall -
Christian Boltz -
Florian Dietzsch -
Jan-Uwe Kögel -
Michael Eschweiler -
michael.eschweiler＠web.de
-
Norbert Zawodsky -
Peter McD