staging.inyokaproject.org

Zurück zum Wiki-Artikel:

Beispielsweise kann beim fröhlichen Einbinden per GUI das eine Dateisystem per ntfs-3g und ein weiteres mit ntfs3 eingebunden werden oder ein und dasselbe Dateisystem einmal mit dem einen und dann mit dem anderen Treiber.

Das kann natürlich ganz leicht passieren, wenn man das Einbinden mit einem fstab-Eintrag mit noauto vorbereitet. Das geschieht dann auch ohne besondere Vorgaben, von denen "gewöhnliche" Benutzter vielleicht eher die Finger weg lassen sollten, wie udev-Regeln. Man muss deshalb darauf eingehen!

Da einbindbare Dateisysteme in der GUI auch an mehreren Stellen angeboten werden, scheint es auch noch von den konkret benutzten Bedienelementen abzuhängen, welches Ergebnis man erreicht.

Das konnte ich hingegen nicht beobachten. Egal, an welcher Stelle das Einbinden in der GUI angeboten wird (und ebenso auch in gigolo), in GTK-basierten Ubuntus wird immer gio mount -d /dev/… verwendet, und dabei können AFAIK keinerlei weitere Parameter übergeben werden. Deshalb möchte ich ja gerne alles vom Dateisystem NTFS bzw. vom Treiber NTFS-3G Unabhängige in diesen Artikel verlagern.

Nach meinen bisherigen Beobachtungen laufen mount und alles was auf udisks2 aufbaut, auf zwei völlig unabhängigen Schienen. D.h. das mount von der udisks2-Infrastruktur einschließlich darauf abgestimmter udev-Regeln nicht profitiert bzw. nicht davon beeinträchtigt wird - je nachdem, wie man da sehen will.

Ich weiß nicht, ob man das so sagen kann. Irgendwo ist natürlich die Stelle (Weiche) von der ab die Schienen auseinander laufen. Aber fstab-Einträge befinden sich vor dieser, denn sie werden sowohl von udisksctl -b /dev/… als auch von mount <Mountpunkt> berücksichtigt. Sie haben offenbar für udisksctl sogar Vorrang vor Einträgen in /etc/udisks2/mount_options.conf.

Max-Ulrich_Farber schrieb:

Zurück zum Wiki-Artikel:

Beispielsweise kann beim fröhlichen Einbinden per GUI das eine Dateisystem per ntfs-3g und ein weiteres mit ntfs3 eingebunden werden oder ein und dasselbe Dateisystem einmal mit dem einen und dann mit dem anderen Treiber.

Das kann natürlich ganz leicht passieren, wenn man das Einbinden mit einem fstab-Eintrag mit noauto vorbereitet. Das geschieht dann auch ohne besondere Vorgaben, von denen "gewöhnliche" Benutzter vielleicht eher die Finger weg lassen sollten, wie udev-Regeln. Man muss deshalb darauf eingehen!

Wenn man mit /etc/fstab-Einträgen herumexperimentiert, dann muss man auch noch beachten, dass der udisks-Daemon, die /etc/fstab auf Änderungen überwacht und für die auf udisks aufbauenden Frontends sofort verfügbar macht, wenn möglich - wie es bei den noauto-Einträgen der Fall sein kann.

Wenn man das nicht weiß und davon ausgeht, dass die Änderungen an der /etc/fstab erst nach einem Neustart wirksam werden, dann kann das auch zu scheinbar "merkwürdigen" Verhaltensweisen führen und Tests verfälschen.

LG, Newubunti

Vielleicht noch irgendwo erwähnen, dass die Option windows_names mittlerweile automatisch gesetzt wird. Und wie es scheint, gibt es kein no_windows_names, das man brauchen würde, wenn ein Programm besondere Zeichen im Dateinamen verwendet.

Max-Ulrich_Farber schrieb:

Zurück zum Wiki-Artikel:

Beispielsweise kann beim fröhlichen Einbinden per GUI das eine Dateisystem per ntfs-3g und ein weiteres mit ntfs3 eingebunden werden oder ein und dasselbe Dateisystem einmal mit dem einen und dann mit dem anderen Treiber.

