staging.inyokaproject.org

Max-Ulrich_Farber schrieb:

Auch wenn es mich manchmal aufgeregt hat, bin ich dir, UlfZibis, jetzt doch dankbar, dass du so hartnäckig dran geblieben bist und nicht einfach klein beigegeben hast. Denn nur so wurde ich heftig genug auf die Problematik des Begriffs "Mapping" aufmerksam gemacht, "mit der Nase darauf gestoßen". Danke! . Das ist ehrlich gemeint.

Oh das ist schön, das mal so zu lesen, heilt die "Wunden" manch deftiger Negativ-Kritik. Ganz ehrlichen Dank auch von mir.

Newubunti schrieb:

UlfZibis schrieb:

Unklar ist mir dabei noch, wie bei permissions der Besitz gemappt wird, da auf Windows-Seite ja "Administratoren" als Besitzer eingetragen wird.

Das hatte ich aus Deinem Kommentar geschlossen. Jetzt sehe ich meine Fehlinterpretation.

Administratoren wird von wo aus eingetragen?

Von NTFS-3G aus, doch wie ich jetzt sehe, passiert das ja nur, wenn gar keine Option und kein "UserMapping" existieren.

Danke für die Kritik und ich bitte um Verzeihung für die Verwirrung.

kB schrieb:

Newubunti schrieb:

[…] Da das ein errechenbares Schema ist

Nein, das ist nicht berechenbar, sondern in Deinem Fall (hoffentlich weltweit) einmalig so.

Ich habe mich zwar auch nicht 100% präzise ausgedrückt, allerdings hast Du meine Aussage jetzt vollständig aus dem Zusammenhang gerissen.

Ich habe im übrigen auch nicht geschrieben, dass eine SID erzeugt auf einem Windows-Computer auf einem Linux-Computer von ntfs-3g berechenbar wäre, sondern ich habe darüber geschrieben, wie ntfs-3g auf ein und demselben Computer ohne UserMapping-Datei eine von ntfs-3g zuvor auf diesem Computer erzeugte und in das NTFS-Datei-System eingetragene SID auf diesem Computer bei erneutem Zugriff auf eine uid berechnen und umsetzen kann und welches Schema ich dabei beobachtet habe.

Dafür sind in meinem Beispiel die letzten fünf Ziffern der SID von Belang.

Wer anderes beobachtet, kann das gerne zur Diskussion stellen, so wie ich meine Beobachtungen auch immer zur Diskussion stelle.

Aber Dein Hinweis auf https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/understand-security-identifiers spielt dafür nur sehr bedingt eine Rolle, weil die Betrachtung sich wie gesagt auf einen Computer beschränkt.

Die ganze Diskussion hier von UlfZibis und Max-Ulrich_Farber dreht sich die ganze Zeit im wesentlichen um die Betrachtung ohne einen weiteren Windows-Computer, sondern es geht erst mal nur um das Mapping von Linux aus auf das NTFS-Dateisystem.

LG, Newubunti

EDIT:

UlfZibis schrieb:

Newubunti schrieb:

UlfZibis schrieb:

Unklar ist mir dabei noch, wie bei permissions der Besitz gemappt wird, da auf Windows-Seite ja "Administratoren" als Besitzer eingetragen wird.

Das hatte ich aus Deinem Kommentar geschlossen. Jetzt sehe ich meine Fehlinterpretation.

Administratoren wird von wo aus eingetragen?

Von NTFS-3G aus, doch wie ich jetzt sehe, passiert das ja nur, wenn gar keine Option und kein "UserMapping" existieren.

Alles gut, ich hatte mir schon fast gedacht, dass da das "Problem" liegt. Aber das ganze ist eben auch recht komplex, weswegen ich die Idee einer Übersichtstabelle, nach wie vor für nicht schlecht halte.

Und wie gesagt, die Tabelle wäre diesbezüglich auch sicher noch deutlich optimierbar.

Weder die Tabelle allein noch der Text des Artikels sind dabei IMO "Wunderwaffen", die ganz für sich alleine alles erklären. Aber in Kombination oder auch, weil unterschiedliche Leser unterschiedliche Arten von Auffassungsgaben haben, wäre es IMO hilfreich.

LG, Newubunti

Max-Ulrich_Farber schrieb:

Der Begriff könnte aber auch mit dem Verfahren von NTFS3 als vergleichbar angesehen und verwechselt werden, wo das Mapping ja tatsächlich per default stattfindet. ...

Das stimmt so nicht. Bei NTFS3 wird gar nichts gemappt. Das habe ich untersucht und auch mit einer Bildschirm-Kopie aus Windows aufgezeigt. Es gibt in Windows für die Linux-Benutzer keine SID, die Linux-Dateien sind in Windows völlig herrenlos. Bei NTFS3 findet also überhaupt kein User-Mapping statt, nicht default und nicht mit Vorgaben.

Wie Newubunti nun bestätigt, findet auch bei NTFS3 ein "Mapping" des Datei-Besitzers (Owner) statt, und zwar zwischen uid / gid und "Extended Attributes" (EA) von Windows. Ich hätte mir auch nicht vorstellen können, wie es ohne funktionieren könnte, und hatte deshalb einfach mal grob ein "Mapping" von irgendwelchen Bits in die NTFS-Dateisystem-Struktur in den Raum gestellt. Diese Struktur ist nun ausfindig gemacht worden.

Gruß Ulf

kB schrieb:

Nein, das ist nicht berechenbar, sondern in Deinem Fall (hoffentlich weltweit) einmalig so.

Ich sehe das genau wie Newubunti: Das Schema ist, solange man keine UserMapping-Datei verwendet, immer das gleiche: Bis auf die letzten fünf Ziffern wird immer und in jedem Linux-System mangels anderer Idee die Ziffernfolge der Kreiszahl PI verwendet. Deshalb bleibt das sog. "Default-User-Mapping" hinsichtlich Linux-Systeme kompatibel. Diese Kompatipilität geht aber bei einem mittels UserMapping-Datei an ein ganz bestimmtes Windows-System gebundenen User-Mapping verloren.

Den Ausdruck "berechenbar" für die SID im sog. default user mapping finde ich gar nicht schlecht, obwohl die vorderen Ziffern, die Ziffern der Kreiszahl PI, natürlich nicht berechnet, sondern lediglich "abgeschrieben" werden. Aber sie sind eben immer die gleichen, bei jedem default user mapping in jedem Linux-System. Eben gerade nicht "weltweit einmalig".

Ich hoffe, wir verstehen uns nicht schon wieder falsch. Doch hierauf will bzw. muss ich im Artikel dann noch gebührend eingehen. Aber so weit bin ich noch gar nicht.

Newubunti schrieb:

wie ntfs-3g auf ein und demselben Computer ohne UserMapping-Datei eine von ntfs-3g zuvor auf diesem Computer erzeugte und in das NTFS-Datei-System eingetragene SID auf diesem Computer bei erneutem Zugriff auf eine uid berechnen und umsetzen kann und welches Schema ich dabei beobachtet habe.

Das kann man noch allgemeiner sagen: Nicht nur "auf diesem Computer", sondern "auf jedem Computer"

Dafür sind in meinem Beispiel die letzten fünf Ziffern der SID von Belang.

Wer anderes beobachtet, kann das gerne zur Diskussion stellen, so wie ich meine Beobachtungen auch immer zur Diskussion stelle.

Ich würde ja gerne darüber diskutieren, aber IMO hast du halt ganz einfach Recht…

Und beim mittels UserMap-Datei an ein ganz bestimmtes Windows-System "gebundenen" User-Mapping werden halt die stereotypen Ziffern der Kreiszahl PI gegen die "weltweit einmalige" Ziffernfolge einer ganz bestimmten Windows-SID ausgetauscht. Kleiner Unterschied mit großer Auswirkung!

Weder die Tabelle allein noch der Text des Artikels sind dabei IMO "Wunderwaffen", die ganz für sich alleine alles erklären. Aber in Kombination oder auch, weil unterschiedliche Leser unterschiedliche Arten von Auffassungsgaben haben, wäre es IMO hilfreich.

Das wäre wirklich ideal. Mal sehen, ob wir das hinkriegen!

Die ganze Diskussion hier von UlfZibis und Max-Ulrich_Farber dreht sich die ganze Zeit im wesentlichen um die Betrachtung ohne einen weiteren Windows-Computer, sondern es geht erst mal nur um das Mapping von Linux aus auf das NTFS-Dateisystem.

