staging.inyokaproject.org

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.

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.

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

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.

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

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.

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

Nun ungetestet.