Das kann natürlich ganz leicht passieren, wenn man das Einbinden mit einem fstab-Eintrag mit noauto vorbereitet.

Ich habe allerdings meine gemischten Zustände ganz ohne Einträge in der fstab nur über Bedienungen in der Desktop-Umgebung erzeugt. So etwas erwartet der naive Benutzer sicher nicht.

Wenn man mit fstab arbeitet, dann will man ja explizit bestimmte Verhältnisse (z.B. welchen der 3 möglichen Dateisystem-Treiber für NTFS) erzielen. Das funktioniert bei NTFS zwar auch nicht, ist aber ein anderes Problem als das mir aufgefallene.

kB schrieb:

Ich habe allerdings meine gemischten Zustände ganz ohne Einträge in der fstab nur über Bedienungen in der Desktop-Umgebung erzeugt. So etwas erwartet der naive Benutzer sicher nicht. ... Wenn man mit fstab arbeitet, dann will man ja explizit bestimmte Verhältnisse (z.B. welchen der 3 möglichen Dateisystem-Treiber für NTFS) erzielen. Das funktioniert bei NTFS zwar auch nicht, ist aber ein anderes Problem als das mir aufgefallene.

Ich sage das ausdrücklich nicht, weil ich Beobachtungen anzweifeln will, sondern vor dem Hintergrund, dass wir uns wegen der relativ neuen Einführung von ntfs3 hinsichtlich NTFS in einer Umbruchphase befinden:

• Könnten wir uns bitte darauf verständigen, dass so Aussagen, wie "funktioniert bei mir (nicht)" mit exakter Darlegung des Testverfahrens und des beabsichtigten Testziels flankieren?!

Dazu zählen für mich:

• Was für ein System, also VM, Laptop-, Desktop-Computer?

• Ubuntu Version(en) einschließlich Falvours mit der oder denen getestet wurde?

• Kernelversion/en?

• Welche Programme (mount, udisksctl, Laufwerke, Nautilus etc.) wurden zum Test herangezogen?

• Wurde mit oder ohne /etc/fstab-Eintrag getestet?

• Wie wurde überhaupt reproduzierbar vorgegangen?

Denn alleine bei udisks2 gab es z.B. folgende Änderungen bezüglich aktueller Ubuntu-Versionen:

• Ubuntu 22.04 mit udisks 2.9.4: Einführung der /etc/udisks2/mount_options.conf

• Ubuntu 23.10 mit udisks 2.10.2: Möglichkeit der Konfiguration der Priorisierung der genutzten NTFS-Treiber innerhalb der /etc/udisks2/mount_options.conf

Der zweite Punkt ist eine Reaktion auf die Einführung des ntfs3-Kernelmoduls. Man sieht daran auch, dass es aufgrund unterschiedlicher Releasezyklen aller beteiligter Komponenten ein, zwei LTS-Generationen braucht, bis sich alle Komponenten aufeinander abgestimmt sind.

Ubuntu ist da IMO auch immer besonders betroffen, weil dort einerseits aufgeschlossen mit Neuerungen umgegangen wird - z.B. wurde das ntfs3-Kernel-Modul schon sofort mit Einführung bei Ubuntu 20.04 aktiviert, aber andererseits steht das mit einer restriktiven Paketpolitiks Debians in Konflikt, die man bei Ubuntu dann einfach übernimmt.

Newubunti schrieb:

[…]

• Könnten wir uns bitte darauf verständigen, dass so Aussagen, wie "funktioniert bei mir (nicht)" mit exakter Darlegung des Testverfahrens und des beabsichtigten Testziels flankieren?! […]

Ja, das wäre schön. Allerdings macht diese durchaus auch von mir unterstützte Forderung Probleme in der Praxis: Ich habe durchaus Schwierigkeiten, die konkreten Testverhältnisse zu erfassen, insbesondere wenn ich z.B. Regeln für udev ändere – dann muss man eine spezielle Routine durchlaufen, damit die neue Version der Regeln überhaupt aktiviert wird. Trotzdem scheint es für die Einbindung erst nach der ersten Ausbindung (!?) wirksam zu werden. Bin momentan ziemlich verwirrt und kämpfe selber um Durchblick. Jedenfalls scheinen viele Details den Einbindeprozess zu beeinflussen. Solange ich selber nicht von der Wirksamkeit überzeugt bin, veröffentliche ich keine „vielleicht wirksamen Woodoo-Befehle“ mit vielleicht unerkannten Nebenwirkungen und belasse es mit dem Hinweis: Ich sehe auch merkwürdige Effekte.

