staging.inyokaproject.org

Einhängen mittels GUI ist bei GTK-Flavors von Ubuntu gleichbedeutend mit gio mount. Was ich herausbekommen will ist, salopp gesprochen: Will gio mount freiwillig gvfs3 benutzen oder kann es irgendwie nicht anders.

Probiere ich gleich mal. Was für eine Änderung erwartest Du?

Vielleicht tritt dann das Verhalten wie bei mir auf. Das wäre ein Hinweis, dass FUSE das Mounten mittels NTFS-3G verhindert hat, vielleicht weil die Mount-Option users nicht akzeptiert wird (siehe obiger "BUG"). Dann würde es sich tatsächlich um ein fallback handeln. Bei gio mount tappe ich ziemlich im Dunkeln. Mit den beiden Zeilen müsste FUSE eigentlich tolerant sein und jedem das Mounten erlauben.

Ab Ubuntu 22.04 bei Neuinstallation einhängen mittels GUI ⇒ ntfs3

Aber warum nur bei gio mount und nicht auch bei mount oder fstab? Dieser "Alleingang"" von gio mount stört mich. Und ein solcher wichtiger Unterschied zwischen Upgrade und Neuinstallation kann zwar passieren, ist aber unüblich.

Alles klar! Ich verstehe nun worauf Du hinaus willst und werde entsprechende Tests machen.

Ich muss jetzt erst mal etwas anderes erledigen, werde dann heute am späteren Abend wieder antworten.

LG, Newubunti

EDIT:

Noch schnell: In der /etc/fstab habe ich bei meinen Versuchen bis jetzt für den Typ immer ntfs oder auch ntfs-3g angegeben, was das gleiche bedeutet und ja somit ntfs-3g erzwingt. Insofern kann da das System ja gar nicht wählen. Man muss das - um vergleichbar zu GUI zu sein - mit dem Typ auto gegenprüfen.

Man muss das - um vergleichbar zu GUI zu sein - mit dem Typ auto gegenprüfen.

oder einfach mal mount ohne Typ-Angabe. Müsste auch gehen.

Getestet erst mal nur mit Ubuntu 22.04:

Also auto oder keine Angabe beim mount-Kommando führen im Terminal immer zu ntfs-3g. Ich denke mal, dass das an den ganzen Symlinks liegt, die von mount.ntfs letztlich auf /bin/ntfs-3g zeigen.

Das Standardverhalten der GUI kann ich durch eine udev-Regel verändern, z.B. /etc/udev/rules.d/99-force-ntfs-3.rules:

SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs-3g"

Es besteht bei mir aber unter Ubuntu 22.04 standardmäßig keine udev-Regel der Art:

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

Wo diese Standardeinstellung der GUI herkommt, habe ich bis jetzt noch nicht heraus gefunden.

LG, Newubunti

Und

SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs-3g"

funktioniert ohne Fallback? Dann kann es nicht FUSE sein, das sich querstellt. Dann ist offenbar ntfs3 bei der GUI und gio mount gewollt.

Wenn bei GUI und Kommandozeile standardmäßig verschiedene, zueinander nicht kompatible (!) Treiber verwendet werden, ist das IMO ein "dicker Hund"!

Wenn ich Zeit habe, probiere ich es vielleicht noch mittels VENTOY in einem nativen, neu installierten Ubuntu 22.04.3 ohne VM. Aber ich glaube nicht mehr, dass das was ändert.

Newubunti schrieb:

Würde ich meine 20.04-Installation auf 22.04 upgraden, dann könnte ich sehr wahrscheinlich das gleiche Verhalten wie bei Dir beobachten.

Könntest Du das nicht einfach mal machen? Dann wäre die Frage (vermutlich) eindeutig geklärt. Kannst ja von der aktuellen 20.04-VM vorher ein Backup machen.

Habt Ihr denn eine Erklärung, warum bei mir ntfs3 überhaupt nicht funzt?

Max-Ulrich_Farber schrieb:

Und

SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs-3g"

funktioniert ohne Fallback?

So wie ich es im vorigen Post angegeben habe, funktioniert es nur, solange ntfs-3g installiert ist. Nachdem ich es für den Fallback-Test gepurgt habe, erst mal Fehlermeldung wegen unbekannten ntfs-3g, also einfach mal probiert, den Fallback manuell zu setzen,

SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs-3g,ntfs3"

Erfolg! Er mountet mit ntfs3.

ntfs-3g wieder installiert ⇒ Er mountet mit ntfs-3g! 😀

Aufgrund von

https://wiki.gnome.org/Projects/gvfs/doc#Volume_monitors

und

https://gitlab.gnome.org/GNOME/gvfs/raw/master/monitor/udisks2/what-is-shown.txt

sowie

https://storaged.org/doc/udisks2-api/latest/mount_options.html

habe ich ein gutes Gefühl bezüglich des GUI-Mountens mit udisks2 und udev hier auf der richtigen Fährte zu sein.

Außerdem hat sich mein Verdacht bestätigt, dass die Mount-Schwierigkeiten per GUI mit ntfs-3g bei internen NTFS-Partitionen wegen fehlender Zugriffsrechte auf /dev/..., an der Einstufung als Block:HintSysem liegen:

https://forum.ubuntuusers.de/topic/unknown-error-when-mounting-udisks-error-quark/5/#post-9417209

LG, Newubunti

Zur neuen Eränzung von Max-Ulrich_Farber:

Sollte dies aber trotzdem einmal der Fall sein, dann gelten folgende Prioritäten:

• Findet NTFS-3G keine User-Mapping-Datei vor (s.u.), so haben die Optionen uid, gid, umask usw. Priorität. Eventuell vorhandene persistente Dateirechte werden dann ignoriert.

• Findet NTFS-3G aber eine User-Mapping-Datei vor, dann haben permissions und acl Priorität, und die Optionen uid, gid, umask usw. werden ignoriert.

Würde man da nicht besser schreiben? :

• Findet NTFS-3G keine User-Mapping-Datei vor (s.u.), so haben die Optionen uid, gid, umask usw. Priorität vor permissions und acl. Eventuell vorhandene persistente Dateirechte (auch die von Windows) werden dann ignoriert.

Interessant wäre dann noch zu erforschen, wie sich dann inherit auswirkt.

Und:

• Findet NTFS-3G aber eine User-Mapping-Datei vor, dann haben permissions und acl Priorität, und die Optionen uid, gid, umask usw. und die User-Mapping-Datei werden ignoriert. Dies führt zu Fehlern, denn die Zuordnungen aus der User-Mapping-Datei sind nicht kompatibel mit denen von permissions und acl.

@UlfZibis

Findet NTFS-3G keine User-Mapping-Datei vor (s.u.), so haben die Optionen uid, gid, umask usw. Priorität vor permissions und acl. Eventuell vorhandene persistente Dateirechte (auch die von Windows) werden dann ignoriert.

Die Ergänzungen sind ok. Ich habe diese (vielleicht fälschlicherweise) für selbstverständlich gehalten.

Findet NTFS-3G aber eine User-Mapping-Datei vor, dann haben permissions und acl Priorität, und die Optionen uid, gid, umask usw. und die Usuer-Mapping-Datei werden ignoriert. Dies führt zu Fehlern, denn die Zuordnungen aus der User-Mapping-Datei sind nicht kompatibel mit denen von permissions und acl.

So ist das nicht richtig! Es müsste vielmehr heißen: Schon früher ohne User-Mapping gesetzte persistente Dateirechte gelten nicht mehr, da durch die User-Mapping-Datei nun eine andere Zuordnung von UID:GID zu Windows-SID festgelegt wird. Die früher ohne User-Mapping vorgenommene (willkürliche) Zuordnung läuft damit ins Leere. Die Devise ist also: "einmal User-Mapping – immer User-Mapping" und nicht "mal mit und mal ohne". – Aber auf diese Problematik kann an dieser Stelle (noch) nicht eingegangen werden. Wenn überhaupt, dann erst unten nach der Erklärung, wie User-Mapping funktioniert.

Doch auch ich habe jetzt leider erst mal anderes zu tun und antworte deshalb auf Newubunti später.

Max-Ulrich_Farber schrieb:

So ist das nicht richtig! Es müsste vielmehr heißen: Schon früher ohne User-Mapping gesetzte persistente Dateirechte gelten nicht mehr, da durch die User-Mapping-Datei nun eine andere Zuordnung von UID:GID zu Windows-SID festgelegt wird.

