staging.inyokaproject.org

Hartmut2 schrieb:

D.h. hier scheint das fehlende 'users' zu wirken.

Super danke Dir. Damit bestätigt sich mein Verdacht: Bzgl. NTFS bewirkt die Option users nicht das, was sie soll.
Ich vermute mal, dass da noch ein sudo umount dazwischen war, denn mit sudo mount -a dürfte /media/E ja schon eingehangen gewesen sein.

Übrigens: Auch in 20.04 geht mount /media/Sicherung bei mir nicht ohne sudo trotz Option users. Aber immerhin geht da das Einhängen über "Klick" auf den Seitenleisten-Eintrag im Dateimanager und den Button in Laufwerke noch.
Auch auf meinem 18.04-System verhält es sich im Gegensatz zu Deinen Erinnerungen bei mir so, dass mount /media/Sicherung ohne sudo nicht geht. Das könnte daran liegen, dass auf meinen 18.04 durch Updates mittlerweile der fast identische NTFS-3G-Treiber installiert ist, wie auf 20.04:

• 18.04: NTFS-3G Version: 2017.3.23

• 20.04: NTFS-3G Version: 2017.3.23AR.3

• 22.04: NTFS-3G Version: 2021.8.23

• 22.10: NTFS-3G Version: 2022.5.17

Wenn ich's mir richtig notiert habe, dann haben FAT-Laufwerke standardmäßig '022' und das umask=000 soll Verbote (nicht Rechte) auf "alles erlaubt" setzen. Zumindest funktioniert's damit ☺

OK, danke, dann scheint das für FAT anders geregelt zu sein, wie für NTFS.

UlfZibis schrieb:

Ich vermute mal, dass da noch ein sudo umount dazwischen war, denn mit sudo mount -a dürfte /media/E ja schon eingehangen gewesen sein.

Nein, das war nicht der Fall. Das dürfte an dem 'noauto' liegen. Alle Laufwerke, die ein 'noauto' haben, sind bei mir nach einem 'sudo mount -a' nicht gemountet.

Auch auf meinem 18.04-System verhält es sich im Gegensatz zu Deinen Erinnerungen bei mir so, dass mount /media/Sicherung ohne sudo nicht geht.

Hier muß ich mich leider korrigieren. Ich benutze zum mounten und entmounten schon seit langem nicht mehr die Befehle 'mount' und 'umount', sondern ein kleines selbstgeschriebenes Programm, das das vereinfacht. Und ich war der festen Überzeugung, daß dieses Programm zum mounten den 'mount'-Befehl benutzt, musste aber jetzt feststellen, daß dies falsch war - stattdessen wird darin 'udisksctl' benutzt und es steht auch der Grund dabei: 'Verwendet den Befehl "udisksctl" statt "mount", weil nur damit auch NTFS-Partitionen OHNE sudo+password gemountet werden können'. Sorry für die gestiftete Verwirrung.

Wenn ich jetzt (mit 22.04) 'udisksctl' benutze, kommt bei allen NTFS-Laufwerken z.B. folgendes:

hg6@i3300:/media/D/Tst$ udisksctl mount -b /dev/sdb1
Error mounting /dev/sdb1: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting system-managed device /dev/sdb1: Unknown error when mounting /media/K

hg6@i3300:/media/D/Tst$ sudo udisksctl mount -b /dev/sdb1
[sudo] Passwort für hg6:
Mounted /dev/sdb1 at /media/K
hg6@i3300:/media/D/Tst$

D.h. seit dem Upgrade von 18.04 auf 22.04 liegt die Änderung darin, daß nun 'udisksctl' bei NTFS-Laufwerken ein sudo verlangt, selbst wenn in /etc/fstab die Option 'users' verwendet wird.

Mein Verdacht ist, daß (vielleicht aus Sicherheitsgründen) mit Absicht das mounten von NTFS-Laufwerken jetzt nur noch mit sudo erlaubt ist? Kann das jemand bestätigen?

Hartmut2 schrieb:

Danke für Deine Richtigstellungen.

Wenn ich jetzt (mit 22.04) 'udisksctl' benutze, ...