Ganz genau! Das hast Du sehr zutreffend ausgedrückt! Allerdings würde ich bei "NTFS-Dateisystem" noch Bedenken äußern: NTFS bietet offenbar (frag mich bitte nicht wie) noch andere Möglichkeiten an, Dateirechte persistent zu speichern, als die SID. Denn NTFS3 tut dies, lässt aber dabei die SID offenbar unberührt. Ich kann mir vorstellen, weiß dies aber nicht, dass es vielleicht innerhalb von NTFS durchaus auch noch Orte gibt, an denen UID &Co nativ, d.h. nicht auf eine fremde Datenstruktur gemappt, persistent festgehalten werden könnten. Die Windows-SID also mit dem Dateisystem NTFS zu identifizieren ist wohl deshalb schon wieder eine missverständliche Sprechweise…

L.G.

Max-Ulrich_Farber schrieb:

Allerdings würde ich bei "NTFS-Dateisystem" noch Bedenken äußern: NTFS bietet offenbar (frag mich bitte nicht wie) noch andere Möglichkeiten an, Dateirechte persistent zu speichern, als die SID. Denn NTFS3 tut dies, lässt aber dabei die SID offenbar unberührt. Ich kann mir vorstellen, weiß dies aber nicht, dass es vielleicht innerhalb von NTFS durchaus auch noch Orte gibt, an denen UID &Co nativ, d.h. nicht auf eine fremde Datenstruktur gemappt, persistent festgehalten werden könnten. Die Windows-SID also mit dem Dateisystem NTFS zu identifizieren ist wohl deshalb schon wieder eine missverständliche Sprechweise…

Siehe meinen vorigen Beitrag ...

Oh danke, den angegebenen Post von Newubunti hatte ich noch gar nicht gelesen. Sorry. Aber er ist auf jeden Fall höchst interessant und informativ! Eigentlich eine Frage, die mich schon lang bewegt.

Da werden manche meiner Vermutungen hinfällig.

Ich habe inzwischen an dem Artikel einige wesentliche Änderungen vorgenommen:

• Um den Artikel nicht mit Warnungen vollzupflastern habe ich einige straffer gefasst und unspezifische Warnungen an den Übersichsartikel "vermittelt"

• Die von UlfZibis als übertrieben beanstandete Warnung vor dem parallelen Benutzen beider Treiber habe ich in einen Hinweis umgewandelt

• Dafür habe ich eine gezieltere kurze Warnung bei den persistenten Dateirechten eingefügt

• Die extrem ausführliche Warnung unter "Probleme und Lösungen" geht auch zum Übersichtsartikel

Um den Artikel etwas zu straffen, habe ich 2 weitere Tabellen verwendet.

Die "Standard-Einstellungen" ziemlich am Anfang muss ich neu recherchieren und formulieren. Diese sind so leider noch fehlerhaft.

Mit den Symlinks-Softlinks-Junctions usw. will ich mich nicht weiter befassen. Wenn das unbedingt sein muss (??), dann soll es jemand anderes machen. Aber bitte ja nicht zu ausführlich! IMHO würde das, was schon im Artikel steht, eigentlich ausreichen.

Newubunti wollte gerne die Tabelle aus dem NTFS-3G Wiki zur besseren Übersicht noch zusätzlich einfügen. Die Idee finde ich nicht schlecht, doch es gelingt mir nicht, die Tabelle knapp zu fassen und auf das Wesentliche zu reduzieren. In der in der Diskussion dargestellten Form ist sie aber IMHO zu umfangreich und zu komplex und würde deshalb nichts einfacher machen. Vielleicht gelingt es Newubunti besser? Sonst lassen wir die Tabelle lieber doch weg.

Im übrigen würde ich gerne bald mit NTFS-3G zum Schluss kommen, weil ich nach den Erkenntnissen von Newubunti nun doch zu der Ansicht tendiere, dass das einfachere und zumindest für Einsteiger durchsichtigere Konzept von NTFS3 auf die Dauer die besseren Karten hat.

L.G.

EDIT:

Ich habe jetzt doch eine solche Tabelle erstellt, allerdings in verkürzter Form und ohne Anspruch auf Vollständigkeit auf die "normalen" Fälle beschränkt (steht auch da). Die Tabelle habe ich dann am Ende vom eigentlichen NTFS-3G, aber noch vor "weitere Optionen" und "Verknüpfungen" und vor den Hilfsprogramen von ntfsprogs, als Rückblick bzw. Orientierungshilfe eingeschoben. Newubunti, entspricht dies ungefähr deinen Vorstellungen? Eine noch stärker differenzierende Tabelle würde IMHO hier den Rahmen sprengen.

EDIT 2:

Jetzt habe ich noch ein Problem, das ich allein nicht lösen kann:

• ich habe 2 Laptops und verwende auf beiden den gleichen USB-Stick:

  1. Xubuntu 22.04, Kernel 6.05

  2. Xubuntu 22.04, Kernel 5.15, Dual Boot mit Win 10 pro

• auf beiden Laptops ist NTFS3 blacklisted

• auf keinem Laptop habe ich udisksctl.conf verändert

• auf keinem Laptop habe ich einen vorbereitenden fstab-Eintrag für den Stick erstellt

• der Stick enthält keine Datei .NTFS-3G/UserMapping

• der Stick wurde ordnungsgemäß ausgeworfen

• User farber ist auf beiden Laptops in der Gruppe sudoers.

Ich stecke als User farber den gleichen USB-Stick unter Xubuntu in beide Laptops ein (Hotplug) und erhalte unterschiedliche Standard-Einstellungen:

1. Besitzer farber:farber, mode 0777 (jeder Vollzugriff, auch x)

2. Besitzer root:root, mode 0777 (jeder Vollzugriff, auch x)

Der Einhängeort ist immer /media/farber.

Beim Einhängen mit Mausklick oder Gigolo (= gio mount) ist alles gleich wie bei Hotplug.

Bitte untersucht bei euch noch, wie sich NTFS-3G standardmäßig verhält. Ich könnte mir vorstellen, dass sich von Kernel 5.15 auf 6.05 etwas in udisks2 verändert hat. Dann kann ich bald auch noch die Standard-Einstellungen fertig machen.

Beste Grüße!

P.S. Vielleicht wäre ein solcher Vergleich auch bei exFAT und NTFS3 angebracht?

Max-Ulrich_Farber schrieb:

Ich habe inzwischen an dem Artikel einige wesentliche Änderungen vorgenommen: ...

Die folgende Warnung kann man wie folgt kürzer fassen, weil das im Wiki in z.B. Dualboot (Abschnitt „Windows-Schnellstart“) schon abgehandelt ist:

Die "Standard-Einstellungen" ziemlich am Anfang muss ich neu recherchieren und formulieren. Diese sind so leider noch fehlerhaft.

Brauchen wir das so überhaupt? Ich tue mich hier schon mit dem Begriff "Standard" schwer. Welcher soll das sein, bei GUI-Nutzung, bei Nutzung von sudo mount ... ohne Optionen?

Im Artikel im Abschnitt Baustelle/Windows-Partitionen einbinden/NTFS-3G (Abschnitt „Eigenschaften-im-fremden-Dateisystem“) würde ich ein wenig anders formulieren:

Greift man in einem Windows-System auf eine NTFS-Partition zu, auf der in einem Linux-System mit dem sog. default_user_mapping Dateien angelegt wurden, dann erfolgt das Mapping wie folgt:

• Es wird je ein ACE für die Standard-Windows-Gruppen Administratoren und System mit jeweils allen Rechten außer Vollzugriff angelegt.

• Es wird ein ACE für die Standard-Windows-Gruppe Jeder erzeugt. Dabei werden die Linux-Rechte der Linux Gruppe Andere auf die NTFS-Berechtigungen der Windows-Gruppe Jeder gemappt.

• Es wird mindestens ein ACE für den Linux-Datei-Besitzer erzeugt. Dabei erzeugt NTFS-3G einen SID, der in Windows nicht verwendet wird, so dass es zu keiner Kollision von NTFS-3G erzeugter SID und den in Windows benutzten SID kommen kann. Dementsprechend erscheint in Windows der von NTFS-3G erzeugte SID als Unbekanntes Benutzerkonto. Die Linux-Rechte des Linux-Datei-Besitzers, werden auf die NTFS-Berechtigung des unbekannten Benutzerkontot gemappt.

