staging.inyokaproject.org

kB schrieb:

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.

Das kann ich bestätigen und ergänzend: Für GUI-Programme die auf udisks2 zurückgreifen, kommt die Option als Standard-Option mit Einführung von udisks 2.8.2 (siehe udisks2-Release-History). Ubuntu 20.04 verwendet udisks 2.8.4.

20.04 leidet IMO unter dem von mir schon weiter beschriebenen Umstand, dass zwar das ntfs3-Kernel-Modul schon direkt aktiviert wurde, die ganze Software drumherum aber mit dem Kernel-Modul noch nicht umzugehen weiß. Debian hat das nicht so gemacht und aktiviert das jetzt wohl erst mit Debian 13.

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

Das kann ich für Deine Vorgabe, nix an Konfiguration anfassen, bestätigen.

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

Kann ich ebenfalls bestätigen. ntfs3 muss im Zusammenspiel mit mount oder der /etc/fstab explizit angegeben werden. Ich denke dass das im Sinne der Rückwärtskompatibilität auch sinnvoll ist - also zumindest für mount.

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

Kannst Du nicht zuverlässig bitte genauer definieren?

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.

Bei mount hat das doch auch etwas mit dem Symlink zu tun:

jammy@jammyvm01:~$ sudo ls -ll /usr/sbin/mount.ntfs
lrwxrwxrwx 1 root root 13 Dez 18 11:47 /usr/sbin/mount.ntfs -> mount.ntfs-3g

Max-Ulrich_Farber schrieb:

• 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.

Ist das mit dem kein users in Zusammenhang mit noauto jetzt ein Ergebnis dieser Diskussion oder steht das irgendwo so eindeutig dokumentiert?

@kB. Das alles stimmt meiner Beobachtung nach für native Systeme mit Ubuntu 22.04, jedoch nicht für Upgrades von 20.04 aus. Diese verhalten sich offenbar weiterhin wie 20.04 und bevorzugen NTFS-3G. Aber das ist nicht schlimm, denn mit der obigen udev-Regel kann man das ja zuverlässig ändern (?).

Den alten Kernel-Treiber wird wohl freiwillig niemand mehr verwenden wollen. Wenn man über mount bzw. fstab an diesen nicht 'rankommt, ist das nicht schlimm. Außerdem kann man ja die Symlinks nach ntfs-3g deaktivieren. Aber davon würde ich lieber nichts im Wiki schreiben, denn wer will das schon? Wichtig ist, dass ein Fallback von NTFS-3G jetzt in 22.04 eben bei ntfs3 und nicht mehr beim alten Kernel-Modul landet.

20.04 leidet IMO unter dem von mir schon weiter beschriebenen Umstand, dass zwar das ntfs3-Kernel-Modul schon direkt aktiviert wurde, die ganze Software drumherum aber mit dem Kernel-Modul noch nicht umzugehen weiß.

In 20.04 zwar aktiviert, aber noch nicht Standard. Darüber braucht man deshalb nicht mehr viele Worte zu verlieren.

Ist das mit dem kein users in Zusammenhang mit noauto jetzt ein Ergebnis dieser Diskussion oder steht das irgendwo so eindeutig dokumentiert?

Im NTFS-3G Wiki ist bei den Mount-Optionen von ntfs-3g weder users noch user aufgeführt, wohl aber z.B. allow_other. Eigentlich sollten diese Optionen deshalb beim Aufruf von mount.ntfs-3g via mount -t ntfs schon herausgefiltert sein, sind sie aber nicht. Man sollte einfach schreiben, dass nur die bei dem jeweiligen Treiber aufgeführten Optionen verwendet werden dürfen. Verwirrend ist dabei allerdings, dass users und user in man mount als Dateisystem-unabhängig aufgeführt sind.

IMO sollten wir uns für diesen Artikel hier auf etwaige Fehlfunktionen beschränken, die dann auftreten, wenn trotz Blacklisting von ntfs3 es zu Problemen bei der Nutzung von ntfs-3g kommt.

