ubuntuusers.de

Newubunti schrieb:

Liefert bei mir Error: Page not found.

Das liegt wohl daran, dass ich da den Haken für Security gesetzt habe, da die Sache ja auch sicherheitrelevant ist. Außerdem beschleunigt es, dass sich das mal jemand anguckt. Der Text ist folgender:

Bug Title:  mount option `users` blocks ntfs to mount

Package: util-linux (Ubuntu)

Bug Description

/etc/fstab:
# /media/Sicherung was on /dev/sda7 during installation
UUID=2510AA16624BB80C /media/Sicherung ntfs defaults,users,noauto,windows_names,hide_dot_files 0 0

$ gio mount -d /dev/sda7
gio: /dev/sda7: Error mounting system-managed device /dev/sda7: Unknown error when mounting /media/Sicherung

$ udisksctl mount -b /dev/sda7
Error mounting /dev/sda7: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting system-managed device /dev/sda7: Unknown error when mounting /media/Sicherung

$ journalctl -b 0 -u udisks2.service
Feb 27 23:48:51 T500 udisksd[10478]: Error opening read-only '/dev/sda7': Keine Berechtigung
Feb 27 23:48:51 T500 udisksd[10478]: Failed to mount '/dev/sda7': Keine Berechtigung
Feb 27 23:48:51 T500 udisksd[10478]: Please check '/dev/sda7' and the ntfs-3g binary permissions,
Feb 27 23:48:51 T500 udisksd[10478]: and the mounting user ID. More explanation is provided at
Feb 27 23:48:51 T500 udisksd[10478]: https://github.com/tuxera/ntfs-3g/wiki/NTFS-3G-FAQ

This worked fine until Ubuntu 20.04, but since 22.04 I have these errors.

Additionally, mount option `users` does not, what it should do:

$ LC_ALL=C mount /media/Sicherung
Error opening read-only '/dev/sda7': Permission denied
Failed to mount '/dev/sda7': Permission denied
Please check '/dev/sda7' and the ntfs-3g binary permissions,
and the mounting user ID. More explanation is provided at
https://github.com/tuxera/ntfs-3g/wiki/NTFS-3G-FAQ

When removing `users` from /etd/fstab, at least gio mount works:

$ LC_ALL=C journalctl -b 0 -u udisks2.service
Feb 28 00:05:31 T500 ntfs-3g[10977]: Version 2021.8.22 integrated FUSE 28
Feb 28 00:05:31 T500 ntfs-3g[10977]: Mounted /dev/sda7 (Read-Write, label "Sicherung", NTFS 3.1)
Feb 28 00:05:31 T500 ntfs-3g[10977]: Cmdline options: rw,windows_names,hide_dot_files
Feb 28 00:05:31 T500 ntfs-3g[10977]: Mount options: allow_other,nonempty,relatime,rw,fsname=/dev/sda7,blkdev,blksize=4096
Feb 28 00:05:31 T500 ntfs-3g[10977]: Ownership and permissions disabled, configuration type 7
Feb 28 00:05:31 T500 udisksd[583]: Mounted /dev/sda7 (system) at /media/Sicherung on behalf of uid 1000

So it seems, that option `users` virtually effectuates the opposite, than it is supposed to do.

Wenn Du Verbesserungsideen hast, kann ich das gerne noch korrigieren.

When removing users from /etd/fstab, at least gio mount works:

Tippfehler: etc/fstab

Berlin_1946 schrieb

Tippfehler: etc/fstab

Hallo,

ich habe inzwischen mal noch getestet, ob udisks2 (udisksctl) generell Probleme mit der Option users in der /etc/fstab hat. Und dem ist nicht so. Sowohl bei ext4, als auch bei exfat-fuse kann mit udisksctl gemountet werden, wenn die Option users gesetzt ist. Das spricht dafür, dass das Problem eher bei ntfs-3g zu verorten ist.

LG, Newubunti

UlfZibis schrieb:

Ich habe das dann mal als Bug gepostet: 2055226

Newubunti schrieb:

ich habe inzwischen mal noch getestet, ob udisks2 (udisksctl) generell Probleme mit der Option users in der /etc/fstab hat. Und dem ist nicht so. Sowohl bei ext4, als auch bei exfat-fuse kann mit udisksctl gemountet werden, wenn die Option users gesetzt ist. Das spricht dafür, dass das Problem eher bei ntfs-3g zu verorten ist.