Ich kann bestätigen, das mit 20.04 udisksctl noch ohne sudo für NTFS funktioniert, mit 22.04 nicht mehr. Weiterhin kann ich bestätigen, dass mit 20.04 udisksctl für NTFS auch dann ohne sudo funktioniert, wenn ich users weglasse.

Das legt nahe, dass Dateimanager und Laufwerke auch udisksctl verwenden. Das wäre die Erklärung für meine Eingangsfrage.

Wir können zusätzlich festhalten, dass nun sowohl udisksctl als auch mount die Option users in Zusammenhang mit NTFS ignorieren.

Wie funktioniert udisksctl bei Dir denn bei einer FAT-Partition, wenn du users weglässt?

Mein Verdacht ist, daß (vielleicht aus Sicherheitsgründen) mit Absicht das mounten von NTFS-Laufwerken jetzt nur noch mit sudo erlaubt ist?

Mich würde auch interessieren, warum da für NTFS höhere Sicherheitsbedenken bestehen sollen, wie für FAT. (Ich hasse dieses "aus Sicherheitsgründen" ohne weitere nachvollziehbare Erklärung, meist dient es zur Übertünchung der wahren Gründe.)

Hartmut2 schrieb:

Wenn ich's mir richtig notiert habe, dann haben FAT-Laufwerke standardmäßig '022' und das umask=000 soll Verbote (nicht Rechte) auf "alles erlaubt" setzen. Zumindest funktioniert's damit ☺

Noch besser wäre dann wohl dmask=0022,fmask=0133, siehe: mount (Abschnitt „Standard-Rechte-Einstellung-bzw-unterschiedliche-Rechte-fuer-Ordner-und-Dateien-verwenden“)

Moin,

Kernel > 5.15 ist ja vorhanden.

Hast du den "neuen" ntfs3 Treiber mal probiert?

https://superuser.com/questions/1723455/how-to-mount-ntfs-in-linux-without-root-password

san04 schrieb:

Hast du den "neuen" ntfs3 Treiber mal probiert?

Was bedeutet "neu"? Das Problem besteht ja hier gerade mit dem neueren, mit dem älteren hat es ja jahrelang funktioniert.

https://superuser.com/questions/1723455/how-to-mount-ntfs-in-linux-without-root-password

Danke für den Hinweis. Allerdings nutze ich bereits "integrated FUSE", scheint also nicht zu helfen ☹

$ ntfs-3g --version
ntfs-3g 2021.8.22 integrated FUSE 28

UlfZibis schrieb:

Wie funktioniert udisksctl bei Dir denn bei einer FAT-Partition, wenn du users weglässt?

Das funktioniert. Habe 1 Zeile in /etc/fstab folgendermaßen geändert:

LABEL=INSTALL     /media/E  vfat  defaults,noauto,umask=000,utf8  0 0

Hab dann folgendes eingegeben:

hg6@i3300:/media/D/Tst$ sudo mount -a
[sudo] Passwort für hg6:
hg6@i3300:/media/D/Tst$

hg6@i3300:/media/D/Tst$ udisksctl mount -b /dev/sda5
Mounted /dev/sda5 at /media/E
hg6@i3300:/media/D/Tst$

Frage: weiß jemand noch einen anderen Befehl außer 'mount' und 'udisksctl', mit dem man ein NTFS-Laufwerk - jedoch ohne sudo - mounten kann, wenn es in /etc/fstab (oder woanders) entsprechend konfiguriert ist?

Hartmut2 schrieb:

UlfZibis schrieb:

Wie funktioniert udisksctl bei Dir denn bei einer FAT-Partition, wenn du users weglässt?

Das funktioniert. ...

Danke Dir. udisksctl scheint sich nicht für die Option users zu interessieren, was aufgrund des Namens ja auch naheliegend ist.

Aber wie verhält es sich mit mount (statt udisksctl), wenn users bei FAT fehlt? Hat die Option da wenigstens Wirkung?

Frage: weiß jemand noch einen anderen Befehl außer 'mount' und 'udisksctl', mit dem man ein NTFS-Laufwerk - jedoch ohne sudo - mounten kann, wenn es in /etc/fstab (oder woanders) entsprechend konfiguriert ist?