Meiner Erinnerung nach gilt auch:
Einmal Rechte per permissions gesetzt, dann werden die bei vorhandener User-Mapping-Datei fehlinterpretiert. Und Windows kann mit den von permissions gesetzten Rechten überhaupt nicht umgehen. Vielleicht ist letzeres ja der Grund, warum NTFS3 mit permissions anders umgeht, Vielleicht haben die da ein mit Windows kompatibles Verfahren gefunden / vereinbart.

Und für acl gilt wohl was ähnliches, habe ich aber nie benutzt und in sofern keine Ahnung.

Einmal Rechte per permissions gesetzt, dann werden die bei vorhandener User-Mapping-Datei fehlinterpretiert. Und Windows kann mit den von permissions gesetzten Rechten überhaupt nicht umgehen.

Das stimmt so, wenn die Rechte ohne passendes User-Mapping oder mit einem anderen, auf ein anderes Windows-System passenden User-Mapping eingerichtet wurden. Doch folgendes verstehe ich nicht ganz:

Vielleicht ist letzeres ja der Grund, warum NTFS3 mit permissions anders umgeht, Vielleicht haben die da ein mit Windows kompatibles Verfahren gefunden / vereinbart.

Möglicherweise ist dies ein Missverständnis: NTFS-3G hat mit permissions ein in sich schlüssiges Verfahren zum wechselseitigen Umgang mit Dateirechten in Windows/Linux. Es ist nicht gerade einfach, aber es funktioniert. Von NTFS3 ist mir nichts bekannt, wie man mit diesem Treiber zu einem wechselseitigen Umgang mit Dateirechten kommen könnte. Die Dokumentation zu ntfs3 ist leider (noch?) spärlich. AFAIK bestehen da beide Rechtesysteme (Windows und UNIX/POSIX) völlig unabhängig voneinander auf dem gleichen Datenträger.

Max-Ulrich_Farber schrieb:

Doch folgendes verstehe ich nicht ganz:

Vielleicht ist letzeres ja der Grund, warum NTFS3 mit permissions anders umgeht, Vielleicht haben die da ein mit Windows kompatibles Verfahren gefunden / vereinbart.

Möglicherweise ist dies ein Missverständnis: NTFS-3G hat mit permissions ein in sich schlüssiges Verfahren zum wechselseitigen Umgang mit Dateirechten in Windows/Linux. Es ist nicht gerade einfach, aber es funktioniert. Von NTFS3 ist mir nichts bekannt, wie man mit diesem Treiber zu einem wechselseitigen Umgang mit Dateirechten kommen könnte. Die Dokumentation zu ntfs3 ist leider (noch?) spärlich. AFAIK bestehen da beide Rechtesysteme (Windows und UNIX/POSIX) völlig unabhängig voneinander auf dem gleichen Datenträger.

Mit permissions "erfindet" NTFS-3G SIDs, die Windows unbekannt sind, und versieht die dann mit Rechten. Wenn dabei die evtl. vorhandenen Original-SID-Rechte von Windows nicht überschrieben werden, könnte es tatsächlich klappen, dass dann beide Rechte-Systeme parallel funktionieren, was aber voraussetzen würde, dass auch Windows die von NTFS-3G gesetzten Rechte nicht überschreibt. Ob das so ist, könnte man mit ntfssecaudit überprüfen. Was NTFS-3G unter permissions mit Dateien macht, die nur von Windows mit entsprechenden SID-Rechten versehen wurden, weiß ich auch nicht.

Wenn mittels NTFS-3G und permissions neue Dateien erzeugt werden, haben die dann keine Windows-kompatiblen Rechte. Was Windows damit macht, ob es die Dateien dann öffnet z.B., weiß ich nicht. Wenn solche Dateien dann aber mittels User-Mapping-Datei von Linux eingebunden werden, dürfte Linux dann gar keine Rechte an diesen Dateien haben.

Wenn ich es richtig verstanden haben macht NTFS3 per default etwas ähnliches wie NTFS-3g mit Option permissions aber auf unterschiedliche Weise, weshalb die dann nicht miteinander kompatibel sind.

@Newubunti

Nun endlich…

