staging.inyokaproject.org

Gemountet wird dabei mittels ntfs3.

Wirklich? Ich habe nie beobachtet, dass der Dateimanager oder ein GUI-Werkzeug ntfs3 verwendet hätte.

ntfs-3g behandelt die Optionen user & Co. fehlerhaft:

Ich habe mir folgende (vielleicht falsche) Erklärung zurechtgelegt

• NTFS-3G kennt offenbar weder die Option user noch users, sondern nur die FUSE-Option allow_others. Diese ist sehr tolerant und entspricht so ungefähr users.

• Die mount-Optionen user &Co müssen nun auf die FUSE-Option allow_others abgebildet werden, ggf. eben mittels zusätzlicher Einschränkungen.

• Was dabei herauskommt, hängt von den jeweiligen FUSE-Einstellungen ab. Wenn das unerwartet ausfällt, ist das kein Fehler von NTFS-3G, sondern eine fehlerhafte Übertragung der Optionen. An NTFS-3G hat sich vermutlich zwischen den genannten Ubuntu-Versionen nichts geändert, an FUSE oder fuse.conf vielleicht schon (?)

• Ich meine, ähnlich verwirrende Beobachtungen auch beim FUSE-Treiber von exFAT gelesen zu haben, weiß es aber nicht mehr so genau. Es ging da auch um allow_others.

Max-Ulrich_Farber schrieb:

Und NTFS3 ist meinem System gänzlich unbekannt.

Ubuntu 22.04? Das kann eigentlich nicht sein. Bei mir funktioniert ntfs3 wie in der Kernel-Dokumentation beschrieben.

Bei mir verhält sich das aktuell so:

$ sudo mkdir /media/NTFS3
$ sudo mount -t ntfs3 /dev/sda7 /media/NTFS3/
mount: /media/NTFS3: /dev/sda7 ist bereits eingehängt oder wird gerade benutzt.
$ mount | grep sda7
$ sudo blkid | grep sda7
/dev/sda7: LABEL="Sicherung" BLOCK_SIZE="512" UUID="2510AA16624BB80C" TYPE="ntfs" PARTUUID="0f756184-07"
$ sudo umount /dev/sda7
umount: /dev/sda7: nicht eingehängt.
$ sudo mount -t ntfs3 /dev/sda7 /media/NTFS3/
mount: /media/NTFS3: /dev/sda7 ist bereits eingehängt oder wird gerade benutzt.
$ sudo mount -t ntfs-3g /dev/sda7 /media/NTFS3/
$ mount | grep sda7
/dev/sda7 on /media/NTFS3 type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
$ sudo umount /dev/sda7
$ lsb_release -d
Description:	Ubuntu 22.04.4 LTS
$ cat /proc/version_signature
Ubuntu 5.15.0-94.104-generic 5.15.136
$ 

Wie könnte ich denn anderweitig feststellen, ob NTFS3 bei mir im System "bekannt" ist?

kB schrieb:

Bei einem regulär und nicht kaputt optimiertem Ubuntu-System 20.04, 22.04, 23.10 und wahrscheinlich bei jeder anderen Version auch zurück bis 16.04 gilt einheitlich: [.....]

1. Mounten per fstab durch einen normalen Benutzer benötigt SUID für ntfs-3g und passende Dateiberechtigungen für Quelle und Ziel des Mount-Vorgangs.

Wird in 20.04 nur für mount benötigt, nicht für Einbinden per Dateimanager.

Max-Ulrich_Farber schrieb:

Gemountet wird dabei mittels ntfs3.

Wirklich? Ich habe nie beobachtet, dass der Dateimanager oder ein GUI-Werkzeug ntfs3 verwendet hätte.

Da schon spät, ein wenig schreibfaul der Terminal-Auszug nach Klick auf das NTFS-Laufwerk (Partition) mit dem Label NTFSTEST.

jammy@jammyvm01:~$ id
uid=1000(jammy) gid=1000(jammy) Gruppen=1000(jammy),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),135(lxd),136(sambashare)
jammy@jammyvm01:~$ mount | grep ntfs
/dev/vdb1 on /media/jammy/NTFSTEST type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,windows_names,uhelper=udisks2)
jammy@jammyvm01:~$ sudo fuser /dev/vdb1
[sudo] Passwort für jammy: 
jammy@jammyvm01:~$  