• Es wird mindestens ein ACE für die Linux-Datei-Gruppe erzeugt. Dabei erhält die Gruppe einen eigenen SID. Es gilt sonst das gleiche, wie im vorigen Punkt für den Linux-Datei-Besitzer geschrieben.

• Der für den Linux-Datei-Besitzer erstellte SID wird als NTFS-Datei-Besitzer eingetragen.

• Der für die Linux-Datei-Gruppe erstellte SID wird als NTFS-Datei-Gruppe eingetragen.

In umgekehrter Richtung ist es jedoch einfacher: Durch das sog. default user mapping werden die unter Windows erstellten Dateien unbeachtet Ihrer durch ACE festgelegten Zugriffs-Berechtigungen unter Linux dem Besitzer und der Gruppe root mit den Rechten rwx zugewiesen. Außerdem erhalten Andere ebenfalls die Rechte rwx.

Ich stecke als User farber den gleichen USB-Stick unter Xubuntu in beide Laptops ein (Hotplug) und erhalte unterschiedliche Standard-Einstellungen, die zudem noch beide nicht mit den Angaben von Newubunti übereinstimmen:

Meinst Du damit diesen Absatz aus dem Abschnitt Baustelle/Windows-Partitionen einbinden/NTFS-3G (Abschnitt „Temporaeres-Einbinden-mittels-grafischer-Benutzeroberflaeche“)?:

Standardmäßig wird die betreffende Partition in ein Verzeichnis unterhalb von /media/$USER privat - d.h. nur für den Benutzer der den Klick ausgeführt hat zugänglich - in den Dateibaum gehängt. Einhängepunkt sowie weitere Optionen werden dabei in aller Regel von udisks2 vorgegeben und können bei Bedarf ab Ubuntu 22.04 geändert werden.

Falls ja, dann geht es in diesem Abschnitt um das Einhängen, was von den Datei-Zugriffsrechten abstrahiert behandelt werden muss. Und privat ist hier konkret das Verzeichnis automatisch von udisks angelegte Verzeichnis /media/$USER. Das Verzeichnis /media/$USER/Label-der-NTFS-Partition ist genau genommen nicht privat, sondern je nach dem mit den Modes, wie von Dir beschrieben. Nur faktisch sind die Dateien unterhalb von /media/$USER für andere Benutzer auf dem System standardmäßig nicht zugänglich.

Ich würde in diesem Abschnitt im Artikel auch nicht so gerne auf die Datei-Zugriffsrechte eingehen, aber man kann den Absatz sicher noch etwas klarer formulieren, z.B.:

Standardmäßig wird die betreffende Partition in ein Verzeichnis unterhalb von /media/$USER eingebunden. Dabei ist das Verzeichnis /media/$USER nur für das Benutzerkonto $USER zugänglich, so dass andere Benutzer auf darunter eingebundene Dateisysteme - wie auch die NTFS-Partition - keinen Zugriff haben.

LG, Newubunti

@Max-Ulrich_Farber,

Ich habe nicht alle 30 Seiten gelesen, aber evtl. wurde darüber noch nicht gesprochen :

The following reserved characters:

    < (less than)
    > (greater than)
    : (colon)
    " (double quote)
    / (forward slash)
    \ (backslash)
    | (vertical bar or pipe)
    ? (question mark)

Sobald ich einen Eintrag in fstab habe, wie z.B.:

...
UUID=9230D55130D53D43    /media/mnt/Samsung_2T_Ext      ntfs-3g         defaults,nls=utf8,umask=0000,nofail  0       0
...

verhindert Nautilus nicht mehr das kopieren von Dateien mit "verbotenen" Zeichen im Dateinamen.

Das führt selbstverständlich dazu, dass Windows dann einen Fehler auf der HDD erkennt, die Datei umbenennt und die Fat korrigiert.

Aus meiner Sicht sollte man das zumindest ansprechen.

Max-Ulrich_Farber schrieb:

EDIT:

Ich habe jetzt doch eine solche Tabelle erstellt, ... Newubunti, entspricht dies ungefähr deinen Vorstellungen? Eine noch stärker differenzierende Tabelle würde IMHO hier den Rahmen sprengen.

