Orte in den Systemeinstellungen werden nach Neustart bei 2 verschlüsselten Festplatten zurückgesetzt

Other Languages Deutsch
, ,
1

Ich habe 2 mit luks verschlüsselte Festplatten. Auf der ersten ist das Betriebssytem, auf der 2. meine Daten.
Nach der ersten Eingabe des Passwortes beim Booten / Neustart wird die erste Festplatte freigegeben. Dann kommt eine Fehlermeldung “failed to load key file” und anschließend die Aufforderung zur Eingabe des Passwortes für die 2. Festplatte. Gebe ich erneut mein PW ein, dann wird auch die 2. Festplatte gebootet und das System startet ganz normal.

Seitdem ich meine Festplatten jedoch verschlüsselt habe, werden die “Orte” unter den Systemeinstellungen immer wieder von meinen eigens angelegten Pfaden zurückgesetzt auf:
“/home/rulinux/”. Meine eingestellten Pfade sind verloren.
Ich vermute der Fehler liegt im “Laden” oder Einbinden der verschlüsselten Festplatten.

Ich habe schon einmal eine Fehlermeldung unter https://bugs.kde.org/show_bug.cgi?id=444787#c5 aufgegeben. Die finale Antwort, ich solle mich an das Manjaro Forum wenden. Und da bin ich jetzt.

4

Verstehe ich das richtig? Du mountest (wahrscheinlich) in ‘/etc/fstab’ deine Datenpartition nach ‘/run/media/rulinux/data-drive’.

Der Inhalt der Datenpartition wird dir aber in deinem Home-Verzeichnis angezeigt?

Ich kenn mich mit KDE und Dolphin nicht aus. Daher verstehe ich uU deine Anfrage nicht richtig.

Ich würde aber an deiner Stelle erstmal nachsehen ob die Platte dort gemountet wird wo du sie gemountet haben willst. Mountest du die Platte den über ‘/etc/fstab’ oder wird die irgendwie nach deinem login eingebunden?

5

Das hört sich mir nach einem Automount Problem an.
Bist du sicher, dass dein zweiter Cryptsetup automounted wird und nicht nur der Pfad einer nicht gemounteten Partition versucht wird zu mounten?

Es ist sinnvoller, die zweite Festplatte automatisch entschlüsseln zu lassen, wenn die erste erfolgreich entschlüsselt wurde und anschließend automatisch zu mounten.

Dafür kann ich folgende Anleitung empfehlen: https://kifarunix.com/automount-luks-encrypted-device-in-linux/
Falls du der Anleitung folgst: Bevor du rebootest, solltest du unbedingt Crypttab testen:

sudo cryptsetup -v luksClose luks-<uuid>
sudo systemctl daemon-reload
sudo systemctl restart cryptsetup.target
6

Danke Dir. Ich habe es mir mal angesehen. Aber gibt es da nicht doch noch eine deutlich einfachere Lösung? Es kommt ja beim Booten der 2. Festplatte immer zuerst die Meldung “could not load key file”. Demnach müsste es doch irgendwie möglich sein, einen Keyfile geeignet auf dem Boot device zu hinterlegen auf den dann “die 2. Festplatte zugreifen” können sollte!!??

7

Ja das geht. Man kann jeder Luks-Partition (ich glaube es waren) 7 Passwörter hinzufügen. Dabei ist es egal ob das Passwort eingeben wird oder aus einer Keyfile kommt. Mit jedem der gespeicherten Passwörter kann die Partition entschlüsselt werden.

Dazu wird zb in ‘/’ eine keyfile erstellt. Dann kannst du in der Datei ‘/etc/crypttab’ die Partition mit der passenden keyfile laden.
Und danach kannst du sie auch direkt per ‘/etc/fstab’ an beliebiger Stelle mounten.

Ich dächte im alten deutschen Forum gabs mal eine Anleitung nachder ich das damals gemacht habe.
Ich schaue mal ob ich da nochwas finde … :grinning:

P.S. Wenn du Manjaro mit mehreren verschlüsselten Partitionen installierst erstellt es glaub ich ehe eine keyfile ( /crypto_keyfile.bin ). Kannst ja mal schauen, ob da schon was da ist bei dir. :laughing:

8

Danke! Ja, eine solche Datei habe ich gefunden unter /crypto_keyfile.bin

Eine klare und einfache Anleitung zur “Freigabe” der 2. Daten-Festplatte wäre super, weil ich das ansonsten nicht hinbekomme!

9

Kannst du dann bitte nochmal den output von ‘lsblk’ posten.

lsblk
10

Hier, gerne.

NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    0 941,5G  0 disk  
└─sda1                                          8:1    0 941,5G  0 part  
  └─luks-b42ed99c-c77v-9834-85df-7864dsfgsdg2 254:2    0 941,5G  0 crypt /run/timeshift/backup
                                                                         /run/media/rulinux/Daten-Linux
nvme0n1                                       259:0    0 228,5G  0 disk  
├─nvme0n1p1                                   259:1    0   300M  0 part  /boot/efi
├─nvme0n1p2                                   259:2    0 202,5G  0 part  
│ └─luks-b95c2af0-3c16-4bca-b214-68521hklk333 254:0    0 202,5G  0 crypt /home
│                                                                        /var/log
│                                                                        /var/cache
│                                                                        /
└─nvme0n1p3                                   259:3    0  25,7G  0 part  
  └─luks-59c3ed2e-550d-46ff-b870-98732154b28b 254:1    0  25,7G  0 crypt [SWAP]
11

Um mit der Verschlüsselung zu arbeiten gibts das Programm ‘cryptsetup’.
Mit ‘cryptsetup --help’ und ‘man cryptsetup’ gibt es auch ne gute Übersicht über die verfügbaren Funktionen. :grin:

Am besten du schaust dir die Header deine Verschlüsselung an. Damit kannst du auch prüfen wieviel Passwörter für diese Partition gespeichert sind. Das geht mit folgendem Befehl:

sudo cryptsetup luksDump /dev/sda1
sudo cryptsetup luksDump /dev/nvme0n1p2

Bitte die Ausgabe der beiden Befehle hier NICHT posten, da Sie Daten zu deiner Verschlüsselung enthalten!

Wenn du dir die Ausgaben beider Befehle ansiehst, sollte zumindest bei den "Key Slot"s ein unterschied sein. Ich nehme an das bei dir bei ‘/dev/sda1’ nur ein “Key Slot” auf ‘ENABLED’ steht (wahrscheinlich ‘Key Slot 0’), welcher das Passwort speichert was du beim booten eingibst.
Bei ‘/dev/nvme0n1p2’ gehe ich davon aus das 2 "Key Slot"s auf ‘ENABLED’ stehen. Der eine “Key Slot” enthält das Passwort was du zuerst beim booten eingibst und das andere wahrscheinlich die keyfile (/crypto_keyfile.bin).

Beim booten wird die Datei ‘/etc/crypttab’ geprüft und die unter UUID genannte Partition mit dem gespeicherten Passwort entschlüsselt und als entschlüsseltes Gerät unter ‘/dev/mapper/luks-UUID’ bereitgestellt. Das in ‘/etc/crypttab’ gespeichert Passwort kann auch eine Passwortdatei sein wie zb ‘/crypto_keyfile.bin’

So könnte deine ‘/etc/crypttab’ aussehen:

/etc/crypttab 
luks-b42ed99c-c77v-9834-85df-7864dsfgsdg2 UUID=b42ed99c-c77v-9834-85df-7864dsfgsdg2     /crypto_keyfile.bin luks
luks-b95c2af0-3c16-4bca-b214-68521hklk333 UUID=b95c2af0-3c16-4bca-b214-68521hklk333     /crypto_keyfile.bin luks
luks-59c3ed2e-550d-46ff-b870-98732154b28b UUID=59c3ed2e-550d-46ff-b870-98732154b28b     /crypto_keyfile.bin luks

