Eigene fstab-Datei verstehen

[Thorakon]

Hallo,

ich muss ggf. in naher Zukunft die fstab Datei editieren um eine interne NTFS-Datenaustausch-Partition beim Systemstart von Kubuntu einzubinden. (Aktuell klappt es irgendwie doch grad wieder über KDE GUI-Tools zur Medienverwaltung scheint mir, aber es funktionierte die Tage davor nicht zuverlässig).

Bevor ich das mache, würde ich gern verstehen, was jetzt schon drin steht (ohne direkten Eingriff von mir) - und bei einem Eintrag bin ich unsicher, was der zu bedeuten hat.

Warum gibt es den Eintrag in Zeile 14 zu /dev/nvme1n1p2 - ntfs, und bewirkt er irgendwas? Wird diese Partition nicht von meiner Linux-Homepartition mit ext4 ausgefüllt? Vgl. fstab Zeile 8/9 und Output von Befehl blkid:

/dev/nvme1n1p2: UUID="a246a642-6c05-4053-a721-b5b4234e2133" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7c7781ec-9eba-4a90-a3d4-f8ecbf30ae7a"

Hintergrundinfos:
Ich verwende ein Dual-Boot mit Win 11 und Kubuntu 24.04 auf getrennten SSDs, Kubuntu wurde zuerst installiert. Die Win-Systempartition will ich absichtlich nicht unter Linux sehen. Auf jeder SSD liegt noch eine NTFS-Datenaustauschpartition. Siehe die Screenshots aus der Partitionsverwaltung.

Vielen Dank vorab für eure Hilfe.
Beste Grüße
Thorakon

 

[GrillSgt]

Das kann ich jetzt so nicht stehen lassen 😏.
Die Änderung war Ende der Nuller Jahre,

Das stimmt, aber na ja, wenn ich von früher rede, meine ich eher 20 - 25 Jahre

Defacto werden Systeme, wenn die Hardware nicht gewechselt wurde, in den meisten Fällen die Zuordnung der Gerätepfade Konsistent über mehrere Bootvorgänge identisch durchführen.

Denkt man so. Schon unter ESXi erlebt, dass nach einem Reboot die Zuordnung nicht mehr stimmte. Nach einem Weiteren dann jedoch wieder korrekt gewesen ist.

 

[rgbs]

Wenn also jemand wirklich feststellt, das seine 5 Geräte bei jedem Boot wahrlos gewürfelt werden, hätte einen extremen Fall, der auf Schäden am Mainboard, am PSU oder an der Mehrzahl der Geräte hinweist.

Wenn das nur nur hin und wieder mit einzelnen Drehern passiert, ist das ganz normal und kann schon an minimaler Korrosion am Mainboard oder in Abhängigkeit von Temperatur oder Luftfeuchtigkeitsunterschieden auftreten.

Die Frage, welche sich Gretchen stellt, ist ja, wo will man die Grenze ziehen?
Ich kann nur aus meiner Erfahrung mit zwei Boards berichten, da ist das schon seit Jahren so, dass nicht reproduzierbar die NVMEs manchmal die Plätze tauschen.
Es gibt halt auch Zufälle, da muss man dann nicht unbedingt die Quantentheorie bemühen.

Gruß
R.G.

 

[kieleich]

früher = bei IDE

da hatte man einen controller und hda, hdb, hdc, hdd (master slave strang 0, master slave strang 1) war fest.

bei sata konnten sich die bezeichner schon immer ändern und usb noch dazwischen

bei nvme eben auch noch weiter so

aber was früher war interessiert ja nicht, stand heute ist es gefährlich was anderes als UUID

da sind keine Schäden im Spiel das funktioniert einfach so der Linux Kernel ordnet das nicht fest zu

wer immer die gleichen Buchstaben / Nummern bekommt. Der hat einfach GLÜCK. Oder eben ein laufwerk das immer schnell antwortet und eins das immer langsam ist so das die nicht gegeneinander konkurrieren

 

[rgbs]

da sind keine Schäden im Spiel

Eben, denn dann wäre es reproduzierbar.

Gruß
R.G.

 

[Thorakon]