Ja, das entspricht in etwa meinen Vorstellungen. Allerdings würde ich ein paar kleine Korrekturen anbringen:

LG, Newubunti

Newuunti schrieb:

Brauchen wir das so überhaupt? Ich tue mich hier schon mit dem Begriff "Standard" schwer. Welcher soll das sein, bei GUI-Nutzung, bei Nutzung von sudo mount ... ohne Optionen?

Der Abschnitt ist im Artikel nun 'mal da, und er ist definitiv falsch oder wenigstens nicht mehr richtig. Da besteht "Handlungsbedarf"… Wenn meine Beobachtungen allgemein stimmen, ist das Thema allerdings praktisch wenig relevant, da ja unabhängig vom Besitzer jeder Vollzugriff hat. Das Thema ist allerdings evtl. im Blick auf udisks2 von Bedeutung: Wer ist Eigentümer des Einbinde-Prozesses?

Die folgende Warnung kann man wie folgt kürzer fassen, weil das im Wiki in z.B. Dualboot (Abschnitt „Windows-Schnellstart“) schon abgehandelt ist:

Ich habe die Warnung (früher unter "Probleme und Lösungen" am Ende des Artikels) bereits erheblich gekürzt. Es ist richtig, dass sie in Dualboot bereits abgehandelt ist. Trotzdem würde ich sie gerne hier so belassen, weil NTFS-3G nach wie vor der meist benützte Dualboot-Treiber ist.

… die zudem noch beide nicht mit den Angaben von Newubunti übereinstimmen:

Sorry, war ein Missverständnis. Habe ich gemerkt und wieder herausgenommen.

Ja, das entspricht in etwa meinen Vorstellungen. Allerdings würde ich ein paar kleine Korrekturen anbringen:

Ach, es geht wieder 'mal um das heiß und lang diskutierte default user mapping. Es ist halt definitiv das schwierigste und am schwierigsten zu verstehende Kapitel. Wenn du meinst, die Präzisierungen sind nötig und hilfreich, kannst du sie gerne in der Tabelle vornehmen. – Ich habe die Präzisierungen bewusst weggelassen, denn was in Windows geschieht ist IMHO nicht unser wichtigstes Thema. Dort kann jeder Eigenschaften-Sicherheit… aufrufen und selbst nachschauen. Wichtig ist IMHO hier nur: In Windows werden Rechte berücksichtigt und es hat nicht automatisch jeder Vollzugriff.

Im Artikel im Abschnitt Baustelle/Windows-Partitionen einbinden/NTFS-3G (Abschnitt „Eigenschaften-im-fremden-Dateisystem“) würde ich ein wenig anders formulieren:

Auch da geht es wieder ums default user mapping. Im Grunde gilt da auch das, was ich für die Tabelle gesagt habe.

@Gloster

Ich habe nicht alle 30 Seiten gelesen, aber evtl. wurde darüber noch nicht gesprochen :

Implizit wurde es beim Thema windows_names schon angesprochen, doch es hat im Artikel noch keinen Niederschlag gefunden. Eigentlich gehört das Thema wohl eher in den Übersichtsartikel, da es genau so auch für den Kernel-Treiber NTFS3 von Bedeutung ist. Aber eine kurze Erwähnung ist sicher auch hier angebracht. Danke für den Hinweis!

Ich habe jetzt die "Default-Einstellungen" gekürzt und aktualisiert. Dann bin ich noch über den ganzen Artikel 'mal drüber gegangen und habe einige Kleinigkeiten (hoffentlich) verbessert. Etwas "Feinschliff" wird sich bestimmt bei jedem Durchlesen noch ergeben.

Newubunti, schaue bitte, ob ich Deine Ergänzungen richtig eingearbeitet habe, und vor allem, ob jetzt alles korrekt und möglichst auch verständlich ist.

Auf das "private" Einhängen in /media/$USER würde ich hier nicht besonders eingehen, es gehört wohl eher nach udisks. An sich ist es ganz einfach: Die UNIX-Dateirechte erlauben nur root:root den Zugriff, aber ein ACL noch zusätzlich $USER.

Dann wäre ich wohl jetzt "fürs Erste" mal fertig. Es war um einiges mehr Arbeit als ich gedacht hatte…