Bitte prüf das mal ob Sie 3 Einträge wie oben hat oder nur 2. Ich hab jetzt die UUIDs der Festplatten aus deinem ‘lsblk’ post genommen. Falls du die UUIDs aus irgendwelchen Gründen vor dem posten geändert hast musst du sie ggf noch anpassen.

Wenn nur 2 Einträge in ‘/etc/crypttab’ drin sind (also nur für / und swap) musst du den dritten für deine Datenplatte noch mit einfügen.
Das währe dann dieser hier(ober der erste):

luks-b42ed99c-c77v-9834-85df-7864dsfgsdg2 UUID=b42ed99c-c77v-9834-85df-7864dsfgsdg2     /crypto_keyfile.bin luks

Wenn du nur 2 drinnen stehen hast ändere an den 2 Einträgen nichts, nur den neuen unten dran.

Jetzt musst du deiner Datenplatte noch den (in /crypto_keyfile.bin gespeicherten) Schlüssel hinzufügen.
Das geht mit folgendem Befehl:

sudo cryptsetup luksAddKey /dev/sda1 /crypto_keyfile.bin

Achtung! Bei dem Befehl musst du dann 2 Passwörter eingeben. Erst dein Nutzerpasswort für das ‘sudo’ und danach sollte es dich noch nach dem Verschlüsselungpasswort fragen, das was du beim booten für deine Datenplatte angibst.
Kurz gesagt du kannst einer luks-partition nur neue Schlüssel hinzufügen wenn du wenigstens einen Schlüssel kennst.

Wenn das gemacht ist sollte deine Datenplatte beim booten automatisch entschlüsselt werden, so das du kein Passwort während des bootens mehr eingeben musst … nur noch das eine beim starten.

Die Platte sollte dann in deinem Dateimanager zu sehen sein und beim “draufklicken” auch wieder unter ‘/run/media/rulinux/data-drive’ gemountet werden.

Wenn du die Platte dann doch woanders und automatisch gemountet haben möchtest kannst du sie dann noch in ‘/etc/fstab’ eintragen. In ‘/etc/fstab’ sollte auch schon ein Eintrag für ‘/’ drin sein, an dem du dich orientieren kannst. :slightly_smiling_face:

Beim arbeiten mit Verschlüsselten Platten ist es auch nie verkehrt ein Backup des Headers zu machen falls irgendwas mal den Anfang deiner Platte überschreibt. Das kannst du damit machen:

cryptsetup luksHeaderBackup /dev/sda1
cryptsetup luksHeaderBackup /dev/nvme0n1p2

… So ich hoffe ich hab jetzt alles nötige erklärt. Wenn du unsicher bist oder noch etwas unklar frag ruhig nochmal. :grinning:

12

Danke Dir Kisun, für Dir sehr präzise Erklärung, die ich versuche nachzuvollziehen.

Ich hatte seit meinem letzten diesbezüglich Beitrag eine Systemaktualisierung durchgeführt, anschließend ein Kernelupgrade von 5.13 auf 5.15. Das funktionierte noch. Dann habe ich eine erneute, anfallende Systemaktualisierung mit Neustart durchgeführt. Es wurde mir als Login-Bildschirm “Kodi” (!!!) zum Login angezeigt. Nach meinem User Login bin ich auf dem Kodi-Media-Player gelandet. Ich konnte dann nicht mehr weiter auf mein System zugreifen!!! Vollkommen unverständlich ist das. Ich hatte nur einmal Kodi aus pamac zur Probe installiert und wieder installiert. Mehr nicht. Leider hat Manjaro die Schwäche, dass es installierte Programme nie mehr auch sauber deinstalliert. Das ist sehr schlecht. Vielleicht hat es damit zu tun. Vielleicht kommt der Fehler auch ganz woanders her.

Dann wollte ich mit einem aktuellen Live-Boot-Stick mein System mit timeshift wiederherstellen. Das funktioniert auch nicht. Timeshift funktioniert nicht richtig beim Backup mit verschlüsselten Festplatten sehr schlecht. Mir blieb nur noch übrig, mein System neu mit Kernel 5.15 komplett zu installieren, auch mti verschlüsselten Festplatten. Zum Glück konnte ich meine “home” Verzeichnis aus den timeshift Ordner in das neue System retten. Alle Programme musste ich natürlich neu installieren.

