Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7963
|
Mit der Methode erreicht man, dass Linux-seitig erzeugte Dateien mit NTFS-Vollzugriff für jedermann abgelegt werden. Damit wird allerdings der Schutz durch die Windows-Benutzerrechte ausgehebelt.
Ich verstehe nicht, was dies mit dem statischen Festlegung von umask, UID und GID beim Einbinden von NTFS-Partitionen versus permissions,acl zu tun hat. Dies ist doch unabhängig von der "Methode" immer der Fall, wenn kein User-Mapping festgelegt ist. acl erfordert, dass man auch Linux-seitig ACLs verwendet statt der klassischen Zugriffsrechte
nicht "erfordert", sondern "erlaubt"… Mit permissions werden Linux-seitig erzeugte Dateien unter NTFS-Eigentümer-SIDs abgelegt, die Windows nicht kennt.
und damit hat dann von Windows aus wieder jedermann Zugriff (s.o.) Ohne User-Mapping merken also Windows-Benutzer gar nichts davon, ob Linux-seitig die Option permissions besteht oder nicht. Allgemein gilt doch: Wenn kein User-Mapping stattfindet, dann haben immer alle Benutzer im jeweils anderen Betriebssystem prinzipiell Vollzugriff, in Linux jedoch noch abhängig von den Mount-Optionen umask,uid,gid .
Leider wurde da auch nicht alles berücksichtigt, mein vorgeschlagener Ausweg aus dem Dilemma wurde bisher nicht umgesetzt.
Ich habe den betreffenden Thread kurz überflogen. Es ist klar, dass eine umkehrbar eindeutige Übertragung der Linux-Gruppenstruktur auf Windows-Gruppen oft nicht möglich ist. It is a strong assumption in ntfs-3g that users are organized the same way in Windows and Linux. Otherwise you cannot grant or deny access according to group membership.
Spezielle, zudem nicht gerade einfache Workarounds für Windows-Versionen vor Win-8, sind sicher nicht mehr lohnend. – Doch dies sind reine Probleme des User-Mapping und haben mit den verwendeten Mount-Optionen ("Methode") direkt nichts zu tun. Ich sehe hier also kein Problem der Optionen permissions,acl .
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3021
Wohnort: Köln
|
Max-Ulrich_Farber schrieb: Ich verstehe nicht, was dies mit dem statischen Festlegung von umask, UID und GID beim Einbinden von NTFS-Partitionen versus permissions,acl zu tun hat. Dies ist doch unabhängig von der "Methode" immer der Fall, wenn kein User-Mapping festgelegt ist.
Beim Einbinden per default als auch mit der zusätzlichen statischen Festlegung von umask , UID und GID werden Linux-seitig erzeugte Dateien mit NTFS-Vollzugriff für jedermann abgelegt. Im Fall von permissions , und so weit ich weiß auch von acl , werden pseudo-SIDs mit darauf bezogenen Rechten erzeugt, die Windows nicht bekannt sind. Da dies schwer zu finden ist, habe ich mal einen "Antrag" dazu gepostet. Wenn unter Linux kein Zugriff für die "world"-Bits gesetzt wurde, sind diese Dateien für normale Windows-Benutzer nicht zugreifbar. Zumindest sollte das der Theorie nach so sein: If no interoperation is wanted, and no real user mapping is required, such a generic mapping can be used, either explicitly, or by defining the mount options permissions or acl. Files defined on Linux as readable by anybody will also be readable by any user on Windows.
acl erfordert, dass man auch Linux-seitig ACLs verwendet statt der klassischen Zugriffsrechte
nicht "erfordert", sondern "erlaubt"…
Ja, so ist das genauer beschrieben, doch wüsste ich nicht, welchen Sinn das machen sollte, wenn Linux-seitig keine ACLs verwendet werden. Weiterhin wird die ACL-Unterstützung nicht von den Standard-Binaries unterstützt. Ich schätze, dass die Option acl dann einfach ignoriert wird: The POSIX ACL features are released as a disabled compile-time option in source tarballs. The option is not activated in the compiled versions. They can be enabled by defining the option --enable-posix-acls in the configure command.
Mit permissions werden Linux-seitig erzeugte Dateien unter NTFS-Eigentümer-SIDs abgelegt, die Windows nicht kennt.
und damit hat dann von Windows aus wieder jedermann Zugriff (s.o.) Ohne User-Mapping merken also Windows-Benutzer gar nichts davon, ob Linux-seitig die Option permissions besteht oder nicht.
Nicht wirklich, s.o.
Allgemein gilt doch: Wenn kein User-Mapping stattfindet, dann haben immer alle Benutzer im jeweils anderen Betriebssystem prinzipiell Vollzugriff, in Linux jedoch noch abhängig von den Mount-Optionen umask,uid,gid .
Nicht wirklich bei permissions und acl , s.o.
Leider wurde da auch nicht alles berücksichtigt, mein vorgeschlagener Ausweg aus dem Dilemma wurde bisher nicht umgesetzt.
Ich habe den betreffenden Thread kurz überflogen. Es ist klar, dass eine umkehrbar eindeutige Übertragung der Linux-Gruppenstruktur auf Windows-Gruppen oft nicht möglich ist. It is a strong assumption in ntfs-3g that users are organized the same way in Windows and Linux. Otherwise you cannot grant or deny access according to group membership.
Spezielle, zudem nicht gerade einfache Workarounds für Windows-Versionen vor Win-8, sind sicher nicht mehr lohnend.
Windows 7 wird es wohl noch eine Weile geben, und Volumes, die damit erstellt wurden, wohl noch länger. Ich fände die Erweiterung des Mappings auf 4 Parameter nicht sooo kompliziert. Dies wäre auch für den umgekehrten Fall hilfreich: Windows >=8 und ein Linux-OS, wo nicht GID=UID ist. – Doch dies sind reine Probleme des User-Mapping und haben mit den verwendeten Mount-Optionen ("Methode") direkt nichts zu tun.
Stimmt, doch es ging ja auch um Mehrbenutzer-Umgebungen, da kommt man um UserMapping nicht mehr drum herum.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28947
Wohnort: WW
|
Hallo, kleiner Erinnerung: es geht um die Funktion des Mülleimers - nicht ACLs, Permissions etc für das gesamte Dateisystem. Das ist zwar schön, dass ihr das diskutiert, driftet aber ein wenig von der Ausgangssituation weg. Gruß, noisefloor
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8553
Wohnort: Münster
|
Die Einschätzung in diesem Artikel Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.
halte ich spätestens seit Ubuntu 22.04 mit Kernel 5.15 für zweifelhaft. Es gibt nun 4 für Linux verfügbare Methoden (3 freie und eine kommerzielle) zur Einbindung von NTFS-Dateisystemen. Diese sollten im Artikel thematisiert und verglichen werden oder man muss den Artikel (auch im Titel) einschränken auf einen der verfügbaren Treiber. ntfs-3g ist nicht mehr das neueste, sondern nun ntfs3. (Leider fatale Ähnlichkeit der Namen, welche Supporter noch ärgern wird.) Wieso bei Ubuntu 22.04 mit Kernel 5.15 das Paket ntfs-3g installiert wird, ist mir rätselhaft, jedenfalls sind diffizile funktionale Unterschiede zwischen früheren Kerneln und diesem zu erwarten oder durch Tests nachzuweisen, dass es diese doch nicht gibt. Auch wünschenswert ist eine Beschreibung, wie man gezielt zwischen ntfs3 und ntfs-3g umschalten kann. Sucht bitte jemanden, das das UU-Wiki bezüglich dieses Themenkanons überarbeitet.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28947
Wohnort: WW
|
Hallo,
halte ich spätestens seit Ubuntu 22.04 mit Kernel 5.15 für zweifelhaft.
5.15 ist der Kernel, der OOTB (also mit Bordmitteln ohne externes Modul) NTFS unterstützt, oder? Gruß, nosiefloor
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8553
Wohnort: Münster
|
noisefloor schrieb: […] 5.15 ist der Kernel, der OOTB (also mit Bordmitteln ohne externes Modul) NTFS unterstützt, oder?
Genau. Ab Kernel 5.15 gibt es zusätzlich zu dem alten NTFS-Modul, der nur lesen kann (und den wohl keiner mehr benutzt), einen weiteren ntfs3, welcher die Funktionalität von NTFS-3.1 vollständig unterstützen soll, direkt im Kernel. ntfs-3g ist extern und funktioniert über FUSE. ntfs3 hat natürlich das Potential, schneller, besser und vollständiger zu sein als ntfs-3g. Ob das in der Praxis wirklich so ist, dazu kann ich nichts sagen, und was sich langfristig durchsetzen wird, bleibt ungewiss. Aber die Situation ist nicht mehr so einfach wie vorher.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28947
Wohnort: WW
|
Hallo, tja... das "getestet: general" muss in der Tat weg, weil das halt durch den Kernel 5.15 hinfällig ist. IMHO schleppt der Artikel auch noch ziemlich viele Altlasten mit. Vielleicht wäre es aus heutiger Sicht einfacher, gar keinen Artikel mehr mit dem Titel zu haben (bzw. wenn nur noch als Übersichtsartikel aka Verlinkung auf speziellere Wikiartikel) und dann zu den drei gängigen Windows Dateisystemen NTFS, exFat und FAT einen eigenen Artikel zu haben. BTW: bei mir auf dem Laptop wird die Win-Partition mit NTFS mit fuseblk eingebunden, also über FUSE - wenn ich diese über Nautilus öffne. Wenn man das NTFS3 Modul aus dem Kernel will muss man scheinbar von Hand einbinden - wie auch immer das genau geht. Gruß, noisefloor
|
karzer
Wikiteam
Anmeldungsdatum: 10. April 2022
Beiträge: 1288
Wohnort: Bad Oeynhausen
|
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7963
|
NTFS-3G ist vergleichsweise langsam, weil es über FUSE funktioniert. Wie langsam, kann ich nicht allgemein sagen. Aber es hat mit den Mount-Optionen permissions und acl den großen Vorteil, in LINUX-Mehrbenutzersystemen praktisch wie ein Original Linux-Dateisystem zu funktionieren, und bei Dual-Boot lassen sich mit User-Mapping Windows- und LINUX-Rechte weitgehend synchronisieren. Frage: Lässt sich dies auch mit dem Kernel-Driver NTFS3 irgendwie realisieren? Meines Erachtens ist dies Voraussetzung dafür, dass NTFS3 als vollwertiger Ersatz für NTFS-3G gelten kann.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8553
Wohnort: Münster
|
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7963
|
@kB: Das freut mich sehr, dass du den Artikel überarbeiten willst! - Wir kennen einander ja noch von früher… Ich habe inzwischen ein bisschen mit den Treibern NTFS-3G (mir altbekannt) und NTFS3 herumgespielt, eine externe Partition abwechselnd mit den beiden Treibern eingebunden und dabei vor allem die Verwaltung der UNIX-Dateirechte verglichen. Dabei habe ich einige Beobachtungen gemacht, die ich auch gerne einbringen möchte. Ganz kurz:
Wie ein Treiber für ein Linux-Dateisystem bindet NTFS3 die Partition mit vollständiger UNIX-Rechteverwaltung ein, je nachdem ob die Mount-Option acl gesetzt ist oder nicht, auch mit POSIX-ACLs. Damit entspricht NTFS3 weitgehend NTFS-3G mit den Mount-Optionen permissions und acl
Aber jetzt kommt der große Haken:
Die Rechte-Verwaltungen der beiden Treiber werden gegenseitig nicht anerkannt! Rechte, die mit einem der beiden Treiber (bei NTFS-3G natürlich mit der Option permissions ) gesetzt wurden, werden nicht gefunden und nicht anerkannt, wenn die Partition mit dem jeweils anderen Treiber gemountet ist (eigentlich nicht verwunderlich, aber sehr lästig…) Wie ein user-mapping Linux-Windows (mit NTFS-3G bedingt möglich) mit NTFS3 gehen soll, habe ich nicht gefunden. Ich denke, das geht wohl grundsätzlich nicht (??).
Über die Geschwindigkeit kann ich mit meiner nicht mehr taufrischen Hardware keine Aussagen machen. Ebenso kann ich nichts darüber aussagen, wie schlimm oder nicht schlimm das offenbar eingeschränkte Journaling bei NTFS3 ist, und ob das bei NTFS-3G überhaupt besser ist. Vom Dateisystem exFAT ist in dem Artikel (noch) gar nicht die Rede; es darf aber keinesfalls fehlen. Meines Wissens gibt es da auch beides, einen Kernel-Treiber in neueren Kerneln und einen älteren Treiber über FUSE. Weil es da ja keine Rechte-Verwaltung gibt, ist der einzige wichtige Unterschied wohl die Geschwindigkeit (?). Noch eine allgemeine Anmerkung: Ich würde nicht befürworten, den Artikel nach den verwendeten Dateisystemen aufzuteilen. Ich finde es gut, wenn es einen Übersichtsartikel gibt, der für die Entscheidung, welches Dateisystem man im Einzelfall wählen soll, hilfreich ist.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8553
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: […] Ich habe inzwischen ein bisschen mit den Treibern NTFS-3G (mir altbekannt) und NTFS3 herumgespielt, eine externe Partition abwechselnd mit den beiden Treibern eingebunden und dabei vor allem die Verwaltung der UNIX-Dateirechte verglichen. Dabei habe ich einige Beobachtungen gemacht, die ich auch gerne einbringen möchte. Ganz kurz:
Wie ein Treiber für ein Linux-Dateisystem bindet NTFS3 die Partition mit vollständiger UNIX-Rechteverwaltung ein, je nachdem ob die Mount-Option acl gesetzt ist oder nicht, auch mit POSIX-ACLs. Damit entspricht NTFS3 weitgehend NTFS-3G mit den Mount-Optionen permissions und acl
Aber jetzt kommt der große Haken:
Die Rechte-Verwaltungen der beiden Treiber werden gegenseitig nicht anerkannt! Rechte, die mit einem der beiden Treiber (bei NTFS-3G natürlich mit der Option permissions ) gesetzt wurden, werden nicht gefunden und nicht anerkannt, wenn die Partition mit dem jeweils anderen Treiber gemountet ist (eigentlich nicht verwunderlich, aber sehr lästig…)
Danke für die wichtigen Informationen, die ich in den Artikel einbauen werde. Meines Wissens geht das in der Tat nicht, aber vielleicht kennt jemand anderes ja noch Details hierzu.
Über die Geschwindigkeit kann ich mit meiner nicht mehr taufrischen Hardware keine Aussagen machen.
Ich werde mich jedenfalls auf die Funktionalität beschränken und Benchmarks dann anderen überlassen.
Ebenso kann ich nichts darüber aussagen, wie schlimm oder nicht schlimm das offenbar eingeschränkte Journaling bei NTFS3 ist, und ob das bei NTFS-3G überhaupt besser ist.
Das ist noch zu klären.
Vom Dateisystem exFAT ist in dem Artikel (noch) gar nicht die Rede; es darf aber keinesfalls fehlen. Meines Wissens gibt es da auch beides, einen Kernel-Treiber in neueren Kerneln und einen älteren Treiber über FUSE. Weil es da ja keine Rechte-Verwaltung gibt, ist der einzige wichtige Unterschied wohl die Geschwindigkeit (?).
Ja, einige Hinweise, mindestens auf den bereits existierenden Artikel, gehören auch in diesen Artikel. Bzgl. Geschwindigkeit s.o. Ich bin zufrieden, wenn der Artikel die Grundlagen legt, anderen solche Messungen zu ermöglichen.
Noch eine allgemeine Anmerkung: Ich würde nicht befürworten, den Artikel nach den verwendeten Dateisystemen aufzuteilen. Ich finde es gut, wenn es einen Übersichtsartikel gibt, der für die Entscheidung, welches Dateisystem man im Einzelfall wählen soll, hilfreich ist.
Mein Plan sieht vor, den Artikel in eine allgemeine, von der Ubuntu-Version unabhängige Übersicht zu entwickeln und die konkreten Hinweise zur praktischen Verwendung in testbare Unterartikel zu packen.
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7963
|
kB schrieb:
Ich werde mich jedenfalls auf die Funktionalität beschränken und Benchmarks dann anderen überlassen. … Mein Plan sieht vor, den Artikel in eine allgemeine, von der Ubuntu-Version unabhängige Übersicht zu entwickeln und die konkreten Hinweise zur praktischen Verwendung in testbare Unterartikel zu packen.
Dies finde ich eine sehr sinnvolle und "wartungsfreundliche" Lösung! – Benchmarks sind übrigens auch nicht mein Ding, da spielen so viele Parameter eine Rolle, dass man nur schwer zu wirklich allgemein gültigen Aussagen kommen kann. Wenn ich die Zeit finde (?), möchte ich mich noch etwas eingehender mit dem NTFS3 Kernel-Treiber beschäftigen, sodass man für diesen dann – vielleicht – bald einmal einen eigenen Artikel verfassen kann. Bei exFAT ist die Koexistenz zweier Treiber wesentlich weniger problematisch als bei NTFS, da es dort offenbar keine Unterschiede in der Funktionalität und keine Probleme der Rechteverwaltung gibt. EDIT: Oh, so einfach scheint es bei exFAT offenbar auch nicht zu sein! Beide Treiber scheinen nicht die gleichen Mount-Optionen zu vertragen oder verschieden auf diese zu reagieren. Siehe dazu https://askubuntu.com/questions/1484064/new-kernel-and-exfatprogs-do-not-support-same-mount-options-as-exfat-utils. Ist anscheinend eine Untersuchung wert!
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7963
|
@ kB: Wie wäre es mit folgendem Vorgehen:
Du übernimmst entsprechend deinem Plan den Umbau des Artikels "Windows-Partitionen einbinden" in eine allgemeine, von der Ubuntu-Version unabhängige Übersicht, und die Auslagerung von Einzelheiten in Einzelartikel, die ja zum Teil bereits bestehen. Ich kümmere mich um den Artikel "exFAT", der gründlich überarbeitet gehört. Dies dürfte überschaubar sein. Beim Artikel "NTFS-3G", der ja zum großen Teil von mir stammt, lassen wir es bei dem kurzen Hinweis auf den Kernel-Treiber NTFS3. Bei dem Artikel selbst sehe ich im Moment wenig Handlungsbedarf, weil sich an NTFS-3G seither nichts Wesentliches geändert hat. Mit einem Artikel für den Kernel-Treiber NTFS3 lassen wir uns noch etwas Zeit um die in Internet-Blogs aufgetretenen Probleme oder Missverständnisse auszuwerten. Bei Ubuntu sind die Erfahrungen mit dem Treiber bis jetzt spärlich. Zu FAT gibt es nicht viel Neues zu sagen. Der Zugriff auf Linux-Partitionen von Windows aus ist nicht unser Thema; trotzdem wäre vielleicht ein Hinweis angebracht, dass dies (bedingt) auch möglich ist.
Gruß, Max-Ulrich EDIT: könntest Du mir bitte den Artikel "exFAT" in die Baustelle verschieben? Danke!
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8553
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: […]
Du übernimmst entsprechend deinem Plan den Umbau des Artikels "Windows-Partitionen einbinden" in eine allgemeine, von der Ubuntu-Version unabhängige Übersicht, und die Auslagerung von Einzelheiten in Einzelartikel, die ja zum Teil bereits bestehen.
OK
Gerne.
Beim Artikel "NTFS-3G", der ja zum großen Teil von mir stammt, lassen wir es bei dem kurzen Hinweis auf den Kernel-Treiber NTFS3. Bei dem Artikel selbst sehe ich im Moment wenig Handlungsbedarf, weil sich an NTFS-3G seither nichts Wesentliches geändert hat.
Ein aus meiner Sicht wichtiges Thema: Vertragen sich die beiden Module? Übersehe ich aber im Moment noch nicht.
Das ist bereits vorbereitet im Artikel Baustelle/NTFS3, in den ich erst einmal den kompletten alten Text aus Windows-Partitionen einbinden kopiert habe. Das wird nicht so bleiben, auch der Titel ist vorläufig.
Ein Artikel zu Kernel Modul vfat und dessen Konfiguration wäre nett, ist aber sicherlich nicht die dringendste Thematik.
Dazu gibt es bereits den Artikel Linux-Partitionen unter Windows.
|