Beforge
Ehemalige
Anmeldungsdatum: 29. März 2018
Beiträge: 2007
|
Windows-Partitionen einbinden/NTFS-3G (Abschnitt „Remount-mit-rw-nicht-moeglich“) Hat man ein Dateisystem mit ro -Option eingebunden, funktioniert das Remount mit Schreibrechten nicht (Stand: Ubuntu 12.04).
(siehe 186117) Abhilfe ist, hier erst ein umount zu machen und dann mit rw- Option zu mounten.
Ist das noch aktuell?
|
Beforge
Ehemalige
Anmeldungsdatum: 29. März 2018
Beiträge: 2007
|
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6472
|
Hat man ein Dateisystem mit ro-Option eingebunden, funktioniert das Remount mit Schreibrechten nicht
Ich verstehe den Sinn dahinter überhaupt nicht. Wozu soll das gut sein?
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28953
Wohnort: WW
|
Hallo, ich verstehe das so, dass eine entsprechende Partionen, die mit ro eingehängt ist, im laufenden Betrieb _nicht_ mit Schreib-/Leserechten neu eingehängt werden kann. Gruß, noisefloor
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Habe den Hinweis auf Gruppe fuse auf "bis einschließlich Ubuntu 18.04" begrenzt, einen toten Link korrigiert und dann "getestet focal" eingetragen, da an NTFS-3G nichts mehr verändert wurde. Gruß – Max-Ulrich
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17583
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Bearbeitet von karzer: Modtag korrigiert.
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Dadurch, dass jetzt seit Ubuntu 22.04 (Kernel 5.15) nun ein vollwertiger NTFS-Kerneltreiber NTFS3 zur Verfügung steht, hat sich die Situation deutlich verändert. Unglücklicherweise lädt der Name des Kernel-Treibers auch noch geradezu zu Verwechslungen mit NTFS-3G ein! Ubuntu verwendet fürs automatische Einbinden von NTFS-Partitionen nach wie vor den FUSE-Treiber NTFS-3G und nicht – wie man vielleicht erwarten könnte – den Kernel-Treiber. Gleiches gilt, wenn beim Mount-Befehl kein Treiber spezifiziert wird. Dies alles wäre nicht so schlimm, wenn die beiden Treiber besser miteinander kompatibel wären. Das sind sie aber eben nicht! Zwar bietet NTFS3 per Default – d.h. ohne entsprechende Mount-Parameter – eine ganz ähnliche Verwaltung der UNIX-Dateirechte und POSIX-ACL wie NTFS-3G mit den Parametern permissions und acl , aber die beiden Rechte-Verwaltungen sind leider zueinander nicht kompatibel. Rechte, die mit einem der Treiber festgelegt wurden, werden vom jeweils anderen Treiber nicht erkannt und völlig ignoriert. Obwohl der neuere Kernel-Treiber NTFS3 angeblich wesentlich performanter arbeitet als NTFS-3G (wirklich?), rechtfertigt die mangelnde Kompatibilität wohl das Festhalten von Ubuntu am alten, langsamen aber bewährten FUSE-Treiber: Beim Übergang auf NTFS3 müsste in Partitionen, die vorher mit NTFS-3G eingebunden und bearbeitet wurden, u.U. die gesamte UNIX-Rechteverwaltung neu organisiert werden! Außerdem bietet (bislang) nur NTFS-3G die vor allem für Dual-Boot-Systeme interessante Möglichkeit des User-Mapping zwischen Windows und UNIX/Linux. Weil in Ubuntu bisher nur recht spärliche Erfahrungen mit dem Kernel-Treiber NTFS3 vorliegen, habe ich nur einen relativ knappen Hinweis auf diesen Treiber eingefügt. Eine detailliertere Gegenüberstellung der beiden Treiber muss dann zu einem späteren Zeitpunkt erfolgen.
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
In verschiedenen Blogs fand ich im Internet noch so viele Klagen und Unstimmigkeiten über den Kernel-Treiber NTFS3, dass ich auf diesen bis auf weiteres nicht näher eingehen möchte. Ich denke, NTFS-3G wird wohl auf längere Sicht noch der "Königsweg" zum Einbinden von NTFS-Partitionen in Linux bleiben. Andererseits finde ich den vorliegenden Artikel sehr lang und umfangreich. Ich überlege mir, wie man ihn kürzen könnte, ohne dabei wichtige Informationen zu verlieren. Als erstes möchte ich gerne aus dem Artikel alles entfernen, was nur vor Ubuntu 20.04 und vor Windows 10 von Bedeutung war. Dies würde den Artikel schon ’mal besser lesbar machen. Wo genau ich bei NTFS-3G selbst den Schnitt machen müsste, weiß ich nicht. Aber auf jeden Fall könnte man Hinweise auf Uralt-Versionen entfernen. Wenn hier niemand Bedenken zum Ausdruck bringt, mache ich mich an die Arbeit. Es ist sicher nicht nötig, den Artikel dafür eigens in die Baustelle zu verschieben.
|
karzer
Wikiteam
Anmeldungsdatum: 10. April 2022
Beiträge: 1288
Wohnort: Bad Oeynhausen
|
Max-Ulrich_Farber schrieb: [...] Wenn hier niemand Bedenken zum Ausdruck bringt, mache ich mich an die Arbeit. [...]
Nur zu, Mitarbeit ist immer willkommen!
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Nur zu, Mitarbeit ist immer willkommen!
Danke für die Ermunterung! 😀 Den Artikel habe ich selbst ja vor genau 12 Jahren begonnen… Deshalb stammt vermutlich das meiste von dem alten Kram von mir. EDIT: Ich habe den Artikel jetzt erst einmal etwas gestrafft und entrümpelt. Ich hoffe, dass er dadurch besser lesbar wurde.
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Ich habe mir nochmal den Abschnitt "Standard-Einstellungen" vorgeknöpft. So wie beschrieben stimmt dieser jedenfalls nicht oder nicht mehr. Ich bin zu folgendem Schluss gekommen, muss diesen aber nochmals eingehend überprüfen::
NTFS-3G unterscheidet beim Einbinden nicht zwischen internen und externen Partitionen. Unterschiede der simulierten Besitzer kommen daher, wie die Partition eingebunden wurde: Wenn die Partition mit Root-Rechten eingebunden wurde, ist bei fehlenden Optionen uid und gid immer Root der Besitzer. Das gilt bei Einträgen in fstab sowie beim Mounten mittels sudo mount… Wenn die Partition ohne Root-Rechte eingebunden wurde, ist bei fehlenden Optionen uid und gid der eingeloggte Benutzer Besitzer der Partition. Das gilt vor allem immer dann, wenn das Einbinden mittels GVfs erfolgt, d.h. bei Hotplug und beim Einbunden mittels Mausklick im Dateimanager.
Wenn für umask, fmask und dmask keine Angaben gemacht sind (bei GVfs ist das immer der Fall), dann gilt für alle drei Parameter der Wert 000, d,h. jedermann hat dann Vollzugriff (rwx). die Option permissions bzw. das Vorhandensein einer Datei .NTFS-3G/usermapping setzt alle diese Vorgaben und ggf. die Optionen uid, gid, umak, fmask, dmask außer Kraft. Die Regeln sind somit anders als bei VFAT und exFAT (nicht nur bei permissionsss).
Sollte jemand noch andere Beobachtungen machen, bitte ich um Mitteilung.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: […] * NTFS-3G unterscheidet beim Einbinden nicht zwischen internen und externen Partitionen.
Das gilt für NTFS-3G genauso wie für jeden Dateisystem-Treiber und liegt daran, dass niemand zwischen internen und externen Partitionen unterscheiden kann. Unterscheiden kann man nur fest angeschlossene (vermutlich für Dich „interne“) und im Betrieb trennbare (vermutlich für Dich „externe“) Geräte und zu welcher Gruppe ein Gerät konkret gehört, kann zwar ein Mensch durch Okularinspektion entscheiden, aber es gibt dafür kein sicheres technisches Kriterium.
Automatisch beim Start eingebunden wird alles, was ohne Option noauto in der Datei /etc/fstab steht, alles andere krallt sich GVfs.
Jein. Der simulierte Besitzer der eingebundenen Dateien ist immer der Besitzer des Prozesses, der einbindet. Zum Einbinden benötigt man immer die erforderlichen Root-Rechte; GVfs hat diese, auch wenn es unter einem normalen Benutzer läuft.
[…]
Überprüfen, mit welchen Optionen eine Einbindung erfolgte, kann man übrigens z.B. so:
$ findmnt -r | grep ntfs*
/media/alt/Windows /dev/sdb4 ntfs3 ro,nosuid,nodev,noexec,relatime,uid=0,gid=0,iocharset=utf8 … als notwendige Folge der erheblichen technischen Unterschiede der drei Dateisysteme.
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Danke, kB: Das stimmt genau mit meinen Beobachtungen überein. Du hast das etwas korrekter ausgedrückt: Es ist nicht ausschlaggebend, ob mit Root-Rechten eingebunden wird oder nicht, sondern ob Root der Besitzer des Prozesses ist, der einbindet. Das ist zweifellos ein kleiner Unterschied. Ich will die Passage ändern, aber ich überlege noch, wie ich das so sagen kann, dass es der "einfache Benutzer" auch versteht. Das ist nicht immer so einfach…
… als notwendige Folge der erheblichen technischen Unterschiede der drei Dateisysteme.
Ich denke, NTFS-3G hätte das wohl trotzdem genau so machen können, wie bei den anderen Windows-Dateisystemen. Aber das wollten die Entwickler eben nicht: Sie wollten in sich konsequent bleiben, und "keine Option" bedeutet eben immer "Null". Das war anscheinend am Anfang noch nicht so gewesen (??). Ich muss mal sehen, ob uid und gid dann ignoriert wird, wenn man "Root" einsetzt. Das wäre dann konsequent (aber das macht ja zum Glück niemand).
Automatisch beim Start eingebunden wird alles, was ohne Option noauto in der Datei /etc/fstab steht, alles andere krallt sich GVfs.
Stimmt das auch noch uneingeschränkt mit systemd? Das überschaue ich nicht ganz. Und auch das Einbinden mittels @reboot in /etc/crontab ist mit einem fstab-Eintrag gleichzusetzen. Überhaupt läuft alles, was irgendwie mit irgendeiner crontab läuft, ohne GVfs, denn die beiden vertragen sich nicht. gio mount in crontab klappt nicht, auch nicht in der persönlichen crontab des Benutzers.
$ findmnt -r | grep ntfs*
Das geht beim Kernel-Treiber ntfs3, aber wegen FUSE nicht bei ntfs-3g.
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Remount mit rw nicht möglich Hat man ein Dateisystem mit ro-Option eingebunden, funktioniert das Remount mit Schreibrechten nicht (Stand: Ubuntu 12.04). (siehe186117) Abhilfe ist, hier erst ein umount zu machen und dann mit rw-Option zu mounten.
Der Fehler ist IMHO etwas anders: NTFS-3G unterstützt die (eigentlich unnötige) Option remount nicht. Das ist kein Fehler, sondern Feature. Bei mount -t ntfs-3g ... -o remount,rw kommt die korrekte Meldung Remounting is not supported at present. You have to umount volume and then mount it once again.
Fehlt aber die Angabe -t ntfs , dann unterbleibt die Meldung und der Remount wird scheinbar ausgeführt, doch in Wirklichkeit geschieht er nicht. Anschließend stimmen die für die Partition angezeigten Eigenschaften nicht mehr mit der Wirklichkeit überein. Das verwirrt schon. Dies ist heute noch so (Ubuntu 22.04), obwohl die Fehlermeldung von 2008 (!) stammt. Dies gilt für alle evtl. geänderte Optionen, nicht nur für rw.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3022
Wohnort: Köln
|
Warum wurde im Abschnitt "permissions" folgender Satz gestrichen? Dabei entstehen allerdings für Windows unbekannte Eigentumskennungen in den ACLs.
Dass .NTFS-3G/UserMapping eine reine Textdatei ist, ist jetzt direkt aufeinander folgend doppelt gemoppelt erwähnt.
|