Wie man sieht ǹtfs3 und bei fuser ... kein Prozess. Bei Verwendung von ntfs-3g würde da bei den mounts fuseblk stehen. Und das ist ein System unmittelbar nach der Installation und Ausführung von Updates. Sonst keinerlei Veränderungen.

Ich habe mir folgende (vielleicht falsche) Erklärung zurechtgelegt ...

Ich habe FUSE als Verdächtigen für Verwirrungen auch noch nicht ausgeschlossen. Ich habe mein Testprotokoll bis jetzt noch nicht auf ein systematisches Testen gegen allow_others in der /etc/fuse.conf ausgedehnt.

Aufgefallen ist mir aber schon, dass bei Verwendung von FUSE, das allow_others in den aufgelisteten Mount-Optionen auftaucht, wenn man nach dem Einhängen mount | grep ntfs ausführt und zwar ohne, dass ich die Option in der /etc/fstab gesetzt habe und ohne Veränderung der /etc/fuse.conf.

Ich habe auch in die Richtung von Übersetzung von *user* gedacht, aber wie gesagt, noch nicht weiter systematisch untersucht.

LG, Newubunti

noch nicht weiter systematisch untersucht.

habe ich auch nicht.

Aber ich habe noch eine Unkorrektheit beim Zusammentreffen von uid & Co mit permissions und acl entdeckt, die ich berichtigen muss. Das beste wäre natürlich, man würde einander widersprechende mount-Optionen einfach vermeiden…

/dev/vdb1 on /media/jammy/NTFSTEST type ntfs3 (rw,nosuid…

Das ist ja eindeutig. Aber ich finde es schlimm, wenn NTFS-3G und ntfs3 durcheinander verwendet werden, weil die Treiber gegenseitig ihre Rechte-Verwaltung nicht anerkennen. Das habe ich eben nochmal probiert, da ist offenbar nichts zu machen (?). Persistente Rechte, die mit NTFS-3G mittels permissions gesetzt wurden, existieren für ntfs3 nicht und umgekehrt.

Der Benutzer sollte außerdem unbedingt informiert werden, welcher Treiber verwendet wird, ohne dass er dies mittels mount | grep ntfs oder mount | grep fuse ermitteln muss. Ich erhalte folgendes:

/dev/mmcblk0p1 on /media/SD-200GB type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

gemountet über folgenden fstab-Eintrag:

/dev/mmcblk0p1 /media/SD-200GB ntfs defaults,rw,permissions,acl,nofail 0 0

d.h. ntfs wurde eindeutig als ntfs-3g interpretiert! – per umount ausgehängt und per Mausklick wieder eingehängt: gleiches Ergebnis. Per Mausklick ausgehängt und wieder eingehängt: ebenso. Nichts vom Treiber ntfs3.

Und nun noch fstab-Eintrag deaktiviert, neu gestartet und per Mausklick eingebunden:

/dev/mmcblk0p1 on /media/farber/50B615D848DBB7B0 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

wieder fuseblk und kein ntfs3. Was könntest Du nur anders gemacht haben ??

Hallo,

ich wollte meinen vorigen Beitrag gerade noch bearbeiten, aber Du warst schneller. ☺

Ubuntu 20.04.6 verwendet standardmäßig beim Mount über Nautilus durch den Systemverwalter (uid=1000) FUSE/ntfs-3g:

focal@focalvm01:~$ id
uid=1000(focal) gid=1000(focal) Gruppen=1000(focal),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),120(lpadmin),133(lxd),134(sambashare)
focal@focalvm01:~$ mount | grep ntfs
focal@focalvm01:~$ mount | grep fuseblk
/dev/vdb1 on /media/focal/NTFSTEST type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
focal@focalvm01:~$ sudo fuser /dev/vdb1
[sudo] Passwort für focal: 
/dev/vdb1:            1803
focal@focalvm01:~$ sudo ps 1803
    PID TTY      STAT   TIME COMMAND
   1803 ?        Ss     0:00 /sbin/mount.ntfs /dev/vdb1 /media/focal/NTFSTEST -o rw,nodev,nosuid,windows_names,uid=1000,gid=1000,uhelper=udisks2