Könnt Ihr mich hinsichtlich FUSE im Zusammenspiel mit ntfs-3g aufklären?

Schön wäre es!

Warum besteht z.B. in Ubuntu 22.04 eine Abhängigkeit des Paketes ntfs-3g zu fuse3, wenn aber doch ntfs-3g mit einem internen FUSE 28 kompiliert ist? Ich hätte jetzt angenommen, da müsste als Abhängigkeit libfuse2 genügen?

FUSE ist nicht nur für NTFS da, sondern ein allgemein benutzbares Subsystem. Da ist schon richtig, wenn Ubuntu die neueste Version (was auch immer das bei Ubuntu bedeuten mag) verwendet.

Und was hat das interne FUSE bei ntfs-3g überhaupt für eine Funktion?

Keine Ahnung. Unklar ist bereits, was "FUSE 28" überhaupt aussagen soll.

Ich habe allerdings meine gemischten Zustände ganz ohne Einträge in der fstab nur über Bedienungen in der Desktop-Umgebung erzeugt. So etwas erwartet der naive Benutzer sicher nicht.

Ich nehme ’mal ganz naiv an, dass es sich wohl um Fallbacks handelt, wenn du irgend etwas gemacht hast, was der prioritäre Treiber nicht mag – z.B. unpassende Mount-Optionen, unzulässige Zeichen im Dateinamen oder irgend etwas, woran man zunächst nicht denkt. Gegen solche unliebsamen Überraschungen gibt es wohl wirklich nichts anderes als das Blacklisting. Sicher kein eleganter Weg, aber wenigstens ein sicherer.

Da es diesen sicheren Weg gibt, würde ich vorschlagen, es im Wiki-Artikel bei diesem zu belassen. Wer sich wirklich nicht für einen der Treiber entscheiden kann und beide in seinem System behalten möchte, der muss sich eben selber durch das Gestrüpp durchhangeln.

Der zweite Punkt ist eine Reaktion auf die Einführung des ntfs3-Kernelmoduls. Man sieht daran auch, dass es aufgrund unterschiedlicher Releasezyklen aller beteiligter Komponenten ein, zwei LTS-Generationen braucht, bis sich alle Komponenten aufeinander abgestimmt sind.

Und das gilt erst recht, wenn es bei der Zusammenarbeit zwischen Modul-Maintainer und Kernel-Entwicklern so massiv hakelt wie in diesem Fall!

Könnten wir uns bitte darauf verständigen, dass so Aussagen, wie "funktioniert bei mir (nicht)" mit exakter Darlegung des Testverfahrens und des beabsichtigten Testziels flankieren?!

Als Absichtserklärung gerne. Aber oftmals macht man Beobachtungen auch zufällig, wenn man nach etwas ganz Anderem sucht. Da ist es dann schwierig oder ganz unmöglich, den gesamten Vorgang aus dem Gedächtnis zu rekonstruieren. Man kann dann nicht anders als den Ball mit "offenbar können so seltsame Dinge vorkommen wie…" weiterzugeben. Das "Tor" wird dann vielleicht ein Anderer schießen!

Max-Ulrich_Farber schrieb:

Da es diesen sicheren Weg gibt, würde ich vorschlagen, es im Wiki-Artikel bei diesem zu belassen. Wer sich wirklich nicht für einen der Treiber entscheiden kann und beide in seinem System behalten möchte, der muss sich eben selber durch das Gestrüpp durchhangeln.

+1! Und habe das soeben auch direkt umgesetzt.

LG, Newubunti

Zu ntfs-3g-Verwendung sicherstellen:

Ich denke, hier sollte noch das "vorbereitete Einbinden" erwähnt werden.