Das wäre wohl nur das Fallback auf den alten Kernel-Treiber, das kann man in einem kurzen Satz erwähnen. Wichtig wäre mir aber: Wann und wie wird die udev-Regel zur Auswahl der Treiber nicht beachtet? Spielt diese (theoretische) Möglichkeit fürs Wiki überhaupt eine Rolle oder kann man die udev-Regel als zuverlässig ansehen? – Ich sehe bis jetzt nur mount und fstab, welche die udev-Regel missachten, und das ist ja trivial.

Bei NTFS hat es (= Mehrfach-Mount) 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.

Deshalb muss man bei NTFS ausdrücklich vor einem Mehrfach-Mount warnen. Wer es aber dennoch tut, tut es auf eigene Gefahr.

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

Sogar noch brisanter: Man kann mehrfach übereinander auf den gleichen Mountpunkt mounten, und das womöglich mit verschiedenen Treibern. – Aber so etwas gehört sich nicht, und ich will damit auch nicht weiter experimentieren. Wir bleiben anständig 😇 .

EDIT:

Bei 22.04 HWE mit Kernel 6.5 …

Ist es nötig, dass wir im Wiki auch die HWE-Versionen berücksichtigen? Das führt doch zu unheimlich viel Arbeit, an die sich dann niemand mehr 'ran machen will

Man muss Fehlfunktionen nicht verstehen. Oft reicht es aus, zu wissen, dass solche bei ungünstiger Konfiguration auftreten können und wie eine ungefährliche Konfiguration aussieht.

Aus meiner Sicht könnte für den Praktiker diese Strategie zu empfehlen sein:

• In der Datei fstab sollte man bei NTFS-Dateisystemen die Typangaben ntfs und erst recht auto vermeiden. Beide sind mehrdeutig interpretierbar. Statt dieser sollte man die eindeutigen Angaben ntfs3 bzw. ntfs-3g verwenden.

• Vorstehender Satz gilt auch für mount auf der Kommandozeile und ebenso für alle verwandten Programme.

• Man sollte sich bewusst für eines der beiden Programme ntfs-3g ./. ntfs3 entscheiden und konsequent nur eines verwenden.

• Wer ntfs-3g verwenden will, sollte die Kernel-Module ntfs und ntfs3 blacklisten.

• Wer ntfs3 verwenden will, sollte

  • entweder das Paket ntfs-3g deinstallieren (damit verliert man allerdings die Dienstprogramme und kann nicht mehr Formatieren/Überprüfen/Pflegen),

  • oder dem Befehl /sbin/mount.ntfs-3g (bzw. /usr/bin/ntfs-3g?) die Ausführungsrechte nehmen (Das ist bisher nur eine ungetestete Idee. Wirft vielleicht Fehler, aber i.d.F. gilt: „Es ist besser, NTFS nicht zu verwenden, als es falsch zu verwenden.“).

Max-Ulrich_Farber schrieb:

Im NTFS-3G Wiki ist bei den Mount-Optionen von ntfs-3g weder users noch user aufgeführt, wohl aber z.B. allow_other. Eigentlich sollten diese Optionen deshalb beim Aufruf von mount.ntfs-3g via mount -t ntfs schon herausgefiltert sein, sind sie aber nicht. Man sollte einfach schreiben, dass nur die bei dem jeweiligen Treiber aufgeführten Optionen verwendet werden dürfen. Verwirrend ist dabei allerdings, dass users und user in man mount als Dateisystem-unabhängig aufgeführt sind.

Das hatte ich ziemlich weit vorne auch schon mal in die Diskussion geworfen und da wurde mir entgegnet - allerdings nicht von Dir - dass das im ntfs-3g-Wiki "nur" ntfs-3g-spezifische Mount-Optionen seien und die allgemeinen damit nicht außer Kraft gesetzt wären.

Es ist mir bisher unmöglich gewesen, da im Internet verlässliche Aussagen zu bekommen. In der Anfangszeit von ntfs-3g wurden die Optionen user und users wohl nicht unterstützt bzw. funktionierten nicht richtig. Das lese ich aus dieser Release-Note von wohl 2007. Da das aber ewig her ist, sagt das auch nicht wirklich etwas aus. Jedenfalls gibt es keine folgende Release-Note, die die Optionen noch mal explizit nennen würde.