Es könnte evtl. über das setuid-Flag in Verbindung mit einer zusätzlichen ntfsuser-Gruppe funktionieren, siehe hier die oberste Frage.

Insgesamt finde ich das aber einen Bug in Ubuntu, wenn users nicht einfach das tut, was es soll.

UlfZibis schrieb:

Aber wie verhält es sich mit mount (statt udisksctl), wenn users bei FAT fehlt? Hat die Option da wenigstens Wirkung?

Das hatte ich bereits hier getestet.

Frage: weiß jemand noch einen anderen Befehl außer 'mount' und 'udisksctl', mit dem man ein NTFS-Laufwerk - jedoch ohne sudo - mounten kann, wenn es in /etc/fstab (oder woanders) entsprechend konfiguriert ist?

Es könnte evtl. über das setuid-Flag in Verbindung mit einer zusätzlichen ntfsuser-Gruppe funktionieren, siehe hier die oberste Frage.

Danke für den Tipp. Diese FAQ's hatte ich auch schonmal gefunden, verstehe davon aber das meiste nicht. Weiß Du, was FUSE in dem Zusammenhang bedeutet?

Hallo,

Was bedeutet "neu"?

Neu heißt, dass es ab Kernel 5.15 ein vollwertigen NTFS-Treiber direkt im Kernel gibt, der von den Kernelentwicklern gepflegt wird. Der alte NTFS-Treiber des Kernels konnte nur read-only, der NTFS-3G Treiber lief "nur" via FUSE im Userspace.

Details:

• https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html

• https://www.paragon-software.com/home/ntfs3-driver-faq/

Oder mit einer Suchmaschine deiner Wahl nach "linux kernel 5.15 ntfs" suchen.

Gruß, noisefloor

Hartmut2 schrieb:

Das hatte ich bereits hier getestet.

Sorry, ja ich bin schon ganz kirre.

Weiß Du, was FUSE in dem Zusammenhang bedeutet?

Siehe FUSE

UlfZibis schrieb:

Weiß Du, was FUSE in dem Zusammenhang bedeutet?

Siehe FUSE

Besten Dank.

noisefloor schrieb:

Neu heißt, dass es ab Kernel 5.15 ein vollwertigen NTFS-Treiber direkt im Kernel gibt, der von den Kernelentwicklern gepflegt wird. Der alte NTFS-Treiber des Kernels konnte nur read-only, der NTFS-3G Treiber lief "nur" via FUSE im Userspace.

Interessant, das wusste ich ja noch gar nicht. Danke für die Aufklärung! Hier auf 20.04 habe ich den Kernel 5.15.0-71-generic, der ntfs3-Treiber müsse also da drin sein. So habe ich nun mal ntfs3 statt ntfs in die fstab geschrieben. Leider klappt das nicht:

$ mount /media/Sicherung/
mount: /media/Sicherung: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/sda24 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.

Auch mit sudo bekomme ich den gleichen Fehler. Woran kann das nun liegen?

Auf 22.04 mit Kernel 5.19.0-41-generic dasselbe Ergebnis.

• https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html

• https://www.paragon-software.com/home/ntfs3-driver-faq/

Wie ich der Dokumentation entnehme, kann der nicht alles, was der NTFS-3G-Treiber kann, z.B. kein UserMapping und kennt auch nicht alle Optionen, wie z.B. permissions. Na mal sehen, wie der sich entwickelt.

UlfZibis schrieb:

Na mal sehen, wie der sich entwickelt.

Wie sehen deine nächsten Aktivitäten aus?
Ist das Thema damit für dich (wenn auch unbefriedigend) erledigt bzw. gelöst?

Berlin_1946 schrieb:

Wie sehen deine nächsten Aktivitäten aus?

Warten bis jemand klären kann, wie man in den Genuss und den Nutzen von NTFS3 im Kernel >= 5.15 kommt und / oder wie man die Option users zum Funktionieren bringt.

Ist das Thema damit für dich (wenn auch unbefriedigend) erledigt bzw. gelöst?

Auf keinen Fall!