focal@focalvm01:~$ ls -lisa /sbin/mount.ntfs
271256 0 lrwxrwxrwx 1 root root 13 Dez 18 11:17 /sbin/mount.ntfs -> mount.ntfs-3g
focal@focalvm01:~$ ls -lisa /sbin/mount.ntfs-3g
271257 0 lrwxrwxrwx 1 root root 12 Dez 18 11:17 /sbin/mount.ntfs-3g -> /bin/ntfs-3g
focal@focalvm01:~$ ls -lisa /bin/ntfs-3g
262983 160 -rwxr-xr-x 1 root root 162704 Nov  1  2022 /bin/ntfs-3g
focal@focalvm01:~$ 

Bei Ubuntu 23.10 verhält es sich, wie bei Ubuntu 22.04.3, d.h. grafischer Mount standardmäßig wiederum über ntfs3.

UlfZibis schrieb:

...

1. Mounten per fstab durch einen normalen Benutzer benötigt SUID für ntfs-3g und passende Dateiberechtigungen für Quelle und Ziel des Mount-Vorgangs.

Wird in 20.04 nur für mount benötigt, nicht für Einbinden per Dateimanager.

Das entspricht nicht dem Standardverhalten von Ubuntu 20.04.6. Ein unprivilegierter Nutzer kann weder über Nautilus noch über Laufwerke einhängen, wenn in der /etc/fstab die NTFS-Partition mit noauto,users vorbereitet wurde und SUID- und Mountpunkt-Rechte nicht bestehen. Ich kann mir auch nicht vorstellen, dass das jemals in einer Ubuntu-Version standardmäßig anders war.

Max-Ulrich_Farber schrieb:

Aber ich finde es schlimm, wenn NTFS-3G und ntfs3 durcheinander verwendet werden, weil die Treiber gegenseitig ihre Rechte-Verwaltung nicht anerkennen. Das habe ich eben nochmal probiert, da ist offenbar nichts zu machen (?). Persistente Rechte, die mit NTFS-3G mittels permissions gesetzt wurden, existieren für ntfs3 nicht und umgekehrt.

Das habe ich aus dem Augenwinkel - d.h. noch nicht systematisch untersucht - auch schon beobachtet.

Der Benutzer sollte außerdem unbedingt informiert werden, welcher Treiber verwendet wird, ohne dass er dies mittels mount | grep ntfs oder mount | grep fuse ermitteln muss. Ich erhalte folgendes:

/dev/mmcblk0p1 on /media/SD-200GB type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

gemountet über folgenden fstab-Eintrag:

/dev/mmcblk0p1 /media/SD-200GB ntfs defaults,rw,permissions,acl,nofail 0 0

d.h. ntfs wurde eindeutig als ntfs-3g interpretiert! – per umount ausgehängt und per Mausklick wieder eingehängt: gleiches Ergebnis. Per Mausklick ausgehängt und wieder eingehängt: ebenso. Nichts vom Treiber ntfs3.

Da liegt vielleicht ein kleines Missverständnis vor:

Die Beobachtung aus meinem vorigen Post bezieht sich auf das Einhängen ohne fstab-Eintrag für die betreffende NTFS-Partition. Dann wird ab Ubuntu 22.04 bei GUI-Nutzung per ntfs3 eingehängt.

ntfs in der /etc/fstab führt, dagegen zu fuseblk/ntfs-3g. Wenn man über die /etc/fstab ntfs3 will, dann muss man es derzeit dort explizit setzen.

Man sieht das auch an:

jammy@jammyvm01:~$ ls -lisa /sbin/mount.ntfs
820042 0 lrwxrwxrwx 1 root root 13 Dez 18 11:47 /sbin/mount.ntfs -> mount.ntfs-3g
jammy@jammyvm01:~$ ls -lisa /sbin/mount.ntfs-3g
820043 0 lrwxrwxrwx 1 root root 12 Dez 18 11:47 /sbin/mount.ntfs-3g -> /bin/ntfs-3g
jammy@jammyvm01:~$ 
 

LG, Newubunti

Ich könnte mir nur vorstellen, dass Ubuntu dann, wenn der Zugriff auf FUSE oder NTFS-3G nicht möglich ist, als fallback auf den Kernel-Treiber ntfs3 zurückgreift und nicht, wie im Artikel geschrieben, mit ro auf den alten Kernel-Treiber. Wenn es so sein sollte, dann müsste man das noch genauer untersuchen.