Seit 22.04 bringen die Optionen jedenfalls udisks2 aus dem Tritt und dürfen auch aus dieser Perspektive heraus nicht gesetzt sein - das war das Problem von UlfZibis.

IMO sollten wir uns für diesen Artikel hier auf etwaige Fehlfunktionen beschränken, die dann auftreten, wenn trotz Blacklisting von ntfs3 es zu Problemen bei der Nutzung von ntfs-3g kommt.

Bei 22.04 HWE mit Kernel 6.5 …

Ist es nötig, dass wir im Wiki auch die HWE-Versionen berücksichtigen? Das führt doch zu unheimlich viel Arbeit, an die sich dann niemand mehr 'ran machen will

Ich würde mir das wie gesagt im Moment viel einfacher machen:

Wer ntfs-3g nutzen möchte, der soll ntfs3 per Blacklist deaktivieren. Ganz simpel zu schreiben und noch viel wichtiger, ganz einfach zu lesen und dementsprechend zu befolgen.

Bei der Nutzung der udev-Regel und Differenzierung nach Kerneln, blickt kein Leser am Ende mehr durch.

Die udev-Regel hat das Problem, dass sie nicht garantiert systemweit gilt. Sie gilt schon nicht für mount und es kann GUI-Programme geben, die an udisks2 vorbei ein- und aushängen.

LG, Newubunti

EDIT:

Auch wenn es nicht so aussieht:

Mein Post hier hat sich mit dem von kB vor mir überschnitten. Ich würde kB hier in allen Punkten beipflichten wollen.

Mir gefällt immer noch die udev-Regel, denn mit ihr kann man auch, wenn man will, ein Fallback vorgeben. Vorausgesetzt natürlich, die Regel "funktioniert" zuverlässig. Deshalb meine Frage: Wann, wie und wo funktioniert die Regel denn nicht?

Aber das Blacklisting sollte unbedingt auch als "ultima ratio" erwähnt werden, denn wenn alle Stricke reißen…

Das Manko beim Blacklisting ist, dass es ja für NTFS-3G nicht geht, und FUSE komplett zu blacklisten wäre Schwachsinn. Deshalb: Kann man bei FUSE vielleicht einzelne Anwendungen ausschließen? Ich weiß das nicht. NTFS-3G deinstallieren ist wegen der Dienstprogramme nicht zu empfehlen, doch das mit den geklauten Ausführungsrechten von mount.ntfs-3g könnte vielleicht ein genialer Trick sein.

Aber, wie gesagt, wenn sie zuverlässig funktioniert (?), dann finde ich die udev-Regel zusammen mit der Aufforderung, bei mount und fstab immer (!) den gewünschten Treiber explizit anzugeben, eigentlich schöner. – Es geht doch nur ums Einbinden. Was außer mount und fstab könnte denn überhaupt sonst noch die udev-Regel missachten?

Doch jetzt muss ich noch meine Zusage einlösen, ’mal in die Haut eines Unterprivilegierten zu schlüpfen und so obige Tests wiederholen.

Max-Ulrich_Farber schrieb:

• 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… 😉

Das geht auch mit 22.04 bzw. udisks 2.9.X nicht. Das geht erst ab udisks 2.10.0 und damit ab Ubuntu 23.10.

LG, Newubunti

Also in Eile noch die Test-Ergebnisse:

• Die udev-Regel funktionierte zuverlässig für ntfs3 und ntfs-3g (für das alte ntfs nicht probiert), ist aber jeweils erst nach einem Neustart wirksam.

• die oben erwähnte unmotivierte Passwort-Abfrage von Nautilus war wohl ein Nautilus-Fehler und ist nicht reproduzierbar. Alles verlief sonst ohne Überraschungen wie erwartet. Alle GUI-Operationen entsprachen immer genau gio mount -d

• beim unprivilegierten User erfolgte nur bei der internen Partition (Hintsystem = Yes) eine Abfrage des Administrator-Passworts, sonst verlief alles genau gleich. Wieder keine Überraschungen.

• Die beiden DM Nautilus und Thunar zeigten zwar in der Leiste links nicht die gleichen Partitionen an, verhielten sich aber sonst völlig identisch.