In einem entsprechen deine Beobachtungen genau dem, was ich auch erwartet hätte. Wenn Du in einer udev-Regel ein Fallback zu ntfs3 verlangst, dann funktioniert das auch so. Das ist korrekt (aber leider nicht ganz selbstverständlich…).

Was mich überrascht ist, dass ohne von Hand eingetragene udev-Regel, also per Default, gar kein Fallback stattfindet. Was in NTFS-3G (Abschnitt „Transparente-Verwendung-in-Ubuntu“) steht, stimmt also offenbar nicht mehr. Wichtig wären für mich jetzt Antworten auf folgende Fragen:

• versucht Ubuntu wirklich immer zuerst, mit NTFS-3G einzuhängen und ist die Verwendung von ntfs3 also ein Fallback?

• unter welchen Bedingungen findet beim Misslingen des Einhängens mittels NTFS-3G überhaupt ein Fallback statt?

• wird bei einem Fallback per Default nach wie vor mit dem alten ntfs-Kerneltreiber im Modus ro eingehängt, oder wird da jetzt ntfs3 im Modus rw verwendet?

Vermutlich sind die Antworten auf diese Fragen so, wie sie (noch) im Wiki stehen, falsch bzw. obsolet.

Wenn man die derzeitige Situation beim Kernel-Treiber ntfs3 von Paragon betrachtet, dann wäre es mir weitaus am liebsten, wenn per Default immer erst versucht würde, mit NTFS-3G einzuhängen und ntfs3 nur ein Fallback wäre, denn:

• die Dokumentation zu ntfs3 ist im Vergleich zur sehr guten Dokumentation von NTFS-3G sehr spärlich und lässt viele Fragen offen

• bei ntfs3 findet man in Internet-Blogs viele Fehler bzw. Ungereimtheiten oder Missverständnisse und leider auch von Dateisystem-Beschädigungen

• die Kommunikation mit dem Betreuer von ntfs3, einem Russen, ist zurzeit durch die bedauerliche politische Situation leider sehr erschwert, wenn nicht unmöglich.

• NTFS-3G von Tuxera ist nach langer Entwicklingszeit (seit 2006) zwar nicht gerade schnell, aber doch sehr stabil und zuverlässig geworden. Es ist sehr gut dokumentiert, und wenn trotzdem nötig, erfolgen Fehler-Korrekturen schnell und problemlos.

• das User-Mapping von NTFS-3G ist zwar nicht gerade einfach, aber AFAIK einmalig.

Bei exFAT wurde der erste Kernel-Treiber, ebenfalls von Paragon, nach kurzer Zeit wieder entfernt und zur allgemeinen Zufriedenheit durch den stabileren und performanteren Treiber von Samsung ersetzt. Diese Möglichkeit besteht zurzeit bei NTFS leider nicht.

Ich würde gerne so vorgehen:

• Wenn möglich und vertretbar, würde ich gerne zurzeit NTFS-3G nach wie vor als Standard-Treiber darstellen und ntfs3 als "experimentell" ansehen.

• Später dann, wenn sich die Verhältnisse bei ntfs3 (und auch der Treiber selbst) stabilisiert haben, könnte ntfs3 zu einer sinnvollen Standard-Lösung für alle diejenigen Benutzer werden, die kein User-Mapping benötigen und für die dieses schwierige Unterfangen eine unnötige Belastung und Fehlerquelle ist

• Vielleicht bekommen wir doch noch einen anderen Kernel-Treiber, wodurch die Arbeit für einen Wiki-Artikel für ntfs3 zur Makulatur würde (??)

Doch die Verantwortung für das gesamte Gebiet "Windows-Partitionen einbinden" habe nicht ich, sondern kB.

@UlfZibis

Mit permissions "erfindet" NTFS-3G SIDs, die Windows unbekannt sind, und versieht die dann mit Rechten. Wenn dabei die evtl. vorhandenen Original-SID-Rechte von Windows nicht überschrieben werden, könnte es tatsächlich klappen, dass dann beide Rechte-Systeme parallel funktionieren, was aber voraussetzen würde, dass auch Windows die von NTFS-3G gesetzten Rechte nicht überschreibt.