Wie geschrieben, war es bei mir (Xubuntu 22.04, Upgrade von 20.04, alle Kernel-Updates gemacht) auch ohne fstab-Eintrag fuseblk…

Hallo Max-Ulrich_Farber,

mit welcher Ubuntu-Version hast Du getestet? Hattest Du weiter oben nicht mal erwähnt, dass Du Xubuntu verwendest, oder habe ich das falsch in Erinnerung?

LG, Newubunti

EDIT:

Hatte sich zeitlich wieder überschnitten.

Ich sehe da einen Unterschied. Bei Dir ist es ein Upgrade von 20.04 auf 22.04. Da ist es nach meiner Erfahrung sehr häufig so, dass das alter Verhalten erhalten bleibt.

Meine Test-Systeme sind alle vollständige Neuinstallationen.

Deine Beobachtungen dürften sich insofern mit den meinigen unter 20.04 decken.

Richtig! Aber Xubuntu - Ubuntu dürfte eigentlich egal sein. Beide verwenden gleichermaßen für GUI-Operationen GIO/GVfs.

jammy@jammyvm01:~$

Testest Du auf einer Virtuellen Maschine? Könnte sich daraus eine Erklärung geben?

Ich werde als nächstes mal noch ein Testprotokoll etablieren, bei dem ich - da ich ja im Vergleich zu Dir Neuinstallationen habe - jeweils unter allen Systemen (20.04 - 23.10) jeweils mit ntfs3 und ntfs-3g je eine Datei und einen Ordner anlege und dann mal beobachte, wie die in den jeweils anderen Systemen erscheinen.

LG, Newubunti

Max-Ulrich_Farber schrieb:

jammy@jammyvm01:~$

Testest Du auf einer Virtuellen Maschine? Könnte sich daraus eine Erklärung geben?

Ja, ich teste in virtuellen Maschinen. Es liegt aber IMO daran, dass es sich bei Dir um ein Upgrade von 20.04 auf 22.04 handelt und bei mir jeweils stets um Neuinstallationen.

Würde ich meine 20.04-Installation auf 22.04 upgraden, dann könnte ich sehr wahrscheinlich das gleiche Verhalten wie bei Dir beobachten.

LG, Newubunti

In dieser Richtung habe ich auch schon experimentiert, d.h. auf der gleichen Partition mit beiden Treibern und verschiedenen Optionen jeweils Ordner und Dateien angelegt und untersucht, wie diese sich dann unter dem anderen Treiber verhalten. Ein sauber gegliedertes "Testprotokoll" habe ich allerdings nicht angelegt.

Ich habe auch schon daran gedacht, in VMs native neuere Ubuntu-Versionen (also vor allem 23.10) anzulegen. Aber bei allem, was mit dem Einbinden von Partitionen zu tun hat, misstraue ich den mittels VM gewonnenen Aussagen.

Würde ich meine 20.04-Installation auf 22.04 upgraden, dann könnte ich sehr wahrscheinlich das gleiche Verhalten wie bei Dir beobachten.

Das kann gut sein. Aber das würde das Chaos nur noch verschlimmern!

Hänge bitte mal die Partition aus und hänge sie mit gio mount -d /dev/vdb1 wieder ein. Alles genau so? Und ist vdb1 eine "echte" NTFS-Partition oder eine Partition in einem VirtualBox-Container? Du kannst in die Box ja auch native Partitionen einbinden. Ändert das etwas?

Max-Ulrich_Farber schrieb:

Hänge bitte mal die Partition aus und hänge sie mit gio mount -d /dev/vdb1 wieder ein. Alles genau so?

jammy@jammyvm01:~$ id
uid=1000(jammy) gid=1000(jammy) Gruppen=1000(jammy),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),135(lxd),136(sambashare)
jammy@jammyvm01:~$ gio mount -d /dev/vdb1
jammy@jammyvm01:~$ mount | grep ntfs
/dev/vdb1 on /media/jammy/NTFSTEST type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,windows_names,uhelper=udisks2)
jammy@jammyvm01:~$ 
 