Danke für die vielen Rückmeldungen und die immer aufschlussreichen Diskussionen hier im Unterforum.
Auskommentieren von Zeile 14 hat geklappt und auch einen reboot überlebt. Das Eingangsproblem ist also erledigt.
-----------------
Jetzt hätte ich aber eine Folgefrage, deren Lösung vermutlich ein neuer Eintrag in der fstab ist:
Aktuell wird die große NTFS-Partition "Daten" unter "/media/User/Daten/" eingebunden. Eigentlich habe ich in der Verwaltung für Wechselmedien bzw. der KDE-Partitionsverwaltung festgelegt, dass das automatisch passiert beim Start, aber heute hat es (anders als gestern) tatsächlich mal wieder nicht geklappt. Das ist lästig, da z.B. der Syncthing Dateiabgleich mit den Handy dann nicht funktioniert, bis ich die Partition im Dolphin manuell einbinde.
Nun habe ich schon etwas recherchiert gestern, es scheint wohl den "mount"-Befehl zu geben und den "udisksctl"-Befehl. Für "udisksctl" scheint man sich auch noch Gedanken über den Treiber machen zu müssen. Scheinbar gibt es unter (K)Ubuntu ntfs3, ntfs-3 (Standard?) und ntfs (alt, als Fallback)?
In den Anleitungen gibt es zudem teils Beispiele, wo direkt als "/media/Daten/" eingebunden wird, statt wie bei mir aktuell mit "User" dazwischen. Ich würde -wenn es möglich und sinnvoll ist- gern beim Pfad "/media/User/Daten/" bleiben, denn einige Programme arbeiten schon damit, dann muss ich nicht soviel umkonfigurieren.
Wie binde ich also am besten meine NTFS "Daten" Datenaustauschpartition beim Systemstart ein?
Info zur UUID:

/dev/nvme1n1p4: LABEL="Daten" BLOCK_SIZE="512" UUID="063AC34F3AC33A87" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="cb24ff94-46ed-4d9e-84
a2-01afb32e52b7"

Vorschlag, angelehnt an Post #10 und ubuntuusers.de:
UUID="063AC34F3AC33A87" /media/User/Daten/ ntfs-3g auto,users,windows_names,nofail 0 0

Ich habe gelesen, das mit locale und utf8 ist nicht mehr nötig. Auf meinem System gibt es nur einen Linux-Nutzer, dann muss ich nicht mit uid, gid oder umask etwas festlegen, oder?
----------------------

Nun noch kurz zu den anderen Posts um eure Neugier zu stillen:

Es steht in der fstab doch explizit drin.
/ was on ..... during installation

Naja, da steht leider eben "was on" obwohl es immer noch so IST. Deshalb wollte ich mich darauf nicht blind verlassen.

Der Schnellstart in Windows wurde deaktiviert?

Ja, darauf wurde zum Glück oft genug hingewiesen. Mein Rescuezilla würde sonst auch das Backup abbrechen.

Zeile 15 würde ich drin lassen, da wird die Windows Partition auf der Kingston über "noauto" auf nicht automatisch einhängen und mit "ro,users" auf nur lesend einbinden gestellt, falls du diese doch irgendwann mal mounten willst, das ist wohl von der GUI der Medienverwaltung.
Das kann nicht schaden.😏

Jo, der Eintrag stammt auch aus einer Aktion von mir, evtl. in der grafischen Partitionsverwaltung (im Installer kann es nicht gewesen sein, da Win später drauf als Linux).

Aber bei jedem System mit mehreren NVMEs ändern diese ihre Nummern bei Reboots. Eben weil es keine Reihenfolge gibt sondern wer zuerst antwortet bekommt die erste freie Nummer. Das ist dann bei jedem Systemstart ein Wettrennen bzw. ein Lotterie Los.

Wurde ja von anderen hier schon diskutiert...aufgefallen ist mir das hier noch nicht.
Nichtsdestotrotz werde ich gerne mit den UUID arbeiten, wenn ich selbst was eintrage, schaden kann es ja scheinbar nicht.

Wer hat dir das geraten (link?) und was ist die Begründung das man das macht?

https://wiki.ubuntuusers.de/Dualboot/
Ich hatte vorab ziemlich viel rumgelesen, aber vermutlich war es einfach die Tatsache, dass hier folgendes stand:

Seit Ubuntu 7.10 wird der Lese- und Schreibzugriff auf NTFS Partitionen voll unterstützt. So können Daten von Linux auch auf eine Windows-NTFS-Partition kopiert werden und umgekehrt. Des weiteren ist es auch möglich, von Windows aus auf ein ext- oder Btrfs-Dateisystem auch Lese- und Schreibzugriff zu bekommen.

Bei "voll unterstützt" und das andere nur als Alternative genannt, habe ich vermutlich nicht lange überlegt. Irgendwo hatte ich gelesen das Treiber von Win für Linux-Formate stellenweise problematisch sein können, ohne dass ich jetzt noch die Details dazu weiß.

 

[rgbs]

ich in der Verwaltung für Wechselmedien

bzw. der KDE-Partitionsverwaltung festgelegt

Das sind ja zwei Paar Schuhe, die Partitionsverwaltung müsste ja auch (wie das unter Ubuntu mit Gnome disks ist) direkt Einträge in der fstab machen können.
Auf jeden Fall solltest Du deine Datentauschpartition bei den Wechselmedien austragen bevor Du diese in der fstab einträgst.
Außerdem müsstest Du ja auch noch in Zeile 15 der fstab die uuid mit eintragen.
So mal als Beispiel meine fstab, wobei die von mir angelegten Partitionen mit Gnome disks eingetragen wurden:

Gruß
R.G.

 

[MonteDrago]

OK, dann will ich auch dazu kurz meinen Einschätzung abgeben, auch wenn ich ntfs schon seit über 15 Jahren nicht mehr in Linux genutzt habe. 😏

Vorschlag, angelehnt an Post #10 und ubuntuusers.de:
UUID="063AC34F3AC33A87" /media/User/Daten/ ntfs-3g auto,users,windows_names,nofail 0 0

Also, den ntfs-3g Eintrag nicht nutzen der ist veraltet und kann meines Wissen nach beim Schreiben Probleme machen.
Das ganze wird mit "auto," beim Booten mit gemountet, der Kernel erkennt das dann automatisch mit.

Ich würde allerdings noch die Zugriffsrechte mit umask vergeben, wenn du aus Linux darauf schreiben willst.
Also in der fstab etwa so:
UUID="063AC34F3AC33A87" /media/User/Daten/ auto,users,umask=0777,windows_names,nofail 0 0

 

[kieleich]

ntfs-3g (ntfs über fuse) ist nicht veraltet, das war jahrelang die etablierte lösung und ist auch heute noch normal.

das schreibproblem hatte der kernel ntfs treiber. der kernel kann das safe erst seit kürzerer Zeit (2-3 Jahre??) und der neue treiber dazu heisst ntfs3. der veraltete ntfs ohne 3 treiber ist in den meisten distributionen gar nicht aktiviert kann man nur mit custom kernel oder separatem module paket überhaupt verwenden.

und es gibt unterschiede in der implementierung also links und rechte werden unter ntfs-3g und ntfs3 unterschiedlich dargestellt oder interpretiert. somit existierende beide Lösungen parallel und sind inkompatible zu einander.

man kann ntfs-3g zu ntfs3 wechseln und anders rum aber wer bei diesem dateisystem, komplexere strukturen verwendet statt nur hie und da mal auf eine datei zugreifen, der könnte probleme bekommen weil im detail eben unterschiede existieren

bei auto ist ein würfelspiel was man bekommt und wer weiss was wer will der schreibt es richtig rein

(idealerweise verzichtet man auf fat/ntfs/exfat komplett aber das ist halt auch nicht immer möglich)

 

[MonteDrago]

Ja OK, hatte ja geschrieben, das ich das seit über 15 Jahre nicht mehr in Linux genutzt habe. 🙄😏
Daher bin ich da nicht mehr ganz auf dem laufenden.😉🤷‍♂️

 

[Hyourinmaru]

UUID="063AC34F3AC33A87" /media/User/Daten/ auto,users,umask=0777,windows_names,nofail 0 0