Beim erneuten Booten kommt im Bootvorgang jetzt nur noch einmal die Aufforderung zur Eingabe meines Luks-Festplatten-Passworts vor. Ist das System komplett gebootet, dann erscheint ein Pop-Fenster, mit meinem, bereits vorausgefüllt beim Booten eingegebenen Passwort. Ich drücke einfach auf “Ok” und die 2. Daten Festplatte ist freigegeben. Offenbar haben die Entwickler da schon etwas verbessert.

Mein Ursprungsproblem “Orte in den Systemeinstellungen werden nach Neustart bei 2 verschlüsselten Festplatten zurückgesetzt” ist jedoch weiterhin existent.

Ich habe Deinen Befehl ausgeführt.

Das Ergebnis ist sinngemäß wie Du angenommen hast. Es sind bei
‘/dev/sda1’ 2 “Key Slot”s auf ‘ENABLED’ und bei ‘/dev/nvme0n1p3’ 1 “Key Slot” auf ‘ENABLED’. '/dev/nvme0n1p3’ ist jetzt offenbar die swap-partition. '/dev/nvme0n1p2’ ist jetzt meine OS Partition. Leider habe ich in der “Rettungseile” nicht gemerkt, dass diese dummerweise jetzt in ext4 formatiert. Na ja, Pech gehabt.

lsblk

hat jetzt ein anderes Ergebnis. Vermutlich durch die Neuinstallation. Ich habe die Daten-Partition /dev/sda1 bei der Neuinstallation nicht angefasst. In KDE Partitionsverwaltung wird meine Datenpartion /dev/sda als verschlüsselt angezeigt (btrfs). Die OS-Partition mit der ‘/dev/nvme0n1p3’ (Swap) jedoch als LUKS verschlüsselt angezeigt. Die ‘/dev/nvme0n1p3’ (ext4) mit dem OS nur einfach als verschlüsselt angezeigt. Eigentlich müsste doch alles LUKS verschlüsselt sein, aber es wird nicht so angezeigt. Vielleicht ist da auch etwas schief.

NAME               MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                  8:0    0 900G  0 disk  
└─sda1               8:1    0 900G  0 part  
  └─sda1_crypt     254:1    0 900  0 crypt /run/timeshift/backup
                                              /run/media/omlinux/Daten-L
nvme0n1            259:0    0 238,5G  0 disk  
├─nvme0n1p1        259:1    0   300M  0 part  /boot/efi
├─nvme0n1p2        259:2    0 200G  0 part  
│ └─luks-xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
│                  254:0    0 200G  0 crypt /
└─nvme0n1p3        259:3    0  25G  0 part

und

sudo nano /etc/crypttab

ergibt bei mir jedoch nur 1 Eintrag statt eigentlich 3!!!

 luks-xxxxxxxxxxxxxxxxxxxxxxxx UUID=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy>

Auch hier meine Frage. Welche UUID ist das? In dem Programm KDE-Partitionsverwaltung findet sich diese UUID unter den Eigenschaften der betreffenden Partition nicht!!! Welche sollte ich dann jeweils nehmen, wenn die eine unter lsblk gar nicht mit der unter der KDE-Partitionsverwaltung übereinstimmt? Auch finde ich die LUKS-ID unter /etc/cryptab nirgendwo anders wieder, so dass ich diese für die 2 weiteren Einträge gar nicht eintragen kann.

Also von einer Lösung bin ich noch entfernt, noch weiter von der Lösung meines Ursprungsproblems.

Vielleicht muss ich alles “richtig” neu installieren und ‘/home’ und ‘/’ einfach danach löschen und das backup draufkopieren. Aber der Installer von Manjaro hat auch diverse Probleme mit der Installation eines verschlüsselten Systems mit 2 Festplatten.

Was nun??

13

Hallo @Rulinux, da hast du ja was durch. :frowning_face:

Ich kenn die KDE-Partitionsverwaltung leider nicht aber die Sache mit den unterschiedlichen UUIDs ist eigentlicht leicht erklärt.
Die luks UUID ist die UUID der verschlüsselten Platte welche eine art Container ist. Da der Inhalt der verschlüsselte Platte ja normal nicht lesbar ist kann man auch von außen nicht sehen welche Partitionen in diesem Container sind. Die KDE-Partitionsverwaltung zeigt dir wahrscheinlich nur die UUIDs der inneliegenden Partition(en) an.

‘gparted’ zB zeigt dir auch die luks-UUID an.

Auch die Befehle

sudo cryptsetup luksDump /dev/sda1
sudo cryptsetup luksDump /dev/nvme0n1p2

zeigen dir die luks-UUID bei UUID an.

Nach der Neuinstallation hast du ja bestimmt auch eine neue ‘/crypto_keyfile.bin’. Du kannst ja das immer noch genauso wie beschrieben machen.

Also mit

sudo cryptsetup luksAddKey /dev/sda1 /crypto_keyfile.bin

der ‘sda1’ den neuen Schlüssel aus der ‘keyfile’ hinzufügen. Dann mit

sudo cryptsetup luksDump /dev/sda1

oder

sudo cryptsetup luksDump /dev/sda1 | grep UUID

die (luks) UUID von ‘sda1’ ermitteln. Sieht dann vielleicht so aus:

UUID: aaaabbbb-aaaa-bbbb-aaaa-bbbbaaaabbbb

Jetzt nochmal die ‘/etc/cryptab’ mit

sudo nano /etc/crypttab

anpacken und die Zeile für ‘sda1’ dazupacken. Die sollte dann so ausehen (die Zeile :grinning:):

luks-aaaabbbb-aaaa-bbbb-aaaa-bbbbaaaabbbb UUID=aaaabbbb-aaaa-bbbb-aaaa-bbbbaaaabbbb     /crypto_keyfile.bin luks

Bei der Zeile Oberhalb halt noch die UUID anpassen, mit der die du ausgelesen hast. Dann sollte wie vorher schon besprochen die Platte beim booten entschlüsselt werden.

Der erste Teil ( luks-aaaabbbb-aaaa-bbbb-aaaa-bbbbaaaabbbb ) in der ‘/etc/crypttab’ ist auch bloß der Bezeichner. Unter dem Namen findet man dann auch die entschlüsselten Platten unter ‘/dev/mapper/’ und kann sie von dort auch wie normale Laufwerke mounten.

Du kannst das ja gern nochmal probieren wenn du magst und berichten. :grinning:

14

Endlich habe ich wieder etwas Luft für dieses Problem.

und den weiterführenden Erklärungen konnte ich Deine Ausführungen umsetzen, so dass ich das Passwort für die Daten-Festplatte /dev/sda1/ weder eingeben oder (mit dem neuen Kernel 5.15) auch noch nicht einmal mehr bestätigen musste. Danke Dir soweit, Kisun.

Doch das eigentliche Problem, dass die Einstellungen der Orte in den Systemeinstellungen, die auf Pfade der 2. Festplatte mit meinen Daten verweisen, immer wieder beim Neustart zurückgesetzt werden, ist nicht gelöst.

Beim Booten erscheint weiterhin die Fehlermeldung “could not open keyfile” oder so ähnlich. Offenbar wird die 2. Festplatte beim Booten nicht gleich erkannt, sondern erst viel später, da sie verschlüsselt ist. In der Folge setzt Manjaro die Einstellungen für die Orte einfach zurück auf /home/rulinux/

Es sollten zumindest die Einstellungen nicht einfach schon beim Booten zurückgesetzt werden, wenn es überhaupt sein muss. Vielleicht erst, wenn das System nach dem Booten die Standardverzeichnisse immer noch nicht findet und man diese aufruft, wäre ein “Reset” der Pfade vertretbar.
So aber nicht!! Das müsste an die Programmierer weitergeben werden!!

