staging.inyokaproject.org

@Kb:

Ja, genau so verstehe ich das auch. Und es ist so auch logisch. – @"nicht leere?": Ja, die Zuordnungsdatei darf nicht leer sein und muss dem angegebenen Schema entsprechen. Sie muss sogar mit einem LF ("Leerzeile") abgeschlossen sein, sonst ist sie unwirksam.

Das einzige (noch bestehende) Problem ist IMHO, dass es in man ntfs-3g und auch im NTFS-3 Wiki Aussagen gibt, die zu dieser (unserer) Interpretation offenbar oder scheinbar im Widerspruch sind. Vermutlich war da früher etwas anders, und das Manual ist nicht geändert worden

man ntfs-3g:

 acl       Enable setting Posix ACLs on created files and use them for  ac‐
              cess control.  This option is only available on specific builds.
              It is set by default when a user mapping file is present and the
              permissions mount option is not set.

Das ist IMHO falsch. Immer wird permissions by default gesetzt, und es spielt keine Rolle, ob die mount option permissions gesetzt ist oder nicht. Dagegen ist

 permissions
              Set  standard  permissions on created files and use standard ac‐
              cess control.  This option is set by default when a user mapping
              file is present.

korrekt. Die beiden Aussagen widersprechen einander IMHO.

Auch die lange, schwer verständliche Tabelle in https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions ist IMHO widersprüchlich oder zumindst missverständlich:

Permissions according to ownership, mode and POSIX ACLs (uid, gid, fmask, dmask and umask ignored) 	

    POSIX ACLs selected at compile-time, No permissions, and acl defined OR
    POSIX ACLs selected at compile-time, No permissions, and user mapping file found

Das ist zumindest missverständlich: No permissions ist keine Bedingung dafür, dass dies gilt, sondern es soll heißen even if no permissions are definded … werden Permissions according to ownersip, mode an POSIX ACLs zugrundegelegt. Mit anderen Worten: Es ist völlig egal, ob permissions angegeben ist oder nicht.

Meiner Meinung nach ist NTFS-3G korrekt und in sich logisch, aber das Manual und die Beschreibung sind falsch bzw. missverständlich. Versuchen wir, es besser zu machen! Die Zusammenfassung von Kb ist schon ’mal viel klarer als die ganze Tabelle im NTFS-3G Wiki!

Innerhalb von Linux ist damit wohl alles klar. Die Optionen acl und permissions,acl sind gleichwertig, denn acl impliziert permissions. Was ich noch gerne wüsste ist, ob dies auch bei der Übernahme von Windows-Dateirechten nach Linux genau so gilt. Ich vermute ja, konnte dies aber noch nicht verifizieren. Dazu fehlen mir die Voraussetzungen.

EDIT

Ich habe dazu schon unter https://github.com/tuxera/ntfs-3g/issues/109 eine Support-Anfrage an Tuxera gesandt. Ich hoffe, dabei stellt es sich nicht heraus, dass (wieder einmal) das einzige Problem vor dem Bildschirm sitzt…

Ich habe jetzt ’mal eine Serie von Versuchen mit Dateien, die unter Windows angelegt waren, durchgeführt. Diese umfasst sicher nicht alle Möglichkeiten, doch die Ergebnisse waren nie überraschend oder im Widerspruch zu meinen Vermutungen:

* gio mount ohne UserMapping-Datei, keine Mount-Optionen

drwxrwxrwx 1 farber farber 4096 Apr  4 20:38 Hintergrund
-rwxrwxrwx 1 farber farber 1054603 Mär 21  2013 100_0599.jpg

$ getfacl Hintergrund/
# file: Hintergrund/
# owner: farber
# group: farber
user::rwx
group::rwx
other::rwx

$ setfacl -m u:max:rw Hintergrund/

# file: Hintergrund/
# owner: farber
# group: farber
user::rwx
group::rwx
other::rwx 

Ergebnis: ACL werden nicht gesetzt. Kein uid=$UID by default.

* Mit Fake-UserMapping-Datei, keine Mount-Optionen:

drwxrwxrwx 1 root root 4096 Apr  4 20:38 Hintergrund
-rwxrwxrwx 1 root root 1054603 Mär 21  2013 100_0599.jpg

$ getfacl Hintergrund/
# file: Hintergrund/
# owner: root
# group: root
user::rwx
group::rwx
other::rwx