👍

Und der Bug 2055226 ist wohl mittlerweile öffentlich und es wurde auch schon reagiert. Vielleicht magst Du den dort bestätigen, auch mittels "affects me", dann zählt er als "confirmed".

UlfZibis schrieb:

Newubunti schrieb:

Deinen Link auf den BUG-Report (Stichwort: noauto,user(s)), weil unklar, ob das überhaupt ein BUG oder Ursache des restriktiven Mount-Verhaltens von ntfs-3g ist. Dazu antworte ich Dir heute auch noch in Deinem diesbezüglichen Thread.

Eben weil die Sache unklar ist, finde ich einen Hinweis auf die Stelle, die diese Unklarheit behandelt, und (hoffentlich) in Zukunft ausmerzt wird, sinnvoll. Die Unklarheit ist erst aufgehoben, wenn entweder dem "restriktiven Mount-Verhalten von ntfs-3g" abgeholfen wird, oder dieses in mount dokumentiert ist. Man könnte auch sagen, ntfs-3g hält sich nicht an den "contract" von mount, ist also "nicht kompatibel", wobei es auch sein kann, dass die "Inkompatibilität" durch die Zwischenschichten FUSE oder udisks "verschuldet" wird. Für letzteres spricht der Kommentar der Entwickler.

Ich verstehe nicht, auf was für ein Verhalten Du eigentlich hinaus willst. Wenn man die Option user(s) im Zusammenspiel mit noauto weglässt, dann kann man mittels Programmen, die auf udisks zurückgreifen, erfolgreich einhängen. Selbst wenn sich "udisks" oder "fuse" oder "ntfs-3g" nicht direkt an user(s) stören würden, dann erzielt die Option im Zusammenspiel mit mount.ntfs-3g nicht den gewünschten Effekt, weil mit mount /my/mountpoint kann man so oder so als unprivilegierter Nutzer nicht einhängen und das ist auch schon unter 20.04 so.

Ich komme daher zum jetzigen Zeitpunkt zu dem Schluss, dass eher das Verhalten unter 20.04 fehlerhaft ist, weil es den Anschein erweckt, dass die Option user(s) im Zusammenspiel mit ntfs-3g funktioniert, was aber tatsächlich nicht (vollends) der Fall ist.

EDIT: Hat eigentlich jemand schon mal getestet, wie sich NTFS3 unter den Optionen noauto,user(s) verhält ?

Ja, das habe ich und das funktioniert problemlos. Was aber hinsichtlich ntfs-3g gar nichts aussagt, weil Kernel-Module nicht erst eine Brücke zum Kernelspace bauen müssen, wie das bei externen Treibern der Fall ist.

IMO am ehesten mit ntfs-3g vergleichbar ist exfat-fuse, weil auch ein Kernel-externer fuseblk Treiber. Und der verhält sich, wie für solche Treiber in der Regel beschrieben, noauto,user(s) funktionieren ab dem Moment, ab dem für mount.Dateisystemtreiber - also z.B. mount.exfat-fuse - das SUID-Bit gesetzt ist.

Kein anderer Treiber außer ntfs-3g hat dieses eigentümliche Verhalten, dass er trotz SUID-Bit für das Mount-Programm auch noch zusätzlich verlangt, dass der Nutzer, der das Mount-Kommando veranlasst selbst auch noch /dev lesen und schreiben können muss, wenn dabei auch gleichzeitig noch FUSE im Spiel ist. Dieses Verhalten von mount.ntfs-3g ist auch nicht neu, sondern besteht wohl seit jeher und schon immer wird sich darüber gewundert:

frostschutz schrieb z.B. 2011!!!:

Das Problem ist, daß ntfs-3g trotz gesetztem suid-Bit, noch selber ein paar Sicherheitschecks machen möchte. D.h. rein von den Rechten her könnte ntfs-3g dank suid das Ding problemlos mounten, verhindert das dann aber selbst weil ihm das aus welchen Gründen auch immer, dann doch nicht passt. Das suid Bit ist von daher gesehen, leider völliger Nonsens. Ergo vergiss das und mach das stattdessen per sudo. Du brauchst dem User dazu keine vollen Root-Rechte geben, sondern einfach in /etc/sudoers eben speziell nur den passenden Mount/Umount-Befehl freischalten. Ist halt etwas Handarbeit, aber dafür funktioniert das dann auch.