Max-Ulrich_Farber schrieb:

Ich habe allerdings meine gemischten Zustände ganz ohne Einträge in der fstab nur über Bedienungen in der Desktop-Umgebung erzeugt. So etwas erwartet der naive Benutzer sicher nicht.

Ich nehme ’mal ganz naiv an, dass es sich wohl um Fallbacks handelt, wenn du irgend etwas gemacht hast, was der prioritäre Treiber nicht mag – z.B. unpassende Mount-Optionen, unzulässige Zeichen im Dateinamen oder irgend etwas, woran man zunächst nicht denkt.

Ich habe zum Aufbau meines persönlichen Chaos nichts dergleichen gemacht, sondern ausschließlich auf Bedienelemente in der GUI des Desktops geklickt. Keine spezifischen Einträge in der fstab oder anderen Konfigurationsdateien, nur die standardmäßigen Mechanismen und Automatismen eines Desktops. Genau deshalb irritiert mich das ja. Natürlich kann man durch individuelle Vorgabe der Bedingungen bei jeder einzelnen Einbindungen so etwas erreichen, aber durch pure Bedienung über Standardelemente sollte so etwas nicht entstehen. Ich bemühe mich um Klärung.

Gegen solche unliebsamen Überraschungen gibt es wohl wirklich nichts anderes als das Blacklisting. Sicher kein eleganter Weg, aber wenigstens ein sicherer.

Blacklisting wirkt nicht in allen Fällen, Udev-Regeln ebenso. Zudem kann man prinzipiell nur Kernel-Module blacklisten, also nicht ntfs-3g oder exfat-fuse. Das Kernel-Modul ntfs kann man zwar blacklisten, aber das bringt keine Klarheit, weil ntfs-3g ja ntfs für sich okkupiert.

Da es diesen sicheren Weg gibt

Ich sehe keinen sicheren Weg, bei NTFS per Automatik den gewünschten Treiber zu selektieren.

• Was sicher funktioniert, ist die direkte Verwendung vom mount, natürlich als Root, mit expliziter Angabe des gewünschten Treibers.

• Vorgenannter Weg funktioniert auch bei Verwendung von mount über fstab als Root oder normaler Benutzer, dabei kann man aber das Kernel-Modul ntfs nicht bezeichnen, was man vermutlich verschmerzen wird.

• Bei Verwendung von Desktop-Funktionalität erhalte ich aber bisher ohne Konfiguration in fstab oder anderen Konfigurationsdateien bei NTFS unübersichtliche Verhältnisse und mit Konfiguration andere unübersichtliche Verhältnisse. Die Deinstallation von ntfs-3g, wenn man es nicht für NTFS benutzen möchte, ist keine Lösung, denn dann läuft es zwar über ntfs/ntfs3, aber man hat keine Dienstprogramme zur Formatierung/Überprüfung/Pflege.

Da war ich wahrscheinlich wieder ’mal viel zu naiv. Ich dachte so (und sehe nun, dass es viel zu einfach gedacht war):

• Wenn man nichts voreinstellt (kein fstab, keine udev-Regel, kein udisksctl.conf) dann wird bei allen GUI-Operationen und auch bei gio mount -d … der Treiber NTFS3 verwendet.

• Wenn man selbst Voreinstellungen vornimmt, dann muss man aufpassen, dass diese mit NTFS3 kompatibel sind, damit kein Fallback stattfindet, denn NTFS-3G kann man nicht blacklisten (vielleicht aber mittels FUSE deaktivieren, das könnte ich mir vorstellen, weiß ich aber nicht).

• Wenn man NTFS3 blacklistet und vielleicht auch noch den alten Treiber für NTFS (der ist wohl immer noch da ??), dann bleibt ja nur NTFS-3G übrig.

Nach den Ausführungen von kB scheint das alles nicht zu funktionieren. Dann weiß ich im Moment auch nicht weiter. Ich habe das Problem, dass meine Version 22.04 (immer noch das aktuelle LTS) durch ein Upgrade entstanden ist, und eine Neuinstallation will ich jetzt wirklich nicht durchführen! Ich habe VENTOY auf einer 500 GB USB-Platte und könnte versuchen, dort eine echte Neuinstallation einzurichten. Bislang habe ich dort halt Life-Systeme, und die sind nur sehr bedingt aussagekräftig. Aussagen aus VMs traue ich hier überhaupt nicht mehr (obwohl ich bisher immer so getestet hatte).