Das funktioniert wegen des riesigen Zahlbereichs für SID zuverlässig. Frage mich bitte nicht, wie Windows diesen belegt und wo NTFS-3G "sichere" SID findet, die Windows nicht benützt.

Was NTFS-3G unter permissions mit Dateien macht, die nur von Windows mit entsprechenden SID-Rechten versehen wurden, weiß ich auch nicht.

die gehören dann in Linux root:root, und jedermann hat vollen Zugriff.

Wenn mittels NTFS-3G und permissions neue Dateien erzeugt werden, haben die dann keine Windows-kompatiblen Rechte. Was Windows damit macht, ob es die Dateien dann öffnet z.B., weiß ich nicht.

Wenn keine User-Mapping-Datei vorhanden ist oder den betreffenden Linux-Benutzern in der aktuellen User-Mapping-Datei keine SID zugeordnet sind, dann gehören die Dateien in Windows einem "fremden Benutzer", und jedermann hat vollen Zugriff. In dieser Hinsicht (aber nicht beim Einrichten eines User-Mapping) verhalten sich Linux und Windows völlig symmetrisch.

Wenn ich es richtig verstanden haben macht NTFS3 per default etwas ähnliches wie NTFS-3g mit Option permissions aber auf unterschiedliche Weise, weshalb die dann nicht miteinander kompatibel sind.

Wie ntfs3 das macht, weiß ich nicht. Aber das Ergebnis ist zumindest ähnlich.

Doch ich denke, hier handelt es sich mehr um Verständnisfragen als um eine Diskussion des Wiki-Artikels. Dafür wäre dann ein eigener Thread im Support-Bereich sinnvoll.

Max-Ulrich_Farber schrieb:

Was mich überrascht ist, dass ohne von Hand eingetragene udev-Regel, also per Default, gar kein Fallback stattfindet.

Da liegt glaube ich ein kleines Missverständnis vor: Das mit der udev-Regel habe ich nicht getestet, weil es keinen Fallback gab. Fallback hatte ich zudem Zeitpunkt noch gar nicht auf dem Schirm. Das habe ich gemacht, um zu testen, ob man ntfs-3g in der GUI bevorzugen kann, ohne ntfs3 auf die Blacklist setzen zu müssen. Und das geht mit den udev-Regeln.

Was im Abschnitt Windows-Partitionen einbinden/NTFS-3G (Abschnitt „Transparente-Verwendung-in-Ubuntu“) steht, gilt nach wie vor für die Verwendung von mount. Für die GUI gilt das aber nicht.

Bei der GUI oder zumindest bei GUI-Programmen, die udisks2 bzw. udev berücksichtigen, beobachte ich unter Ubuntu 22.04.3 folgendes:

• Ganze ohne Einträge in der fstab hinsichtlich NTFS-Partitionen verwenden z.B. Nautilus und Laufwerke standardmäßig ntfs3

• Ist ein Eintrag für die NTFS-Partition in der /etc/fstab vorhanden, dann wird der von der GUI auch nach Vorgabe entsprechend berücksichtigt

• Setzt man ntfs3 auf die Blacklist, dann verwendet die GUI ntfs-3g

• Setzt man ntfs3 nicht auf die Blacklist, dann sollte man alternativ eine udev-Regel setzen, die ntfs-3g bevorzugt.

Ich muss jetzt mal noch schauen, ob sich Ubuntu 23.10 da anders verhält.

An ntfs-3g ändert das natürlich nichts. Aber es macht die Bedienung unter Umständen erst mal unübersichtlich, solange man das nicht weiß.

Sofern in diesem Artikel auch künftig weiter Einträge in der /etc/fstab aufgeführt werden, würde ich aber aufgrund der Unübersichtlichkeit dazu zu raten den Typ explizit mit ntfs-3g zu benennen, auch wenn man es für mount selbst so nicht benötigt.

Wiki-technisch ist es von der Wartbarkeit grundsätzlich her sinnvoll, Ungereimtheiten, die sich aus der Einführung von ntfs3 für ntfs-3g ergeben, in einen eigenen Artikel zu verlegen und gegebenenfalls von hier nach dort zu verlinken. Dann kann dieser Sonderartikel, den man erfahrungsgemäß für eine mehr oder weniger lange Zeit benötigt, bei Zeiten einfach ins Archiv verschwinden.

LG, Newubunti