sudo setfacl -m u:max:r Hintergrund/
[sudo] Passwort für farber: 
setfacl: Hintergrund/: Vorgang wird nicht unterstützt 

Ergebnis: Option acl ist nicht transparent gesetzt!

$ sudo chown farber:farber Hintergrund/
drwxrwxrwx 1 farber farber 4096 Apr  4 20:38 Hintergrund 

Ergebnis: Option permissions ist transparent gesetzt

* mount mit Option permissions, keine UserMapping-Datei

Ergebnis: völlig identisch mit Fake-Usermapping-Datei.

* mount mit echter UserMapping-Datei, ohne Optionen:

drwxrwxrwx 1 root   root  4096 Apr  4 20:38 Hintergrund
drwxrwxrwx 1 farber users    0 Apr  4 20:42 Speech 

Ergebnis: Die Windows-Dateirechte von Hintergrund wurden im default user mapping zerstört! Diejenigen von Speech sind original.

* mount mit UserMapping-Datei und acl:

drwxrwxrwx+ 1 farber users    0 Apr  4 20:42 Speech

$ getfacl Speech/
# file: Speech/
# owner: farber
# group: users
user::rwx
group::rwx
other::rwx

sudo setfacl -m u:max:r Speech/

$ getfacl Speech/
# file: Speech/
# owner: farber
# group: users
user::rwx
user:max:r--
group::rwx
mask::rwx
other::rwx 

* mount mit UserMapping-Datei und permissions,acl:

alles exakt gleich wie mit acl ohne permissions.

Ich meine, man kann nach den Ergebnissen getrost davon ausgehen, dass auch für die Interaktion mit Windows gilt: acl ist identisch mit permissions,acl bzw. acl impliziert permissions. Die Option acl muss immer explizit gesetzt werden, die Aussage

acl        … It is set by default when a user mapping file is present and the
              permissions mount option is not set.

in man ntfs-3g ist falsch.

Ich habe jetzt, glaube ich, inhaltlich zum Thema NTFS-3G nichts Weiteres beizutragen.

Deshalb schlage ich vor, den Artikel jetzt möglichst bald ins Wiki zurück zu schieben, damit dort zum Thema NTFS-3G wenigstens ein inhaltlich korrekter Artikel steht (der bisherige ist das nämlich nicht). Dies scheint mir auch im Hinblick auf den Kernel-Treiber unverzichtbar.

Wenn dann der Übersichtsartikel und der Artikel zum Kernel-Treiber NTFS3 fertig sind, dann kann man sich alle betroffenen Artikel noch einmal vornehmen, diese inhaltlich und stilistisch aneinander anpassen und gut verlinken. Das geht dann hoffentlich schneller, weil die inhaltlichen Fragen dann schon geklärt sind.

kB, könntest Du den Artikel bitte noch hinsichtlich Ausdrucksweise, Syntax und Layout überprüfen bzw. verbessern und dann alles Übrige veranlassen?

Beste Grüße Max-Ulrich

Inzwischen ist mehr als ein Monat vergangen, und es hat sich aus meiner Sicht nichts Neues mehr ergeben. Deshalb möchte ich nun gerne das Thema "NTFS-3G" abschließen. Wenn dann der Übersichtsartikel fertig ist, kann man nötigenfalls immer noch Korrekturen anbringen. Angesichts der Unterschiede zwischen den Treibern NTFS-3G und NTFS3 sollte der "Schwebezustand", dass es im Wiki für keinen der Treiber einen gültigen Artikel gibt, nicht zu lange dauern!

Gruß, M.-U. Farber

Max-Ulrich_Farber schrieb:

Inzwischen ist mehr als ein Monat vergangen […]

Danke für die Erinnerung. Ich war in den letzten Wochen hauptsächlich mit dem Verständnis der Feinheiten des neuen 24.04 beschäftigt. Natürlich habe ich auch das Interesse, den ganzen Komplex „Windows Dateisysteme“ zügig abzuschließen. Mit der formalen Überprüfung (Typos, Links, Formate …) des hiesigen Artikels habe ich begonnen.

Die durch Max-Ulrich_Farber und Newubunti überarbeitete Fassung ist nun im Wiki. Vielen Dank an die Autoren!

Und vielen Dank an kB für die geduldige Unterstützung und die finale Überarbeitung!

Gruß – Max-Ulrich Farber