Viele Grüße

Max-Ulrich

Hallo Max-Ulrich_Farber,

inwieweit hast Du mit der Option acl experimentiert? Denn bei meinem Testsystem (Ubuntu 22.04.4, Kernel 6.5.0.27) stelle ich im Moment einige Abweichungen zu den Erklärungen im Artikel fest. Da dies mehrere Abschnitte betrifft, wollte ich vorab kurz abklären, ob Du die Option näher untersucht hast oder die eigentlich selbst gar nicht nutzt?

Abweichend ist bei mir z.B. schon mal - und das ist auch gegenüber man ntfs-3g abweichend - dass bei vorhandener .NTFS-3G/UserMapping und mounten ohne Angaben von Optionen mit z.B.

sudo mount -t ntfs-3g /dev/vdb1 /media/ntfs 

acl gar nicht standardmäßig verwendet wird.

Weitere Abweichung zum Artikel ist, dass die Befehle chown und chgrp beim User Mapping mittels .NTFS-3G/UserMapping und gesetzter Option acl bei mir nicht wie gewohnt funktionieren.

Auch das Setzen von ACL für Gruppen funktioniert bei meinem Testsystem nicht. Da erhalte ich eine Das Argument ist ungültig. Fehlermeldung von z.B. einem setfacl -m g:ntfsusers:rwx /media/ntfs/dir-ntfs3g-test-01. Auch hier wieder für den Fall, dass eine .NTFS-3G/UserMapping vorhanden ist.

Jetzt wäre zunächst mal die Frage, ob das alles nur bei mir so ist?

LG, Newubunti

@Newubunti

Nein, die Option acl habe ich kaum benutzt. Ich habe im wesentlichen abgeschrieben, was im Handbuch steht.

Das sieht ganz danach aus, wie wenn du eine ohne ACL kompilierte Version von NTFS-3G hättest. Stammt deine Version aus den Paketquellen oder hast du eine aktuellere Version nachinstalliert?

Morgen habe ich leider keine Zeit, aber übermorgen kann ich mich damit befassen.

LG, Max-Ulrich

Max-Ulrich_Farber schrieb:

Das sieht ganz danach aus, wie wenn du eine ohne ACL kompilierte Version von NTFS-3G hättest. Stammt deine Version aus den Paketquellen oder hast du eine aktuellere Version nachinstalliert?

Nein, das ist ganz normal die mit der Ubuntu-Installation zusammen installierte Version aus den Ubuntu-Paketquellen.

Was ich noch vergessen zu erwähnen hatte: Mit dem Default User Mapping im Zusammenspiel mit der Option acl - also ohne .NTFS-3G/UserMapping - kann ich acl für alle möglichen Benutzer und Gruppen setzen.

Aber mit .NTFS-3G/UserMapping und der Option acl habe ich die beschriebenen Problem mit dem Setzen von ACL-Einträgen.

Die .NTFS-3G/UserMapping sieht dabei so aus:

1000:1000:S-1-5-21-100139866-1955529089-4104550190-1001
1002:1002:S-1-5-21-100139866-1955529089-4104550190-1002
1003:1003:S-1-5-21-100139866-1955529089-4104550190-1003
:100:S-1-5-32-545

Und das Mounten erfolgte konkret mit:

sudo mount -t ntfs-3g -o acl /dev/vdb1 /media/ntfs 

Dann anlegen eines Verzeichnisses mittels:

mkdir /media/ntfs03/dir-test-01 

Und dann

setfacl -m u:test01:rwx /media/ntfs03/dir-test-01
setfacl: /media/ntfs03/dir-test-01: Vorgang nicht zulässig 

und schließlich

sudo setfacl -m u:test01:rwx /media/ntfs03/dir-test-01
setfacl: /media/ntfs03/dir-test-01: Das Argument ist ungültig 

Beim Default User Mapping geht der letzte Befehl dagegen durch und setzt den ACL-Eintrag.

LG, Newubunti

EDIT:

Inzwischen habe ich herausgefunden, dass zumindest der Fehler Das Argument ist ungültig auf den Gruppen-Eintrag in der .NTFS-3G/UserMapping :100:S-1-5-32-545. Allerdings weiß ich noch nicht, wie der sonst aussehen soll.