War es nicht so, dass umask (sowie fmask und dmask) nicht direkt die Rechte einstellen, sondern die Verbote und damit die so angegebenen Rechte entfernt werden? Demzufolge hätte ein umask=0777 doch die Folge, dass niemand Rechte an den Daten hat, da umask=0777 daraus ein 0000 macht.
Würde man den Modus 0777 haben wollen, dann müsste das doch umask=0000 sein.

https://wiki.ubuntuusers.de/mount/#Windows-Dateisysteme

Setzt indirekt die Zugriffsrechte für alle Dateien, indem die Verbote angegeben werden. MASKE ist eine dreistellige Zahl. Zur Unterscheidung von Dateien und Verzeichnissen kann stattdessen auch fmask und dmask verwendet werden. Wird keine dieser Optionen verwendet, gelten für interne Laufwerke (nicht für dynamisch eingehängte externe USB-Partitionen) folgende Standardwerte: FAT: 022, NTFS: 000.

 

[Thorakon]

Hier noch kurze Info, wie ich die fstab nun abgeändert habe um die Einträge ohne UUID loszuwerden und gleichzeitig "Daten" beim Start zu mounten:
"Daten" ausgehängt und in der Wechselmedienverwaltung vom autostart ausgenommen; geprüft, dass auch in Partitionsverwaltung von KDE nichts steht.
Den gewünschten Ordner zum einhängen (wird beim unmount des "Wechselmediums" gelöscht) mit mkdir erzeugt.
Dann Bearbeitung der fstab wie folgt:

UUID="063AC34F3AC33A87" /media/user/Daten/ ntfs-3g auto,uid=1000,gid=1000,umask=0002,users,windows_names,nofail 0 0

UUID="8E02E2D002E2BBF9" none ntfs-3g noauto,ro,users,windows_names 0 0

Habe nun doch die Optionen mit uid und umask noch reingenommen, wobei die Rechteeinschränkungen hier sehr gering sind und eig. dem aktuellen Kubuntu-Standard entsprechen. Hatte perplexity.ai empfohlen und einige plausible Quellen dazu verlinkt.

Witzigerweise ist mir im Zuge des Ganzen aufgefallen, dass tatsächlich /dev/nvme1n... und /dev/nvme0n... beim reboot gestern die Plätze getauscht hatten. Also das zuerst von Keylan benannte Problem (Post #5). Das erklärt vielleicht auch meine Probleme mit dem Automount über die Wechselmedien-Verwaltung, oder den seltsamen (mittlerweile auskommentierten) Eintrag vom Startpost. Verwunderlich, dass ich dann hier nicht noch mehr Probleme hatte.

Nunja, mit den UUID ist das Problem hoffentlich gelöst, bisher läuft alles wie es soll. Danke nochmal für den ganzen Input.

 

[rgbs]

Verwunderlich, dass ich dann hier nicht noch mehr Probleme hatte.

Mein Rescuezilla würde sonst auch das Backup

Trotz jetzt korrekter fstab Einträge musst Du bei Rescuezilla aufpassen, da werden nämlich soweit ich das weiß keine uuids verwendet.
Ich verwende Clonezilla und da ist das so (dadurch ist mir schon vor Jahren aufgefallen, dass die NVMEs manchmal die Plätze tauschen).

Gruß
R.G.

 

[Thorakon]

Trotz jetzt korrekter fstab Einträge musst Du bei Rescuezilla aufpassen, da werden nämlich soweit ich das weiß keine uuids verwendet.
Ich verwende Clonezilla und da ist das so (dadurch ist mir schon vor Jahren aufgefallen, dass die NVMEs manchmal die Plätze tauschen).

Danke für den Tipp.
Rescuezilla basiert natürlich auch auf Clonezilla. Ich denke aber durch die stark unterschiedlichen Partitiongrößen und das "GUI" mit Auswahl erst SSD, dann Partition(en) fällt es mir da recht leicht auf, was ich sichere. Ist ja etwas, das ich vom Stick starten muss und keine Automatik, die fstab von meinem Kubuntu liest das live-System natürlich nicht ein, ja.

 

[rgbs]

Nun ja, besonders blöd wird es halt beim resichern. Da muss man dann aufpassen, falls die NVMEs die Plätze getauscht haben. Bei Clonezilla ist das dann die Nummer mit dem Expertenmodus.

Gruß
R.G.