Eine vollumfängliche Lösung wäre, dass die Einstellungen generell nicht zurückgesetzt werden. Ist der Pfad für die Standardorte bei Aufruf im fertig gebooteten Zustand weiterhin nicht verfügbar, dann sollte man zu den Systemeinstellungen zu “Orte” weitergeleitet werden. Das wäre dann “idiotensicher” aus meiner Sicht.

15

Hast du den schon mal den Update Service der “xdg-user-dirs” deaktiviert? Der Service läuft immer nachdem du dich einloggst. Das Manual ist sehr klar darin, wann ein Pfad zurück gesetzt wird.

any configured directories that point to non-existing locations are reset by pointing then to the users home directory.

Ich würde dir aber davon abraten den Service zu deaktivieren.
Die wichtige Frage zur Lösung deines Problems ist aber, welchen Pfad verwendest du zum mounten deiner Festplatte und wie genau machst du das? Explizit gesagt hast du das noch nicht, aber nach den lsblk Ausgaben könnte man auf die Idee kommen du verwendest /run/media/ .

Falls das zutrifft, ist es klar das warum der Update Service die Orte nicht findet. /run/media/ ist so ziemlich der falscheste Ort für das Einhängen von Partition den du dir aussuchen kannst. /run/media/ ist für Programme die temporäre Mounts erstllen wollen. Wie z.B. dein Dateimanager, wenn du einen USB Stick mounten möchtest. Oder auf wenn du eine Partition aus deinem System mounten möchtest, aber das nur manchmal temporär durch einen Dateimanager machen willst.

/run/media/ ist aber nicht für fest Mounts geeignet die immer benötigt werden. Zum Zeitpunkt von Mounts aus z.B. der /etc/fstab ist dein persönlicher temporärer /run/media/rulinux Ordner noch gar nicht existent. Der wird immer erst beim Einloggen angelegt und nach dem Ausloggen wieder gelöscht. (Außer du fummelst vorher ganz eklig im Dateisystem rum.)

Falls du natürlich deinen Datei Manager verwendest und nach jedem einloggen den Dateimanager verwendest um diese Partition zu mounten, ist auch klar das du keine der Ordner auf dieser Partition in “xdg-user-dirs” verwenden kannst, da sie beim Einloggen einfach noch nicht existieren.

Wenn du weiterhin glaubst das es sich um einen Bug handelt, sollte du bei freedesktop Projekt einen Burgreport erstellen.
xdg-user-dirs
Issues · xdg / xdg-user-dirs · GitLab

16

Ja, Xabbu, Deine Vermutung ist richtig. Der Pfad zu meiner integrierten Daten-Festplatte ist:
/run/media/omlinux/Daten-Linux/
Zum NAS, das ich über fstab umständlich eingebunden habe ist der Pfad.
/mnt/samba/Multimedia/…
Zumindest funktioniert es. Aber gibt es da eine einfache Einbindungsmöglichkeit über Dolphin, ohne kompliziert in der fstab fummeln zu müssen?
Weißt Du zufällig wie ich einen Ordner auf meinem Rechner für mein Home-Netzwerk freigeben kann? Ansonsten recherchiere ich und mache ggf. noch ein eigenen Fall auf.

Offenbar sollte ich /run/media/ also nur für (temporäre) externe Festplatten, USB-Sticks etc. verwenden!!

Welchen Pfad sollte ich den für die Daten Festplatte wählen?
Wie sollte ich den Pfad (Einhängepunkt) meiner verschlüsselten btrfs Daten-Festplatte möglichst problemarm mit allen sonstigen Nebenänderungen am besten ändern? Über KDE Partitionsverwaltung oder gparted? Einfach aushängen und Einhängenpunkt ändern?

Das wirkt sich natürlich auf auch Pfade meiner Virtualbox aus. Aber vermutlich und hoffentlich muss ich dann die VBox-Machine einfach nur neu öffnen und sie hat dann den neuen Pfad.
Auch habe ich manche Anwendungsdateien auf der Daten-Partition liegen, z.B. auch meine Thunderbird-Anwendungsdaten wie Mails. Es reicht vermutlich diese in TB in den Konten direkt zu ändern.

