staging.inyokaproject.org

Ich habe jetzt einen Strace von der Situation, bei der meine Ausgangssituation um den folgenden Eintrag in der /etc/fstab ergänzt wurde:

# /dev/vdb1 NTFSTEST mount to /media/ntfs
UUID=362F9B1C209845D1	/media/ntfs	ntfs-3g	defaults,noauto,users,windows_names,hide_dot_files	0	0

Diese Situation entspricht der, wegen der UlfZibis seinen Support-Thread eröffnet hatte, d.h. ein

udisksctl mount -b /dev/vdb1 

scheitert mit der Fehlermeldung

Error mounting /dev/vdb1: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting system-managed device /dev/vdb1: Unknown error when mounting /media/ntfs

Der gefilterte strace von udisksd sieht dabei so aus (Hinweis: Hier habe ich der Übersicht wegen die strace-Option -z verwendet):

ammy@jammyvm01:~$ grep -Ei 'fstab|mount|fuse|ntfs|polkit' udisksd-jammy-z-fstab-ntfs-3g-strace.txt 
2072  16:51:46.322668 openat(AT_FDCWD, "/var/lib/udisks2/mounted-fs-persistent", O_RDONLY) = 16
2072  16:51:46.323894 newfstatat(AT_FDCWD, "/etc/fstab", {st_mode=S_IFREG|0664, st_size=804, ...}, 0) = 0
2072  16:51:46.324036 openat(AT_FDCWD, "/etc/fstab", O_RDONLY|O_CLOEXEC) = 16
2072  16:51:46.324300 read(16, "# /etc/fstab: static file system information.\n#\n# Use 'blkid' to print the universally unique identifier for a\n# device; this ma"..., 4096) = 804
2072  16:51:46.324683 openat(AT_FDCWD, "/proc/self/mountinfo", O_RDONLY) = 16
2072  16:51:46.328908 newfstatat(AT_FDCWD, "/media/ntfs", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
2073  16:51:46.346030 newfstatat(AT_FDCWD, "/etc/fstab", {st_mode=S_IFREG|0664, st_size=804, ...}, 0) = 0
2073  16:51:46.346274 openat(AT_FDCWD, "/etc/fstab", O_RDONLY|O_CLOEXEC) = 16
2073  16:51:46.346516 read(16, "# /etc/fstab: static file system information.\n#\n# Use 'blkid' to print the universally unique identifier for a\n# device; this ma"..., 4096) = 804
2073  16:51:46.361244 newfstatat(AT_FDCWD, "/sbin/mount.ntfs-3g", {st_mode=S_IFREG|0755, st_size=162824, ...}, 0) = 0
2073  16:51:46.361544 newfstatat(AT_FDCWD, "/run/mount/utab", {st_mode=S_IFREG|0644, st_size=998, ...}, AT_SYMLINK_NOFOLLOW) = 0
2073  16:51:46.361642 newfstatat(AT_FDCWD, "/run/mount/utab", {st_mode=S_IFREG|0644, st_size=998, ...}, 0) = 0
2074  16:51:46.363441 execve("/sbin/mount.ntfs-3g", ["/sbin/mount.ntfs-3g", "/dev/vdb1", "/media/ntfs", "-o", "rw,noexec,nosuid,nodev,windows_names,hide_dot_files,users"], 0x618dcb5860c0 /* 7 vars */) = 0
2074  16:51:46.365285 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libntfs-3g.so.89", O_RDONLY|O_CLOEXEC) = 3
2074  16:51:46.370153 openat(AT_FDCWD, "/proc/mounts", O_RDONLY|O_CLOEXEC) = 3
2074  16:51:46.384577 read(3, "harset=iso8859-1,shortname=mixed,errors=remount-ro 0 0\nbinfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,r"..., 1024) = 611
2074  16:51:46.386881 newfstatat(AT_FDCWD, "/media/ntfs", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
2074  16:51:46.388061 newfstatat(AT_FDCWD, "/dev/fuse", {st_mode=S_IFCHR|0666, st_rdev=makedev(0xa, 0xe5), ...}, 0) = 0
2074  16:51:46.392619 write(2, "Failed to mount '/dev/vdb1'", 27) = 27
2074  16:51:46.392996 write(2, "Please check '/dev/vdb1' and the ntfs-3g binary permissions,\nand the mounting user ID. More explanation is provided at\nhttps://g"..., 170) = 170
2073  16:51:46.393855 write(17, "Unknown error when mounting /media/ntfs", 39) = 39
2072  16:51:46.394895 read(16, "Unknown error when mounting /media/ntfs", 1024) = 39
658   16:51:46.399112 openat(AT_FDCWD, "/var/lib/udisks2/mounted-fs-persistent", O_RDONLY) = 16
588   16:51:46.406602 sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\3\1\1\\\0\0\0 \0\0\0P\0\0\0\4\1s\0$\0\0\0org.freedesktop.UDisks2.Error.Failed\0\0\0\0\6\1s\0\6\0\0\0:1.105\0\0\10\1g\0\1s\0\0\5\1u\0\t\0\0\0W\0\0\0Error mounting system-manage"..., iov_len=188}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 188
jammy@jammyvm01:~$  

Der Auszug bestätigt noch, dass die Option users an /sbin/mount.ntfs-3g weitergereicht wird. Was man IMO leider nicht sicher sagen kann ist, ob das Einhängen an FUSE oder ntfs-3g selbst scheitert.

Jetzt muss ich mal noch mit Focal vergleichen, wo ja users noch nicht zu dem "udisks"-Fehler führt.

LG, Newubunti

Newubunti schrieb:

[…]

udisksctl mount -b /dev/vdb1 

scheitert mit der Fehlermeldung

Error mounting /dev/vdb1: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting system-managed device /dev/vdb1: Unknown error when mounting /media/ntfs

Der gefilterte strace von udisksd […]

2074  16:51:46.392996 write(2, "Please check '/dev/vdb1' and the ntfs-3g binary permissions,\nand the mounting user ID. More explanation is provided at\nhttps://g"..., 170) = 170 

Der Auszug bestätigt noch, dass die Option users an /sbin/mount.ntfs-3g weitergereicht wird. Was man IMO leider nicht sicher sagen kann ist, ob das Einhängen an FUSE oder ntfs-3g selbst scheitert.

Das ist die altbekannte Fehlermeldung von ntfs-3g, wenn mindestens eine der 3 FUSE-Bedingungen nicht erfüllt ist. Warum auch immer es diese 3 Bedingungen braucht, sie sind notwendig. Offen kann auch bleinben, ob ntfs-3g diese nicht erfüllen kann oder nicht will.

Jetzt muss ich mal noch mit Focal vergleichen, wo ja users noch nicht zu dem "udisks"-Fehler führt.

Fokal hat noch ein anderes mount, welches ntfs-3g als root startet.

Newubunti schrieb:

Diese Situation entspricht der, wegen der UlfZibis seinen Support-Thread eröffnet hatte, d.h. ein

Sehr schön !

2072  16:51:46.323894 newfstatat(AT_FDCWD, "/etc/fstab", {st_mode=S_IFREG|0664, st_size=804, ...}, 0) = 0
2072  16:51:46.324036 openat(AT_FDCWD, "/etc/fstab", O_RDONLY|O_CLOEXEC) = 16
2072  16:51:46.324300 read(16, "# /etc/fstab: static file system information.\n#\n# Use 'blkid' to print the universally unique identifier for a\n# device; this ma"..., 4096) = 804
2073  16:51:46.346030 newfstatat(AT_FDCWD, "/etc/fstab", {st_mode=S_IFREG|0664, st_size=804, ...}, 0) = 0
2073  16:51:46.346274 openat(AT_FDCWD, "/etc/fstab", O_RDONLY|O_CLOEXEC) = 16
2073  16:51:46.346516 read(16, "# /etc/fstab: static file system information.\n#\n# Use 'blkid' to print the universally unique identifier for a\n# device; this ma"..., 4096) = 804 

Ich sehe, dass da 2 verschiedene Prozesse die fstat auswerten, Welche sind das?

Woran erkennst Du, dass das Programm mount da nicht mitspielt?
Es sind immerhin 5 verschiedene Prozesse beteiligt.

Jetzt muss ich mal noch mit Focal vergleichen, wo ja users noch nicht zu dem "udisks"-Fehler führt.

Sehr schön !

kB schrieb:

Fokal hat noch ein anderes mount, welches ntfs-3g als root startet.

Es geht hier aber nicht um den Start per mount, sondern per udisksctl bzw. udisksd.
mount soll dabei ja angeblich nicht involviert sein.

Max-Ulrich_Farber schrieb:

Da sieht man auch, dass sowohl mount als auch ntfs-3g die fstab auswerten, nur anscheinend anders, denn ntfs-3g verlangt die explizite Angabe des /dev/... vor dem Mountpoint.

Das sehe ich daran nicht.

Woher kommt denn dann die Option relatime (in defaults enthalten), wenn ntfs-3g die fstab nicht auswertet? Auch die Optionen windows_names,hide_dot_files kämen dann nicht zum tragen.

Darf ich daraus entnehmen, dass vorher SUID nicht gesetzt war? Dann passt ja alles.

Ja sicher, denn sonst hätte ich es ja im 2. Folge-Listing nicht extra setzen müssen. Geh' immer von "Standard" aus, wenn ich nichts anderes schreibe.

UlfZibis schrieb:

[…] kB schrieb:

Fokal hat noch ein anderes mount, welches ntfs-3g als root startet.

Es geht hier aber nicht um den Start per mount, sondern per udisksctl bzw. udisksd.

Nein.

Es geht in diesem Thread um den Wiki-Artikel zu NTFS-3G und nicht um Deine Supportanfrage!

Es geht in diesem Thread um den Wiki-Artikel zu NTFS-3G und nicht um Deine Supportanfrage!

Danke! +1

kB schrieb:

Es geht in diesem Thread um den Wiki-Artikel zu NTFS-3G und nicht um Deine Supportanfrage!

Es ging um die Frage, ob das Verhalten UDisks auch von der neuen mount-Regel betroffen ist. Dafür hat newubunti eine strace von der udisksd-Aktivitat gemacht, um zu sehen, ob das Programm mount dabei überhaupt involviert ist. Es geht darum, die Auswirkungen der neuen Regel auszuloten.

Und so nebenbei ..... erst in Folge meiner Support-Frage ist die neue Regel ja überhaupt erst ans Licht gekommen.

UlfZibis schrieb:

kB schrieb:

Es geht in diesem Thread um den Wiki-Artikel zu NTFS-3G und nicht um Deine Supportanfrage!

Es ging um die Frage, ob das Verhalten UDisks auch von der neuen mount-Regel betroffen ist. Dafür hat newubunti eine strace von der udisksd-Aktivitat gemacht, um zu sehen, ob das Programm mount dabei überhaupt involviert ist. Es geht darum, die Auswirkungen der neuen Regel auszuloten.

Und dabei habe ich den Fehler gemacht, zu sehr nach einem entsprechende Aufruf von mount zu suchen. Den gibt es so zwar in den strace-Auszügen nicht, aber

Since util-linux 2.35, mount does not exit when user permissions are inadequate according to libmount’s internal security rules. Instead, it drops suid permissions and continues as regular non-root user. This behavior supports use-cases where root permissions are not necessary (e.g., fuse filesystems, user namespaces, etc).

gilt für udisksd jedenfalls auch, weil nämlich auch dort der Unterschied zwischen 20.04 und 22.04 darin besteht, dass

2074  16:51:46.363441 execve("/sbin/mount.ntfs-3g", ["/sbin/mount.ntfs-3g", "/dev/vdb1", "/media/ntfs", "-o", "rw,noexec,nosuid,nodev,windows_names,hide_dot_files,users"], 0x618dcb5860c0 /* 7 vars */) = 0

bei 20.04 mit der Benutzer-ID von root (0) und bei 22.04 vom Benutzer-ID des Benutzers, der das Einbinden veranlasst - in meinem Beispiel 1000 - ausgeführt wird.

Da stellt sich für mich die Frage, ob udisksd da mit der neuen Situation, die seit util-linux 2.35 gilt, im eigenen Sinne richtig umgeht? Aber da denke ich morgen bzw. später noch mal drüber nach.

LG, Newubunti

Newubunti schrieb:

[…] gilt für udisksd jedenfalls auch, weil nämlich auch dort der Unterschied zwischen 20.04 und 22.04 darin besteht, dass

2074  16:51:46.363441 execve("/sbin/mount.ntfs-3g", ["/sbin/mount.ntfs-3g", "/dev/vdb1", "/media/ntfs", "-o", "rw,noexec,nosuid,nodev,windows_names,hide_dot_files,users"], 0x618dcb5860c0 /* 7 vars */) = 0

bei 20.04 mit der Benutzer-ID von root (0) und bei 22.04 vom Benutzer-ID des Benutzers, der das Einbinden veranlasst - in meinem Beispiel 1000 - ausgeführt wird.

Das mag richtig sein und wäre für mich durchaus plausibel.

Aber Frage eines DAU: Woran erkennt man in diesen schwer lesbaren Protokollen von strace, ob ein bestimmter Aufruf als root oder als anderer Benutzer erfolgt?

Newubunti schrieb:

Und dabei habe ich den Fehler gemacht, zu sehr nach einem entsprechende Aufruf von mount zu suchen. Den gibt es so zwar in den strace-Auszügen nicht,

D.h., die Frage, ob der Dienst udisksd das Programm mount aufruft und nutzt, um die fstab auszuwerten, oder dies eigenständig nach eigener Logik tut, ist immer noch offen ❓

Since util-linux 2.35, mount does not exit when user permissions are inadequate according to libmount’s internal security rules. Instead, it drops suid permissions and continues as regular non-root user. This behavior supports use-cases where root permissions are not necessary (e.g., fuse filesystems, user namespaces, etc).

gilt für udisksd jedenfalls auch, weil nämlich auch dort der Unterschied zwischen 20.04 und 22.04 darin besteht, dass ...

Nach meiner bescheidenen Logik heißt das:

• Entweder ist udisksd Bestandteil von Paket util-linux 2.35, wodurch es von der Regel direkt betroffen ist.

• Oder udisksd ruft das Programm mount auf, wodurch es von der Regel indirekt betroffen ist.

• Es wäre die Klärung wünschenswert, ob die in Ubuntu 22.04 eingesetzte Version des Programms ntfs-3g die obige Regel schon kennt, denn es kann ja auch ohne Vorschaltung von mount direkt aufgerufen werden. Siehe: tuxera/ntfs-3g/issues/103

kB schrieb:

Aber Frage eines DAU: Woran erkennt man in diesen schwer lesbaren Protokollen von strace, ob ein bestimmter Aufruf als root oder als anderer Benutzer erfolgt?

Gute Frage.

Und dabei ist IMHO zu unterscheiden, ob ein Programm – oder dessen Library, hier z.B. libmount – direkt "aufgerufen" ... oder als eigener Prozess gestartet wird.
Im ersten Fall läuft es dann IMHO zwingend mit den Rechten des aufrufenden Programms, im zweiten kann der Benutzer des Prozesses – und damit auch die "Rechtslage" – frei gewählt werden.

kB schrieb:

Aber Frage eines DAU: Woran erkennt man in diesen schwer lesbaren Protokollen von strace, ob ein bestimmter Aufruf als root oder als anderer Benutzer erfolgt?

Das ist eine berechtigte Frage und anhand der von mir bis jetzt gelieferten gefilterten Auszüge konntet Ihr das jetzt gar nicht ablesen, weil da nicht alle Prozess-Details ersichtlich. Der Grund für meine Art der Filterung war, dass ich nach einem Aufruf von mount gesucht hatte.

Guckt man sich den vollständigen Auszug des Sub-Prozesses von udisksd an, der /sbin/mount.ntfs-3g ausführt, dann sieht man da am Anfang (das ist jetzt ein Auszug des Sub-Prozesses unter Focal - Prozess-ID 1922) :

focal@focalvm01:~$ grep -Ei '^1922' /home/$USER/udisksd-focal-fstab-ntfs-strace.txt
1922  01:24:06.844875 set_robust_list(0x7fd730f079e0, 24) = 0
1922  01:24:06.845095 getgid()          = 0
1922  01:24:06.845167 setgid(0)         = 0
1922  01:24:06.845225 getuid()          = 0
1922  01:24:06.845272 setuid(0)         = 0
1922  01:24:06.845333 execve("/sbin/mount.ntfs-3g", ["/sbin/mount.ntfs-3g", "/dev/vdb1", "/media/ntfs", "-o", "rw,noexec,nosuid,nodev,windows_names,hide_dot_files,users"], 0x55a5614f83b0 /* 6 vars */) = 0
1922 ...

Meine Vermutung der ich heute noch nachgehen werde ist: udisksd übernimmt die Sicherheitsregeln von libmount1, wenn die Partition HintSystem=True hat. Vor util-linux 2.35 führt diese Prüfung im Zusammenspiel mit der Option users immer zu uid=0 und ist daher für udisksd nicht weiter schädlich. Ab Version 2.35 führt die Prüfung aber in aller Regel zu uid=$(id -u).

Das widerspricht aber dann IMO dem Konzept von udisksd, welches die Mount-Erlaubnis an polkit bindet. Und im Falle der uid=1000 besteht diese unter Ubuntu standardmäßig ja.

LG, Newubunti

UlfZibis schrieb:

Und so nebenbei ..... erst in Folge meiner Support-Frage ist die neue Regel ja überhaupt erst ans Licht gekommen.

Das kann man so sehen oder auch anders. Aber auf jeden Fall hat kB Recht: Das Problem nimmt einen viel zu großen Raum in einer Diskussion ein, in der es eigentlich um ganz Anderes geht – nämlich um einen Wiki-Artikel!

Deshalb wiederhole ich meine schon viel früher geäußerte Bitte, diese Diskussion abzutrennen (nicht zu beenden!), sie in einen eigenen Thread zu verlagern und hier wieder zum eigentlichen Thema zurückzukommen.

Also unter 22.04 hat das Setzen von HintSystem=0 keine Auswirkung auf die verwendete uid des Subprozesses von udisksd, der /sbin/mount.ntfs-3g ausführt. Das geht dann aber ab jetzt mehr in die Richtung von udisks.

Für diesen Artikel bleibt für mich festzuhalten, dass die Option users ab 22.04 bzw. util-linux >= 2.35 im Zusammenspiel von ntfs-3g mit udisks im Moment zu unerwarteten Ergebnissen führt.

LG, Newubunti

EDIT:

Weil das auch die Frage war:

Max-Ulrich_Farber schrieb:

UlfZibis schrieb:

Bei mir anders. Unter Vorliegen von users in der fstab ohne "NTFS-3G-Bedingungen" scheitert udisksctl (genau das war ja der Anlass für mein Support-Thema und meinen Fehlerbericht).

Das würde nach meinem (unvollständigen) Verständnis doch heißen, dass da /usr/bin/mount ausgeführt wurde. Hier ist nun Newubunti mit strace gefragt! – Ist es denkbar, dass udisksctl ohne fstab-Zeile mit seinen eigenen hardcodierten bzw. über udisksctl.inf veränderten Bedingungen das Hilfsprogramm /usr/sbin/ntfs-3g direkt aufruft (das geht ja wegen SUID immer), aber beim Vorliegen der Zeile diese mittels usr/bin/mount ausführt? Dies müsste dann auf jeden Fall scheitern, denn dann lehnt ja ntfs-3g wegen users ab.

Der strace zeigt IMO, dass /usr/bin/mount nicht ausgeführt wird, sonst müsste genau diese Zeile irgendwo zu finden sein, ist sie aber nicht. Allerdings hängt das Paket udisks2 vom Paket libmount1 ab. D.h. selbst wenn udisksd direkt über libmount1 einhängt, dann gelten eben auch die libmount-Regeln, bzw. können gelten.

Danke Newubunti für die große Mühe und auch für das klare Statement. Ich wage jetzt also den großen Gedankensprung: Die NTFS-Partition ist eingehängt – wie geht's jetzt weiter?

Wer sie eingehängt hat, ist nur noch fürs wieder Aushängen wichtig, denn:

• ohne User-Mapping, d.h. auch ohne permissions oder acl, wobei dann evtl. eben das default user mapping stattfindet, kann man die transienten Rechte ja mit uid &Co wunschgerecht festlegen. Nach dem bis jetzt diskutierten Trouble sollte man dies dann aber auch unbedingt empfehlen!

• mit User-Mapping spielt es, soviel ich sehe, keine Rolle mehr, wer die Partition eingehängt hat. Und das sollte eigentlich bei allen "kritischen" Partitionen der Regelfall sein bzw. werden. Wer kein User-Mapping haben will, der kann IMO genau so gut bzw. noch besser den Kernel-Treiber verwenden.

Bei der strengen Formulierung der Empfehlung – nein, Ermahnung, die Treiber nicht abwechselnd oder gleichzeitig in dem selben System zu verwenden, die ja UlfZibis beanstandet hatte, bin ich stillschweigend davon ausgegangen, dass eben User-Mapping verwendet wird. Ohne dieses ist es weniger schlimm; mittels uid &Co kann man eine begrenzte Kompatibilität erreichen, mit der man leben kann. Aber auch diese Kompatibilität ist nur begrenzt:

• Bei NTFS-3G bleiben die transienten Dateirechte für die ganze Sitzung fast unverändert bestehen – wie bei VFAT und exFAT. Der Befehl chown wird nicht beachtet, und chmod kann die Rechte nur – ebenfalls transient – weiter einschränken. Nach dem Aushängen ist also betr. Rechte alles wie vorher. Neu angelegte Dateien gehören dann "niemand" bzw. Root mit umask=0.

• Beim Kernel-Treber NTFS3 können hingegen transiente und persistente Rechte koexistieren. Mittels chown und chmod können transiente Rechte durch persistente überschrieben werden (wie es dann mit cp -p bzw. mv aussieht, weiß ich noch nicht). Neu angelegte Dateien gehören persistent demjenigen, dem sie in einem Linux-Dateisystem (ext3/49) gehören würden. Nach dem Aushängen sind also die Rechte nicht mehr unbedingt so wie vorher!

• Das Problem der Symlinks (schon kurz angerissen) besteht unabhängig vom User-Mapping.

Beim User-Mapping sehe ich (im Moment) hauptsächlich folgende Probleme:

• bei permissions ist das Problem, dass sich allein mit UNIX-Dateirechten die Rechteverwaltungen von Windows und Linux nicht umkehrbar eindeutig aufeinander abbilden lassen. Windows auf Linux geht nur sehr eingeschränkt (das spielt ja beim default_user_mapping keine Rolle), aber auch umgekehrt gibt es mit manchen Gruppen gewisse Probleme, auf die UlfZubis zu Recht hingewiesen hat. Soviel ich sehe, spielen diese aber auch erst beim Zusammenspiel mit Windows eine Rolle, sodass sich mit dem User-Mapping (vor allem auch default_user_mapping) schon eine in sich (aber nicht vollständig mit Windows) kohärente, vollständige Verwaltung von UNIX-Dateirechten realisieren lässt.

• bei acl ist das Problem gerade umgekehrt: Die POSIX-ACL lassen sich nicht komplett auf Windows-ACL abbilden. Damit ist – soviel ich sehe – eine komplette Verwaltung der POSIX-ACL mittels User-Mapping, d.h. in NTFS-3G überhaupt, nicht machbar. Aber ganz klar sehe ich da noch nicht.

Dazu kommt, dass die Optionen uid &Co, permissions und acl miteinander nicht kompatibel sind, und dass es deshalb recht schwierige, komplexe "Vorfahrtsregeln" gibt, die zu Unfällen führen können, obwohl sie diese ja verhindern sollten. Man muss das Zeug wirklich studieren, bevor man es fehlerfrei anwenden kann.

Wenn man mit der "Vorfahrt" endlich klar kommt, dann kommen noch Schwierigkeiten beim Zusammenspiel von default_user_mapping und User-Mapping mittels Mapping-Datei dazu. Man muss wirklich beides ganz verstanden haben, wenn man da nicht ins Schleudern kommen will.

Trotz all dieser Probleme ist User-Mapping AFAIK der einzige einigermaßen sichere Weg, NTFS-Partitionen, vor allem interne, abwechselnd mit LINUX und Windows zu verwenden. Es ist verdammt kompliziert, aber einfacher geht es halt nicht. Beim Kernel-Treiber konnte ich (bisher) noch keine auch nur annähernd vergleichbare Sicherheit entdecken. Jeder kann mit dem im jeweils anderen Betriebssystem völlig ungestört alles kaputt machen. 😬

Wer aber NTFS nur als weiteres Linux-Dateisystem und vielleicht noch zum gelegentlichen Datenaustausch verwenden will, muss sich den ganzen Zirkus mit dem User-Mapping nicht antun, er soll lieber NTFS3 verwenden, sobald die Kinderkrankheiten überwunden sind. Das ist sicher einfacher.

Jetzt mache ich ein bisschen Pause um meinen Kopf dafür wieder frei zu bekommen, und dann mache ich mich ans User-Mapping.

L.G. – Max-Ulrich

Jetzt ein organisatorischer Vorschlag zur Arbeitsteilung:

Allgemein heißt es ja, der brave Mann nennt sich selbst zuletzt. Doch wenn’s um Arbeit geht, gilt wohl das Gegenteil:

1. Ich kümmere mich jetzt ums User-Mapping mit allen seinen Facetten, und UlfZibis schaut mir dabei kritisch auf die Finger. 😳

2. Newubunti macht den Anfang und das "Einhängen" fertig und kümmert sich um die Hard- und Symlinks, weil ich davon nicht viel verstehe. UlfZibis ist ihm dabei sicher gerne behilflich.

3. kB hat ganz sicher mit dem Übersichtsartikel und mit der Entscheidung, was jeweils in diesen und was in die Einzelartikel gehört, mehr als genug zu tun – wohl mehr als wir alle!

4. Und wer damit noch nicht genug Arbeit hat, der kann ja gleich jetzt schon mit udisks2 anfangen… 😇

5. Aber, oh je, den Kernel-Treiber NTFS3 ♥ gibt’s ja auch noch! 😢

Geht das so ❓