Könnten wir jetzt mit diesen Informationen den Artikel für "getestet 22.04" fertig machen, IMO ohne HWE-Versionen? Wenn dann 24.04 da ist, kann man ihn ja nötigenfalls immer noch ergänzen.

Gruß – Max-Ulrich

Newubunti schrieb:

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?

Nein, nicht darauf. wird es gesetzt, ist es einfach nur redundant und schadet nicht.
Das Problem taucht auf, wenn ein Programm für seine Dateiablage Zeichen verwendet, die durch windows_names geblockt werden. Dann funktioniert ein solches Programm einfach nicht mehr, und man hat ein Problem, wenn man die Option dann nicht deaktivieren kann, z.B. per fstab. Ich hab' das tatsächlich mal erlebt, kann mich aber leider nicht mehr erinnern, welches das war. Könnte sein, dass es EasyTag war, wenn man versucht hat, die Namen von MP3-Datein aus dem Inhalt von z.B. dem Title-Tag automatisch zu benennen. Wenn dann in einem Tag ein für windows_names ungültiges Zeichen war, streikte die ganze Sache. Da half dann nur noch, windows_names aus der fstab zu entfernen (was aktuell nichts mehr nutzt), oder nur auf ext4 zu arbeiten, und die betreffenden Dateinamen später manuell zu korrigieren, wenn man sie für Windows verwenden wollte. Dummerweise kam von NTFS-3G da keine erklärende Fehlermeldung, sodass ich länger brauchte, die Ursache zu ermitteln. Dies hatte ich dann auch den NTFS-3G-Entwicklern gemeldet. Daraufhin wurde dann für neuere Versionen tatsächlich eine brauchbare Fehlermeldung angeboten. Ich meine, es gab aber auch ein Programm, wo die Verwendung von für Windows unzulässigen Zeichen fest verdrahtet war (kann in Zusammenhang mit Compiler und Make etc. gewesen sein), da ging dann einfach nix mehr.
Deshalb finde ich, dass darauf hingewiesen werden sollte, dass windows_names nun per default gesetzt wird (evtl. nur über gio bzw. GUI, evtl. nicht über mount / fstab), damit man weiß, wo man anfangen muss zu suchen, wenn solche Fehlfunktionen auftauchen.

..., 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.

👍

Max-Ulrich_Farber schrieb:

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.

Das ist wohl wahr.

Max-Ulrich_Farber schrieb:

• fstab-Einträge mit noauto, die in sich widerspruchsfrei sind (nur jeweils zulässige Optionen, z.B. kein users usw. bei ntfs-3g) ...

Wo ist das definiert, dass z.B. users unzulässig ist? Ich halte das eher für einen Bug (auf den man temporär so hinweisen könnte). (Den verlinkten Bug gerne mit "affects me" bestätigen, dann kriegt er den Status "confirmed", und dann kümmert sich auch jemand drum.)

Im NTFS-3G Wiki ist bei den Mount-Optionen von ntfs-3g weder users noch user aufgeführt,

Da ist auch die Option defaults nicht aufgeführt, dennoch ist sie zulässig und funktioniert auch.

... wohl aber z.B. allow_other

Das ist ja auch nicht verwunderlich, denn das ist ja keine Standard-Option von mount, siehe: https://manpages.ubuntu.com/manpages/jammy/en/man8/mount.8.html

Man sollte einfach schreiben, dass nur die bei dem jeweiligen Treiber aufgeführten Optionen verwendet werden dürfen.

damit wären aber auch defaults, gid, uid etc. verboten. Das kann also nicht richtig sein.

Verwirrend ist dabei allerdings, dass users und user in man mount als Dateisystem-unabhängig aufgeführt sind.

👍

Seit 22.04 bringen die Optionen jedenfalls udisks2 aus dem Tritt und dürfen auch aus dieser Perspektive heraus nicht gesetzt sein - das war das Problem von UlfZibis.

Richtig, außer dass das wohl nur für user, users und evtl. no_user (ist ja der default) gilt. Alle anderen Standard-Optionen sollten wohl kein Problem bereiten.

Max-Ulrich_Farber schrieb:

Also in Eile noch die Test-Ergebnisse:

• Die udev-Regel funktionierte zuverlässig für ntfs3 und ntfs-3g (für das alte ntfs nicht probiert), ist aber jeweils erst nach einem Neustart wirksam.

Das kann ich soweit bei Nutzung der Programme Nautilus und Laufwerke bestätigen. Ich kann aber nicht ausschließen, dass es Programme gibt, die die Regeln ignorieren. Ich gehe allerdings auch davon aus, dass die große Mehrheit der GUI-Nutzer eines der beiden genannten Programme für das Einhängen verwenden wird.

• die oben erwähnte unmotivierte Passwort-Abfrage von Nautilus war wohl ein Nautilus-Fehler und ist nicht reproduzierbar. Alles verlief sonst ohne Überraschungen wie erwartet. Alle GUI-Operationen entsprachen immer genau gio mount -d

Deckt sich ebenfalls mit meinen Beobachtungen.

• beim unprivilegierten User erfolgte nur bei der internen Partition (Hintsystem = Yes) eine Abfrage des Administrator-Passworts, sonst verlief alles genau gleich. Wieder keine Überraschungen.

Da hätte ich noch eine Nachfrage, auch wenn die Rückmeldung jetzt schon darauf schließen lässt, dass es sich so verhalten wird wie bei mir: Konntest Du mit einem Eintrag in der /etc/fstab mit noauto,users sowie setzen des SUID-Bit für /bin/ntfs-3g nach Neustart anschließend mittels mount /mein/Mountpunkt (also nur mount ohne sudo) mounten? Oder auch durch die Kombination von noauto,allow_other?

• Die beiden DM Nautilus und Thunar zeigten zwar in der Leiste links nicht die gleichen Partitionen an, verhielten sich aber sonst völlig identisch.

Bei mir ist die NTFS-Partition teilweise nur über "+Andere Orte" in Nautilus zugänglich.

LG, Newubunti

Dröseln wir's von hinten her auf:

Bei mir ist die NTFS-Partition teilweise nur über "+Andere Orte" in Nautilus zugänglich.

Das ist Nautilus. Bei Thunar sind alle NTFS-Partitionen direkt zugänglich. Aber sonst ist's gleich.

Konntest Du mit einem Eintrag in der /etc/fstab mit noauto,users…

Bisher hat bei mir mit users gar nichts geklappt. Aber ich habe nicht mehr weiter experimentiert. In man mount.ntfs-3g sind users und user nicht unter den unterstützten Optionen aufgeführt.

Ich kann aber nicht ausschließen, dass es Programme gibt, die die Regeln ignorieren.

Das ist gerade die entscheidende Frage. Gibt es überhaupt ein anderes Backend außer udisks, mittels dessen man ohne Root-Rechte und ohne SUID-Bit Partitionen einbinden kann? Wenn es, wie vermutet, das Backend udisks ist, das den Treiber auswählt (dafür spricht eigentlich bisher alles) und nicht erst irgend ein Frontend, dann ist wohl die Gefahr nicht groß.

Ein anderes Problem sehe ich aber seit Ubuntu 23.10: Wenn udisksctl.conf ebenfalls Treiber auswählen kann, was ja vorher nicht ging, dann sind zwei einander widersprechende, konkurrierende Einstellungen denkbar. Wie steht es dann mit der Priorität? Ich vermute fast, dass die .conf Datei dann wie auch fstab höhere Priorität hat als die udev-Regel. Und das wäre dann ein Einfallstor für eine unerwünschte Interferenz des "falschen" Treibers!

Beim Holzhammer Blacklist stört mich halt, dass er nur in eine Richtung geht, und dass man ntfs-3g so nur über Tricks ausklinken kann. Und ist es überhaupt sicher, dass man mittels ntfs-3g nur über mount.ntfs-3g einhängen kann? (aber wie denn sonst?). NTFS-3G gleich ganz deinstallieren beim aktuellen Stand von ntfs3? Ich denke, dass doch manche vor einer endgültigen Festlegung noch gerne etwas hin und her experimentieren wollen.

Max-Ulrich_Farber schrieb:

Ein anderes Problem sehe ich aber seit Ubuntu 23.10: Wenn udisksctl.conf ebenfalls Treiber auswählen kann, was ja vorher nicht ging, dann sind zwei einander widersprechende, konkurrierende Einstellungen denkbar. Wie steht es dann mit der Priorität?

Die Priorität ist aufsteigend sortiert, also höhere Nummer = höhere Priorität:

1. Einprogrammierte Standards

2. /etc/udisks2/mount_options.conf

3. udev-Regel

Also sollte Deine Befürchtung diesbezüglich damit praktisch nicht wahr werden können.

LG, Newubunti

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.

Die Option windows_names wird bei ntfs-3g nicht automatisch gesetzt. Das Problem ist diffiziler:

• Es gibt diese Option schon lange bei ntfs-3g und beim Kernel-Modul ntfs3 ab Kernel 6.2.

• Es gibt sie nicht beim Kernel-Modul ntfs und auch nicht beim Kernel-Modul ntfs3 für Kernel ab 5.15 bis 6.1.

Der Disk Manager udisks fordert aber ab Version 2.8.4 für NTFS-Dateisysteme standardmäßig die Option windows_names. Hiervon betroffen sind alle Programme, welche udisks verwenden und insbesondere wohl alle GUI-Programme. Damit entsteht bei Ubuntu Desktops ab 20.04 HWE ab Kernel 5.15 ein Problem: Es kann beim Einbinden eines NTFS-Dateisystems automatisch das neue Kernel-Modul ausgewählt werden und dieses verweigert die Arbeit, weil es die Option (noch) nicht kennt. Mögliche Folgen:

• Entweder: Einbindung misslingt gänzlich.

• Oder: Es wird dann doch noch das Modul ntfs ausgewählt und das Dateisystem schreibgeschützt eingebunden.

Jedenfalls ändert sich in unschöner Weise das Verhalten beim Einbinden eines NTFS-Dateisystems bei einem Upgrade 20.04 Kernel < 5.15 → auf Kernel 5.15. Und 22.04 LTS mit Kernel 5.15 ist natürlich auch betroffen, bei 22.04 HWE verbessert sich das Verhalten aber mit der Freigabe von 23.04 und Umstieg auf den Kernel 6.2.

Die Gegenmaßnahmen in einer solchen Situation (System mit Kernel vor 6.2) wären:

• blacklist ntfs3

• Beim Einbinden nach Möglichkeit immer ntfs-3g angeben.

• Ggf. Konfiguration in udisks der Mount-Optionen für den Dateisystemtyp ntfs (nicht: Modul!) ohne Angabe der Option windows_names.

kB schrieb:

• Wer ntfs3 verwenden will, sollte

...

• oder dem Befehl /sbin/mount.ntfs-3g (bzw. /usr/bin/ntfs-3g?) die Ausführungsrechte nehmen (Das ist bisher nur eine ungetestete Idee. Wirft vielleicht Fehler, aber i.d.F. gilt: „Es ist besser, NTFS nicht zu verwenden, als es falsch zu verwenden.“).

Ich habe das mal getestet. Ausführungsrechte nehmen ist praktisch nicht so gut, weil sich das wie folgt darstellt:

jammy@jammyvm01:~$ sudo chmod -x /usr/bin/ntfs-3g
jammy@jammyvm01:~$ ls -la /usr/bin/ntfs-3g
-rw-r--r-- 1 root root 162824 Nov  1  2022 /usr/bin/ntfs-3g
jammy@jammyvm01:~$ sudo mount -t ntfs-3g /dev/vdb1 /media/ntfs
jammy@jammyvm01:~$ mount | grep /media/ntfs
jammy@jammyvm01:~$ 
 

D.h. auf den ersten Blick wirkt es so, als sei das Kommando korrekt ausgeführt, tatsächlich wird aber nicht eingehängt.

Was aber auf den ersten Blick funktioniert, ist das Verschieben/Umbenennen von /usr/bin/ntfs-3g:

jammy@jammyvm01:~$ sudo mv /usr/bin/ntfs-3g{,.disabled}
jammy@jammyvm01:~$ sudo mkdir /media/ntfs
jammy@jammyvm01:~$ sudo mount -t ntfs-3g /dev/vdb1 /media/ntfs
mount: /media/ntfs: unbekannter Dateisystemtyp "ntfs-3g".
jammy@jammyvm01:~$  