EDIT:

Vorgenannter Weg funktioniert auch bei Verwendung von mount über fstab als Root oder normaler Benutzer, dabei kann man aber das Kernel-Modul ntfs nicht bezeichnen, was man vermutlich verschmerzen wird.

Wirklich nicht? Man kann dort doch AFAIK ntfs3 angeben. Und wenn das in fstab steht, wird es auch über udisks respektiert (wieder zu naiv gedacht?). – Oder denkst du an das alte Kernel-Modul ntfs? Das ist doch wohl gestorben.

UlfZibis schrieb:

Vielleicht noch irgendwo erwähnen, dass die Option windows_names mittlerweile automatisch gesetzt wird. Und wie es scheint, gibt es kein no_windows_names, das man brauchen würde, wenn ein Programm besondere Zeichen im Dateinamen verwendet.

Worauf willst Du genau hinaus? Dass windows_names nicht gesetzt werden soll?

Und Du beziehst Dich wahrscheinlich wieder auf die Verwendung von Laufwerke oder Nautilus, richtig?

Falls ja, dann kann man das ab Ubuntu 22.04 über die /etc/udisks2/mount_options.conf konfigurieren. Das würde ich aber dann nicht unbedingt in diesem Artikel hier beschreiben, sondern nur von hier gegebenenfalls verlinken.

Die Standards hier im Artikel zu beschreiben, hielte ich für sehr pflegeintensiv und würde davon eher abraten, sondern nur verlinken, wie man diese - wenn möglich - ändert.

LG, Newubunti

erwähnen, dass die Option windows_names mittlerweile automatisch gesetzt wird.

Die Option windows_names ist IMO wohl momentan nur sekundär interessant. Zuerst geht es wohl darum, wie man es sicher erreichen kann, dass der gewünschte Treiber und nur dieser verwendet wird.

Ich arbeite gerade auf einem Thinkpad T30 mit Xubuntu 22.04, Upgrade von 20.04 aus, Kernel 5.15.0-97-generic, alle Updates eben erst gemacht, Dual-Boot mit Win 10, eine interne (Hintsystem=true) und eine externe NTFS-Partition.