LG, Newubunti

Newubunti schrieb:

Ich verstehe nicht, auf was für ein Verhalten Du eigentlich hinaus willst.

1. Dass die Optionen user(s) in der fstab mount für beliebige Benutzer erlaubt, genau so, wie in mount beschrieben.
   Oder dass alternativ in mount vermerkt ist, dass diese Optionen nicht für alle Dateisysteme nutzbar sind.

2. Dass udisks und / oder FUSE die Optionen user(s) in der fstab ignorieren, bzw. mindestens keine Fehler werfen.

... weil mit mount /my/mountpoint kann man so oder so als unprivilegierter Nutzer nicht einhängen und das ist auch schon unter 20.04 so.

Verstehe ich nicht, genau dafür sind die Optionen user(s) laut mount doch da.

Ich komme daher zum jetzigen Zeitpunkt zu dem Schluss, dass eher das Verhalten unter 20.04 fehlerhaft ist, weil es den Anschein erweckt, dass die Option user(s) im Zusammenspiel mit ntfs-3g funktioniert, was aber tatsächlich nicht (vollends) der Fall ist.

Fehlerhaft ist doch nur das, was mount widerspricht. Und ja, auch unter 20.04 hat mount mit noauto,users nicht ordnungsgemäß funktioniert, was mir aber früher nicht aufgefallen war, weil ich es nur für die GUI genutzt hatte.

EDIT: Hat eigentlich jemand schon mal getestet, wie sich NTFS3 unter den Optionen noauto,user(s) verhält ?

Ja, das habe ich und das funktioniert problemlos.

Na das spricht doch dafür, dass noauto,users tatsächlich so gemeint sind, wie ich es aus der man mount herausgelesen habe.

Was aber hinsichtlich ntfs-3g gar nichts aussagt, weil Kernel-Module nicht erst eine Brücke zum Kernelspace bauen müssen, wie das bei externen Treibern der Fall ist.

Das ist zwar der technische Hintergrund, der sollte mount gemäß man aber nicht interessieren.

Dieses Verhalten von mount.ntfs-3g ist auch nicht neu, sondern besteht wohl seit jeher und schon immer wird sich darüber gewundert:

frostschutz schrieb z.B. 2011!!!:

Das Problem ist, daß ntfs-3g trotz gesetztem suid-Bit, noch selber ein paar Sicherheitschecks machen möchte. D.h. rein von den Rechten her könnte ntfs-3g dank suid das Ding problemlos mounten, verhindert das dann aber selbst weil ihm das aus welchen Gründen auch immer, dann doch nicht passt. Das suid Bit ist von daher gesehen, leider völliger Nonsens. Ergo vergiss das und mach das stattdessen per sudo. Du brauchst dem User dazu keine vollen Root-Rechte geben, sondern einfach in /etc/sudoers eben speziell nur den passenden Mount/Umount-Befehl freischalten. Ist halt etwas Handarbeit, aber dafür funktioniert das dann auch.

Danke für die Recherche. 👍

Newubunti schrieb:

... ohne dass der Nutzer, der mount.ntfs-3g initiiert, auch noch zusätzlich lesend und schreibend auf /dev/... zugreifen können muss.

Ja da ist was dran. ntfs-3g fordert quasi unmögliches.

Da sie davon aber schon seit mindesten 12 Jahren kein Abstand nehmen,

Hm, mag sein. Als die Dokumentation und Entwicklung noch auf der Tuxera- bzw. der privaten Seite von Jean-Pierre André stattfand, ist mir so eine Regelliste, wie sie jetzt auf GitHub steht, nie aufgefallen.

zumal man das in der Praxis heute eigentlich auch nicht mehr in der Form braucht.

Naja, ob man mount ohne Root-Rechte braucht oder nicht, ist doch nicht so entscheidend. Solange mount die Optionen noauto,users ganz allgemein anbietet, sollten sie auch funktionieren.