Und diese Fehlermeldung gleicht der, wenn man ntfs-3g ganz deinstalliert, womit sich die Wahrscheinlichkeit erhöht, dass Programme die ntfs-3g zum Einbinden verwenden wollen, mit der Fehlermeldung umgehen können (sollten).

LG, Newubunti

EDIT:

kB schrieb:

... Mögliche Folgen:

• Entweder: Einbindung misslingt gänzlich.

• Oder: Es wird dann doch noch das Modul ntfs ausgewählt und das Dateisystem schreibgeschützt eingebunden.

Jedenfalls ändert sich ...

Das stellt sich bei mir aber mit den folgenden Kernel-Daten anders dar (Beispiel ist jetzt 20.04.6, Jammy verhält sich aber bei Kernel < 6.2 gleich):

focal@focalvm01:~$ uname -a
Linux focalvm01 5.15.0-97-generic #107~20.04.1-Ubuntu SMP Fri Feb 9 14:20:11 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
focal@focalvm01:~$ cat /proc/version_signature 
Ubuntu 5.15.0-97.107~20.04.1-generic 5.15.136

1. Entweder: Einbindung misslingt gänzlich ⇐ Diesen Fall hatte ich noch nicht, will ihn aber auch nicht als möglich ausschließen

2. Als nächstes kommt bei mir der "stille" Fallback auf ntfs-3g

3. Wenn ntfs-3g nicht verfügbar, Fallback auf ntfs, ro

Nummer drei wäre zwar praktisch unschön, aber Nummer zwei ist dagegen potentiell gefährlich.

Ich muss dazu sagen, dass ich den Beweis dafür, dass die Verwendung von ntfs-3g als Fallback von ntfs3 bei Ubuntu 20.04.6 stattfindet, gar nicht direkt führen kann. Ich kann das nur herleiten aus

• dem Umstand, dass Kernel-Modul-Treiber grundsätzlich externen Treibern vorgezogen werden

• Den Release-Notes zu udisks2

• Dem Ergebnis des Mountvorgangs und Einsicht ins Protokoll journalctl nach Einhängeprozedere

Merkwürdig ist auch, dass windows_names als Standard vorgegeben ist, aber dann bei Abfrage mittels mount | grep Mountpunkt nicht aufgelistet wird. Im Protokoll taucht die Option aber auf, ohne dass so richtig klar wäre, dass sie auch gesetzt wurde.

Bei Ubuntu 22.04.X mit Kernel < 6.2 lässt sich der Nachweis führen, weil man dort die Standard-Einstellung windows_names verändern kann.

LG, Newubunti

kB schrieb:

Das Problem ist diffiziler: [.....]

Sehr schön recherschiert und klar dargestellt. 👍

Die Option windows_names wird bei ntfs-3g nicht automatisch gesetzt.

Für den Endbenutzer, der für gewöhnlich nur die GUI nutzt, wirkt es aber so. Deshalb sollte IMHO so ein Hinweis ins Wiki, damit er weiß, wo er mit der Ursachenforschung beginnen kann, wenn die automatisch vorgegebene Option windows_names mit irgendeiner Anwendung überraschende Probleme verursacht.
Das gleiche gilt nicht nur für interne Partitionen, die ja erst auf Anfrage durch die GUI eingebunden werden, sondern erst recht für externe Partitionen, die ja automatisch eingebunden werden.

Die Gegenmaßnahmen in einer solchen Situation (System mit Kernel vor 6.2) wären:

Auch nach 6.2 gibt es das oben genannte Problem.

• blacklist ntfs3

Wie schon von anderer Seite erwähnt, eine zu radikale Methode.

• Beim Einbinden nach Möglichkeit immer ntfs-3g angeben.

Nicht möglich bei Mount über GUI oder automatischem Mount von externen Partitionen.

• Ggf. Konfiguration in udisks der Mount-Optionen für den Dateisystemtyp ntfs (nicht: Modul!) ohne Angabe der Option windows_names.

Genau dies sollte dann IMHO im Artikel als "workaround" angeboten werden.