Es ist schon übel, dass es mit den Installations-Manager von Manjaro nicht möglich war, Manjaro KDE mit 2 getrennten, verschlüsselten Festplatten zu installieren. Geschweige denn, dass ich ein eigenes, dynamisches Subdirectory mit btrfs für das home Verzeichnis anlegen konnte. Manuelles Anlegen von Partitionen im Installationsmanager, dass recht unübersichtlich ist, geht nur bei unverschlüsselter Installation. Also das ist alles andere als eine “idiotensichere” Installationsroutine.

Noch zur user-dirs.conf

/etc/xdg/user-dirs.conf

zeigt an:

enabled=True
enabled=True

Ich habe ihn erst einmal nicht deaktiviert, da Du davon abrätst.

Danke Dir für Deine weitere Hilfe, Rulinux

17

Mich würde interesieren wie du das bisher machst. Klickst du bei jedem Starten deines Systems im Dateimanager auf die Partition?

Das wäre gut.

Das kommt auf deinen Geschmack an. Viele bevorzugen /media, andere /mnt oder direkt nach / . Wenn du der einzige menschliche Benutzer auf deinem System bist, kann auch /home/omlinux/Daten-Linux eine gute Option sein. Oder anders, alles ist besser als /run .

Der Einhängepunkt hat erstmal nichts mit der Partition an sich zu tun. Daher meine Frage wie machst du das den bisher? So ganz konkret.

Naja, ist vielleicht ein bisschen hart, aber Idioten installieren kein verschlüsseltes System. Und wenn doch, dann reicht auch der Standard.

18

Also für NAS hatte ich das schon vor längerer Zeit über fstab gelöst, leider war es sehr aufwendig. Aber meine Frage war, ob das auch einfacher über Dolphin geht?

Unter Einhängepunkt, so wie er zumindest in der KDE Partitionsverwaltung beschrieben wird, findet sich genau der Pfad, den Du bemängelst:
/run/media/omlinux/Daten-Linux/
Als Pfad wird dort angegeben: /dev/sda1/
Ich glaube da ist die Nomenklatur nicht eindeutig.

Da bin ich anderer Meinung. Je einfacher der Zugang zu Linux ist, desto erfolgreicher wird es sicher auch durchsetzen und halt umgekehrt auch!
“Einfachheit ist die höchste Form der Kunst” - auch im Programmieren & bei Software

19

Hier ist der wichtigste Punkt, welcher Pfad wird beim Booten einer 2. Festplatte problemlos unmittelbar im Bootvorgang erkannt - ohne all die genannten Probleme mit “/run/media/rulinux/Daten-Linux/”?

/mnt/Daten/ oder
/media/Daten/

Bzw. was ist der Standard, wenn es einen gibt?

20

Naja, bei der Installation einfach den Hacken bei “Verschlüssele System” setzten und ein Passwort auswählen. Einfacher geht es nun wirklich nicht.

Du möchtest halt nicht einfach, sondern individuell. Das ist dann leider nicht mehr immer einfach. Besonders da individuell bei jedem anders ist. Ist aber etwas off topic.

Einen wirklichen Standard gibt es nicht. Es gibt zwar den " Filesystem Hierarchy Standard" der Linux Foundation, aber der ist schon etwas älter und nicht bindend. Da es sich eigentlich auch nicht um " removable media" handelt, kann es überall hin gemountet werden. Es sollte(muss) nur ein Pfad sein, den es beim starten gibt. Also nicht in ein tmpfs wie /run oder /tmp . Manche Filemanager zeigen Ordner in /media/ prominenter an. Das kann gewünscht sein oder auch nicht.

21

Dateisystem-Hierarchie-Standard

Dort steht:

/mnt
Vorübergehend gemountete Dateisystem
/media
Einhängepunkte für Wechselmedien wie CD-ROMs

/dev
Gerätedateien (zB /dev/null, /dev/disk0, /dev/sda1, /dev/tty, /dev/random).|
Hostspezifische systemweite Konfigurationsdateien

…mmh?

22

https://wiki.archlinux.de/title/Mounten