Ja, gio-mount und GUI-Mount verhalten sich genauso. Das war jetzt ein Test ohne Eintrag in der /etc/fstab, so dass man sehen kann, was das System selbständig ohne Angabe vom Typ wählt.

Und ist vdb1 eine "echte" NTFS-Partition oder eine Partition in einem VirtualBox-Container?

Meine Partition liegen alle auf virtuellen Disk-Images. Ich benutzt im übrigen libvirt-qemu/virt-manger, aber das macht hinsichtlich Deiner Frage keinen Unterschied.

Du kannst in die Box ja auch native Partitionen einbinden. Ändert das etwas?

Das könnte ich theoretisch, praktisch kann ich das nicht, weil ich keine "reale" NTFS-Partition auf dem Host habe.

Ich sehe in dem Punkt Virtualisierung für das was wir hier testen - Dateisysteme und Treiber/Module - auch kein Problem, solange wir uns dabei nicht über Performance unterhalten.

Auch teste ich nicht mit "externen" NTFS-Partitionen, die ich an einen virtuellen USB-Anschluss an die VM anschließen/durchreichen müsste, weil ich hier eher Verfälschungen vermute.

Meine Aussagen beziehen sich also immer auf "interne" NTFS-Partitionen.

Ich teste manche Dinge auch lieber an einem realen System, in diesem konkreten Fall habe ich keine Bedenken. Theoretisch wären im Hintergrund tätige udev-Regeln denkbar, die auf vd* nicht ansprechen, auf sd* etc. aber schon. Das konnte ich bis jetzt aber praktisch noch nicht beobachten.

LG, Newubunti

Theoretisch wären im Hintergrund tätige udev-Regeln denkbar, die auf vd* nicht ansprechen, auf sd* etc. aber schon. Das konnte ich bis jetzt aber praktisch noch nicht beobachten.

Um das sicher auszuschließen müsste man die Tests mit einer nativen Neuinstallation ohne VM ausführen. Das kommt für mich im Moment nicht in Frage. Ich verwende allerdings VENTOY auf einer externen HD. Ich muss mir mal überlegen, ob sich damit so etwas mit noch vertretbarer Mühe (!) machen lässt.

Meine Vermutung ist jetzt, dass uns das GIO/GVfs wieder einmal einen Streich spielt und mit einer neuen Überraschung dafür sorgt, dass es uns nicht langweilig wird. Damit, das Innenleben des GIO zu erforschen und herauszufinden, ob und ggf. wie man beeinflussen kann, wie dieses seine Dateisystem-Treiber ermittelt, fühle ich mich überfordert.

Denkbar ist für mich auch immer noch, dass es sich um ein fallback handelt, weil irgend ein Hindernis das Mounten mittels FUSE bzw. GVFS-3G verhindert hat. Vielleicht wären wir dann wieder bei allow_others, was ja keine Bedeutung hat, wenn ein fstab-Eintrag vorhanden ist oder mit Root-Rechten gemountet wird. Es wäre durchaus sinnvoll, wenn bei solch einem fallback nicht mehr der alte ntfs-Kerneltreiber, sondern jetzt ntfs3 verwendet würde. Diese Erklärung wäre mir, ehrlich gesagt, weitaus am liebsten.

EDIT:

Könntest Du vielleicht mal in /etc/fuse.conf die beiden Zeilen allow_other und user_allow_other eintragen und die VM neu starten. Ändert dies etwas?

Was willst Du im Moment eigentlich herausfinden?

Für mich steht eigentlich fest:

• Ab Ubuntu 22.04 bei Neuinstallation einhängen mittels GUI ⇒ ntfs3

• Vor Ubuntu 22.04 oder bei einem Upgrade einhängen mittels GUI ⇒ ntfs-3g

Ist doch eigentlich logisch, oder? Wenn bei einem Upgrade konsequent auch einfach auf ntfs3 umgestellt würde, dann könnte es da ja zu Problemen bei bestehenden NTFS-Partitionen kommen.

Oder habe ich einen Denkfehler, oder möchtest Du auf etwas anderes hinaus?

Könntest Du vielleicht mal in /etc/fuse.conf die beiden Zeilen allow_other und user_allow_other eintragen und die VM neu starten. Ändert dies etwas?

Probiere ich gleich mal. Was für eine Änderung erwartest Du?

LG, Newubunti