1. Als erstes teste ich nun als "privilegierter" Benutzer (d.h. Mitglied in Gruppe sudoers.

   • Kein fstab-Eintrag, keine händischen Einträge in udev und udisksctrl.conf: Alle GUI-Werkzeuge sowie gio mount -d binden beide Partitionen mittels NTFS-3G ein.

   • Udev-Regel gesetzt mit

     SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs3"

     in /etc/udev/rules.d/99-force-ntfs3.rules: Alle GUI-Werkzeuge sowie gio mount -d binden beide Partitionen mittels NTFS3 ein. Zugriff vom Desktop aus und mittels gio mount -d direkt (ohne Passwort) möglich, der DM (Nautilus) verlangt für beide Partitionen Passwort (warum ?).

   • Ich sehe nicht, wie man mittels /etc/udisk2/mount_options.conf für ntfs einen bestimmten Treiber festlegen könnte. Im Gegenteil setzt diese Datei bereits einen festgelegten Treiber voraus und führt widrigenfalls zu unerlaubten Optionen. Was dann geschehen würde, gehört nicht ins Wiki. Man soll sich eben an die Regeln halten… 😉

   • fstab-Einträge mit noauto, die in sich widerspruchsfrei sind (nur jeweils zulässige Optionen, z.B. kein users usw. bei ntfs-3g) werden (anscheinend ungeachtet aller übrigen Einstellungen) von den GUI-Werkzeugen und gio mount -d fehlerfrei mit dem angegebenen Treiber ausgeführt, ntfs ist nach wie vor auf ntfs-3g verlinkt.

Bitte überprüft, ob das alles so gilt bzw. was in einem nativen Ubuntu 22.04.3 System anders ist. Natürlich würden mich auch alle beobachteten Unregelmäßigkeiten sehr interessieren.

Ich mache jetzt ’mal Pause und teste das gleiche anschließend als ganz armer, unterprivilegierter Benutzer. 😢

EDIT

Bevor ich nun in die Rolle eines Unterprivilegierten schlüpfe, noch eine Beobachtung: Es ist tatsächlich möglich, dass die gleiche Partition gleichzeitig mehrmals an verschiedene Mountpunkte und auch mit verschiedenen Treibern gemountet wird. Vor allem (nur?) mount mit Root-Rechten überprüft nicht, ob die Partition bereits eingebunden ist. Beim Aushängen wird nur der letzte mount-Eintrag gelöscht, und es kann dann geschehen, dass das gleiche Desktop-Symbol unversehens auf einen anderen Mount zeigt, möglicherweise sogar mit einem anderen Treiber. Dann ist so ziemlich alles durcheinander, was man sich vorstellen kann! Man sollte sich deshalb sicherheitshalber beim Testen vor jedem Einbinden mittels mount vergewissern, ob die Partition nicht unbemerkt schon eingebunden ist. Doch das alles ist ja bekannt, nur passiert es halt versehentlich doch ’mal.

Max-Ulrich_Farber schrieb:

[…]

• Wenn man nichts voreinstellt (kein fstab, keine udev-Regel, kein udisksctl.conf) dann wird bei allen GUI-Operationen und auch bei gio mount -d … der Treiber NTFS3 verwendet.

Es ist von der Version abhängig:

• Bei 20.04 HWE (nicht: LTS!) mit Kernel 5.15 wird beim Mounten per GUI wohl ntfs (mit der Option windows_names!) verlangt. Das ist mehrdeutig und kann sowohl das Kernel-Modul meinen, aber auch den Alias für ntfs-3g. Je nachdem, wie das System den Konflikt auflöst, führt das entweder zur Fehlermeldung, weil das Modul ntfs die Option windows_names nicht kennt oder zur Benutzung von ntfs-3g.

• Bei 22.04 HWE mit Kernel 6.5 führt das Mounten per GUI nach meinen Experimenten bisher immer zur Verwendung von ntfs3.

• Bei 22.04 HWE führt ein Mounten per sudo mount … immer zur Benutzung von ntfs-3g, sofern man nicht explizit den Typ angibt.

Ich habe keine Ahnung, was diese Änderung der Priorität bewirkt.

Nach den Ausführungen von kB scheint das alles nicht zu funktionieren.

Es funktioniert schon teilweise, aber leider nicht 100%-ig zuverlässig.

Vorgenannter Weg funktioniert auch bei Verwendung von mount über fstab als Root oder normaler Benutzer, dabei kann man aber das Kernel-Modul ntfs nicht bezeichnen, was man vermutlich verschmerzen wird.

Wirklich nicht? Man kann dort doch AFAIK ntfs3 angeben. Und wenn das in fstab steht, wird es auch über udisks respektiert (wieder zu naiv gedacht?). – Oder denkst du an das alte Kernel-Modul ntfs? Das ist doch wohl gestorben.

Ich meine das Kernel-Modul ntfs, das es jedenfalls beim Kernel 6.5 immer noch gibt. Das kann man über die fstab nicht benutzen, solange dieser Typ von ntfs-3g okkupiert wird. Auf der Kommandozeile kann man das mit der Option -i von mount übersteuern, aber diese Option ist nicht aus der Datei fstab benutzbar.

Max-Ulrich_Farber schrieb:

[…] Es ist tatsächlich möglich, dass die gleiche Partition gleichzeitig mehrmals an verschiedene Mountpunkte und auch mit verschiedenen Treibern gemountet wird.

Ja, das hat nichts mit NTFS zu tun und ist auch kein Bug, sondern ein Feature von mount, weil es in dessen Manpage beschrieben ist.

Bei NTFS hat es allerdings seine besondere Brisanz, weil es mehrere Treiber mit unterschiedlichen Fähigkeiten gibt. Ich halte in solchen Situationen Fehlfunktionen mit Datenverlust für nahezu sicher.