staging.inyokaproject.org

Für Einbindung per mount gib die Option user in der fstab an.

Wo außer in einer Server-Version ohne GUI braucht man das überhaupt? Und wer wird in einem Server eine Partition ohne Root-Rechte einbinden wollen? Abgesehen davon weiß ich nicht, ob nicht udisksctl -b … sogar auch ohne GUI funktionieren würde (gio mount -d … natürlich mit Sicherheit nicht).

Ein solcher Eintrag ist aber nützlich, wenn man z.B. den Einbindeort oder bestimmte Mount-Optionen festlegen will.

Ok. Aber müssen unprivilegierte Benutzer das wiklich können? Und andere können ja, wie ich es auch tue, mittels sudo… einbinden. Das ist mir zehnmal lieber als ein SUID-Bit.

Aber gegen einen kurzen einzeiligen Hinweis, vielleicht auch als Experten-Info, habe ich nichts einzuwenden. Doch es sollte jedenfalls deutlich werden: "Der normale Weg ist das nicht".

Deshalb würde ich empfehlen: Ohne Root-Rechte wenn möglich immer nur udisks2 und keine Experimente mit SUID-Bit, mount und users. Und wer es trotzdem nicht lassen kann, soll bitte im Artikel mount nachlesen, was sich da vielleicht doch machen lässt.

kB schrieb:

M.E. kann man das Thema „Mount-Option user“ in diesem Artikel nicht ganz vermeiden, denn es gibt für die Praxis einen relevanten Unterschied:

Sehr gut ausgearbeitet, die Erklärung.

1. Wer als normaler Benutzer das Programm mount zum Einbinden mit ntfs-3g benutzen will, benötigt dafür einen Eintrag in der Datei fstab mit der Mount-Option user.

Muss dafür nicht auch das SUID-Bit gesetzt werden?

Daher lautet die Empfehlung an den Praktiker:

• Für Einbindung per mount gib die Option user in der fstab an.

• Für Einbindung über GUI oder udisksctl gib user nicht an, da es zum Fehler führt. Auch nicht users oder nousers.

Ja, beides gleichzeitig schließt sich aus.

Max-Ulrich_Farber schrieb:

Ok. Aber müssen unprivilegierte Benutzer das wiklich können? Und andere können ja, wie ich es auch tue, mittels sudo… einbinden.

Es gibt aber noch die große Masse der Normalbenutzer – zwischen "unprivilegiert" und (Terminal-)Experten – die für den täglichen bequemen Zugang die GUI bevorzugen, auch wenn sie dafür einmalig fstab richtig einrichten müssen.

Das ist mir zehnmal lieber als ein SUID-Bit.

Ist doch für alles auf udiskctl aufbauendes nicht nötig.

Und wer es trotzdem nicht lassen kann, soll bitte im Artikel mount nachlesen, was sich da vielleicht doch machen lässt.

Und da findet er die Option users, die in Zusammenhang mit ntfs-3g nicht so funktioniert, wie dort beschrieben, deshalb IMHO ein Bug: 2055226.

kB schrieb:

M.E. kann man das Thema „Mount-Option user“ in diesem Artikel nicht ganz vermeiden, denn es gibt für die Praxis einen relevanten Unterschied:

1. Wer als normaler Benutzer das Programm mount zum Einbinden mit ntfs-3g benutzen will, benötigt dafür einen Eintrag in der Datei fstab mit der Mount-Option user.

Auch die Option user funktioniert bei mir mit keiner aktuellen Ubuntu-Version für unprivilegierte Nutzer.

mount funktioniert für unprivilegierte Nutzer gar nicht. Und diese Besonderheit hat ntfs-3g exklusiv. Jedenfalls habe ich noch keinen anderen Treiber gefunden - sicher habe ich auch nicht alle probiert - die dieses Verhalten zeigen. exfat-fuse verhält sich jedenfalls nicht so, sondern der verhält sich so, wie in mount beschrieben und lässt sich sowohl mit users, user, nouser wie erwartet benutzen.

Daher finde ich, dass das thematisch am besten hierher gehört, weil eine spezielle Eigenart von /bin/ntfs-3g und nicht etwa von mount oder FUSE generell.

LG, Newubunti

Ich muss doch nochmal nachfragen:

kB schrieb:

Stand heute: ntfs-3g verhält sich bzgl. nouser/user/users völlig regelgerecht!

und nun ist doch immer wieder von dem Bug die Rede, dass NTFS-3G mit diesen Optionen nicht klar kommt. Das ist ja nicht "regelgerecht". – Was gilt jetzt? Ich möchte nicht selbst jetzt weider alle diesbezüglichen Tests wiederholen!

Sicher habe ich da irgend etwas nicht richtig verstanden, wahrscheinlich was mit "regelgerecht" gemeint ist. kB: Könntest du mir bitte dies nochmal erklären? Ich bin manchmal etwas schwer von Begriff…

Auch bei dem Beitrag von UlfZibis ist mir noch manches unklar. Ich will versuchen, trotzdem zu antworten:

Muss dafür nicht auch das SUID-Bit gesetzt werden?

Aber ja! Darum geht es doch gerade, und das würde ich eben gerne umgehen.

Ja, beides gleichzeitig schließt sich aus.

Das sagt ja gerade kB. Nur warum das zu dem "Fehler" führt, durchschaue ich nicht recht. Deshalb meine obige Frage an kB.

Es gibt aber noch die große Masse der Normalbenutzer – zwischen "unprivilegiert" und (Terminal-)Experten – die für den täglichen bequemen Zugang die GUI bevorzugen, auch wenn sie dafür einmalig fstab richtig einrichten müssen.

Es geht hier doch um "interne" Partitionen mit hintsystem=yes und um unprivilegierte Benutzer. Die werden wohl nicht im alltäglichen Gebrauch interne Partitionen ohne Root-Rechte einbinden, und außerdem können sie ja gar nicht die fstab richtig einrichten. Oder worüber sprechen wir?

deshalb IMHO ein Bug: 2055226.

Eben, aus der Bug-Beschreibung werde ich nicht klug, genau so wenig wie aus den dortigen Antworten. Deshalb meine Frage: Verhält sich NTFS-3G nun "regelgerecht" oder nicht?

@Newubunti:

Auch die Option user funktioniert bei mir mit keiner aktuellen Ubuntu-Version für unprivilegierte Nutzer.

Deshalb mein Vorschlag: Einfach für alle davon abraten. Ein Sätzchen genügt.

Daher finde ich, dass das thematisch am besten hierher gehört, weil eine spezielle Eigenart von /bin/ntfs-3g und nicht etwa von mount oder FUSE generell.

Dem widerspreche ich ja nicht. Nur meine ich: "user und users sind bei NTFS-3G zu vermeiden" deckt das hinreichend ab. Denn ich sehe (bis jetzt noch) nicht, wozu man die Optionen wirklich braucht. Ob das nun Bug oder Feature ist, ändert ja daran nichts. Zu einer Erklärung sind wir im Wiki nicht verpflichtet.

off topic

Ich muss meine zu allgemeine Aussage doch noch etwas relativieren. Bei lokalen Partitionen sind die Optionen user und users IMO überflüssig geworden, weil inzwischen udisks2 auch ohne diese bessere Möglichkeiten bietet. Bei Netzwerk-Dateisystemen, bei denen es nichts zu udisk2 Entsprechendes gibt, mag dies wohl anders sein. Aber das gehört nicht hierher, und für NTFS-3G ist das ja irrelevant.

Ich habe jetzt noch mal ein bisschen unter 22.04 mit LTS-Kernel 5.15 getestet – vollständiger als bisher. Dazu erst mal folgende Voraussetzungen:

1. fstab: UUID=2510AA16624BB80C /media/Sicherung ntfs defaults,noauto,users,windows_names,hide_dot_files 0 0

2. sudo chmod u+s /usr/bin/ntfs-3g

3. sudo chmod 777 /media/Sicherung

4. sudo chmod 666 /dev/sda7

Der Befehl

mount /media/Sicherung 

wird ausgeführt, und der Besitzer der Dateien ist 1000. Nehme ich eine der letzten 3 Bedingungen weg ( u-s, 755, 660 ), wird das Einbinden verweigert. Setze ich sudo chmod 664 /dev/sda7, wird immerhin read-only eingebunden.
Nehme ich users aus der fstab raus, ändert sich absolut nichts und der Besitzer der Dateien ist dennoch 1000. D.h. users hat im Zusammenhang mit NTFS-3G und entgegen mount absolut keine Auswirkung auf mount (anders als ich bisher dachte). IMHO –⇒ Bug.

Nun weiter mit

udisksctl mount -b /dev/sda7 

Sind alle obigen Bedingungen erfüllt, wird das Einbinden ausgeführt, und der Besitzer der Dateien ist 1000. Nehme ich nur eine der letzten 3 Bedingungen weg ( u-s, 755, 660 ), wird das Einbinden verweigert (dies war unter 20.04 noch nicht so, obwohl evtl. unlogisch). Setze ich sudo chmod 664 /dev/sda7, wird auch nur read-only eingebunden (ohne dass dies aus "Mounted /dev/sda7 at /media/Sicherung" hervorgeht).
Nehme ich users aus der fstab raus, ändert sich nichts, außer dass der Besitzer der Dateien nun 0 ist. Nehme ich nun auch noch eine der letzten 3 oder gleich alle 3 Bedingungen weg ( u-s, 755, 600 ), wird das Einbinden hier nicht verweigert. D.h. users hat im Zusammenhang mit NTFS-3G also Auswirkung auf udisksctl mount, aber eben nicht auf mount (also fast genau umgekehrt als bisher gedacht). Dies ist meines Wissens nirgendwo dokumentiert, also auch IMHO –⇒ Bug.

Somit ist das, was ich in Bug 2055226 angegeben habe, unvollständig.

Max-Ulrich_Farber schrieb:

Muss dafür nicht auch das SUID-Bit gesetzt werden?

Aber ja! Darum geht es doch gerade, und das würde ich eben gerne umgehen.

Ich fand nur, dass da die Darstellung von kB evtl. unvollständig war.

Es geht hier doch um "interne" Partitionen mit hintsystem=yes und um unprivilegierte Benutzer. Die werden wohl nicht im alltäglichen Gebrauch interne Partitionen ohne Root-Rechte einbinden, und außerdem können sie ja gar nicht die fstab richtig einrichten. Oder worüber sprechen wir?

Ja, aber die Belange der "normalen" Benutzer wurden dabei nicht berücksichtigt.

@UlfZibis

Ich muss passen. Ich verstehe nur noch "Bahnhof". Nach welchem Plan hast du denn getestet?

Max-Ulrich_Farber schrieb:

[…]

Ich vermute bei Dir ein Missverständnis:

Ich referiere in meinem Beitrag nur die technischen Randbedingungen bzgl. der Option user und adressiere keine bestimmte Benutzergruppe. Allerdings erwarte ich, dass im Wiki sowohl naive „Nur-Benutzer“ genauso berücksichtigt wie Administratoren.

Wenn es um die Einbindung eines weiteren Dateisystems für einen „Nur-Benutzer“ geht, sind das alles vernünftige Wege:

• Automatische Einbindung beim Hochfahren des Systems → fstab mit Option auto

• Vorbereitete Einbindung → fstab mit Option noauto und

  1. Entweder Option user, wenn der normale Benutzer mount verwenden soll (was ich nicht empfehle, aber möglich ist und manchmal sogar notwendig sein mag, z.B. wenn die Anwendungssoftware diesen Weg voraussetzt),

  2. Oder explizit ohne Option user (inkl. verwandte Optionen), wenn direkt oder indirekt UDisks verwendet werden soll

• Temporäre Einbindung bei Bedarf, z.B. beim Einstecken als USB → läuft automatisch, der Administrator muss aber zur Sicherstellung der gewünschten Funktion (Einbindepunkt, Sichtbarkeit in der GUI, Mount-Optionen etc.) ggf. UDisks2 konfigurieren oder einen Eintrag in fstab bereitstellen → s.o. Punkt 2

Wenn es unbedingt Weg 1 sein muss, dann (nur dann!!) muss auch auch die Anforderungen von FUSE beachten, d.h. SUID für ntfs-3g setzten und die Dateiberechtigungen für Einbindepunkt (problemlos) und Gerätedatei des Blockgerätes (sicherheitstechnisch höchst problematisch!!) erfüllen.

Aus meiner Sicht ist der Artikel besonders für den Administrator wichtig, dessen Aufgabe die Sicherstellung der gewünschten Funktion für naive „Nur-Benutzer“ ist.

UlfZibis schrieb:

[…] Nehme ich nur eine der letzten 3 Bedingungen weg ( u-s, 755, 660 ), wird das Einbinden verweigert (dies war unter 20.04 noch nicht so, obwohl evtl. unlogisch).

Die Einbindung scheitert, wenn die Bedingungen von FUSE nicht erfüllt sind. Das hat mit ntfs-3g direkt nichts zu tun, sondern ist nur zwangsweise Folge des Umstandes, dass ntfs-3g nun mal ein FUSE-Programm ist. Und ich beobachte genau dieses Verhalten auch bei 20.04 und zurück bis 16.04.

Das ist alles bestimmungsgemäße Funktion (von FUSE).

[…] Nehme ich users aus der fstab raus, ändert sich nichts, außer dass der Besitzer der Dateien nun 0 ist.

Das ist eine logische Folge, weil nun die Einbindung von root ausgeführt wird.

Nehme ich nun auch noch eine der letzten 3 oder gleich alle 3 Bedingungen weg ( u-s, 755, 600 ), wird das Einbinden hier nicht verweigert.

Wenn die Einbindung von root ausgeführt wird, sind ja die Bedingungen von FUSE immer erfüllt, denn root ist root und Dateiberechtigungen gelten nicht für root.

Max-Ulrich_Farber schrieb:

Ich muss doch nochmal nachfragen:

kB schrieb:

Stand heute: ntfs-3g verhält sich bzgl. nouser/user/users völlig regelgerecht!

und nun ist doch immer wieder von dem Bug die Rede, dass NTFS-3G mit diesen Optionen nicht klar kommt. Das ist ja nicht "regelgerecht". – Was gilt jetzt? Ich möchte nicht selbst jetzt weider alle diesbezüglichen Tests wiederholen!

Sicher habe ich da irgend etwas nicht richtig verstanden, wahrscheinlich was mit "regelgerecht" gemeint ist. kB: Könntest du mir bitte dies nochmal erklären? Ich bin manchmal etwas schwer von Begriff…

• Ich habe in 2024 das Verhalten von ntfs-3g mehrere Male getestet und fand dabei Fehlfunktionen bzgl. einer übergebenen Option *users* und habe auch hier darüber berichtet. Leider finde ich meinen Beitrag nicht wieder.

• Bei einer weiteren Wiederholung dieses Test, über den ich ebenfalls hier berichtet habe, konnte ich Fehlverhalten nicht mehr reproduzieren.

Erstens: Ich kann mir diesen Widerspruch nur durch ein zwischenzeitlich erfolgtes Update erklären, habe das aber nicht überprüft. Es mag also zutreffen, dass manche Versionen von ntfs-3g intern einen BUG bzgl. der Auswertung solcher Zeichenfolgen *user* haben oder auch nicht. Da aber solche Optionen ntfs-3g gar nichts angehen, ist es besser, vorsichtshalber *user* im Zusammenhang mit ntfs-3g zu vermeiden, was ja auch ohne Einschränkungen für die Benutzer möglich ist – wenn man die richtigen Werkzeuge wählt.

Zweitens: Unabhängig von einer Existenz eines solchen internen BUGs verhält sich das FUSE-Programm ntfs-3g natürlich unterschiedlich, je nachdem ob es als root läuft oder mit SUID-Bit von einem normalen Benutzer gestartet wird oder ohne SUID-Bit als normaler Benutzer läuft. Das ist kein Fehlverhalten, führt aber zu unterschiedlichen Ergebnissen bis hin zum Scheitern.

Drittens verhält sich udisksd unterschiedlich, je nachdem in den Optionen user enthalten ist oder nicht. Meine bisherigen Beobachtungen finden eine plausible Erklärung, wenn udisksd das nachgeschaltete Programm ntfs-3g als root startet, wenn users nicht angegeben ist, und als normaler Benutzer, wenn es angegeben wurde. Damit gilt dann vorstehender Satz. Die Verwendung von nouser mit udisksd ist bei ntfs-3g auch ungeschickt, weil dann zwar udisksd alles richtig macht, aber ntfs-3g vielleicht doch – wie ursprünglich von mir beobachtet – die Zeichenfolge nouser per Muster *user* auswertet und dann fälschlicherweise users versteht.

Wer mit den Optionen user & Co. per UDisks experimentieren möchte, muss übrigens UDisks die Verwendung dieser Gesellen erst mal erlauben, was mir persönlich nicht klug erscheint.

Im Hinblick auf den Artikel ist meine Position:

• Keine explizite Notierung der Mount-Optionen users, users, nouser bei der Einbindung von NTFS-Dateisystemen, das betrifft sowohl fstab als auch Optionen für UDisks als auch Parameter auf der Kommandozeile.

• Bei Beachtung vorstehender Empfehlung benötigt man kein SUID-Bit bei ntfs-3g und sollte es daher auch nicht setzen.

• Einzige Ausnahme ist ein für normale Benutzer einsetzbarer Eintrag in der fstab für mount, dieser benötigt users. Auch davon ist abzuraten und ersatzweise die Verwendung von udisksctl zu empfehlen, welches diese problematische Option nicht benötigt. Wem das auch nicht möglich ist, kann sein Problem nur lösen, wenn er die Bedingungen von FUSE selber realisiert.

@kB:

Ich vermute bei Dir ein Missverständnis:

ich glaube nicht. Denn ich sehe (fast) alles genau so, wie im vor-vorherigen Post von kB dargestellt. Doch ich muss jetzt sehr aufpassen, dass ich nicht mehrere Probleme durcheinander wurschtele:

1. Gibt es den von kB früher einmal beschriebenen Bug mit der Zeichenfolge …user… noch und kann er irgendwie reproduziert werden? Wenn ja, dann muss man ihn – ganz klar – berücksichtigen.

2. kB stellt fest, dass er den Bug nicht reproduzieren kann. Also entfällt 1.

So weit, so gut. Nun bemühen sich alle, den Bug dennoch zu reproduzieren. Dabei treten die seltsamsten Beobachtungen auf, die ich nicht verifizieren kann, weil mir manches an den Tests schleierhaft bleibt.

Das von kB beschriebene Vorgehen in Post 9420544 sehe ich genau so. Es ist eben das ganz normale Vorgehen, und wenn es nicht die Geschichte mit dem rätselhaften nicht oder vielleicht auch doch verifizierbaren Bug gäbe, wäre alles klar. Nun meine Frage:

Wenn es unbedingt Weg 1 sein muss, dann (nur dann!!) muss auch auch die Anforderungen von FUSE beachten, d.h. SUID für ntfs-3g setzten und die Dateiberechtigungen für Einbindepunkt (problemlos) und Gerätedatei des Blockgerätes (sicherheitstechnisch höchst problematisch!!) erfüllen.

Muss denn unbedingt Weg 1 sein? Weil ich mir (bis jetzt) keinen Fall vorstellen kann, bei dem Weg 1 "unbedingt" sein muss (welches Anwendungsprogramm könnte dies z.B. verlangen?), habe ich vorgeschlagen, Weg 1 bei NTFS-3G einfach auszuschließen. Damit wären wir, meine ich, aus dem Schneider, für alle Arten von Anwendern. Doch vielleicht weiß jemand, wann und wofür man Weg 1 "unbedingt" braucht. Denn dann geht das natürlich nicht, und ich lasse mich dann gerne belehren. Und ich gebe dann auch Newubunti uneingeschränkt Recht.

Mit den Beobachtungen von UlfZibis komme ich nach wie vor nicht klar. kB hat einige davon erklärt, aber IMO nicht alle. Was ist denn da bloß passiert?? Und wie wollte UlfZibis denn genau vorgehen? Um einen "Test" zu verstehen, müsste man doch die Voraussetzungen und das Testziel genau kennen. Keines davon ist mir da klar. In "grauer Vorzeit", als es noch Geräte mit Drehknöpfen gab, war eine der wichtigsten Regeln: "Drehe nie gleichzeitig an mehreren Knöpfen!"

L.G.

Hallo kB, kB schrieb:

Newubunti schrieb:

[…] Regelgerecht im Sinne welcher Regeln

Die Regeln stehen in der Kernel-Dokumentation, dort insbesondere:
https://www.kernel.org/doc/html/next/filesystems/fuse.html#how-do-non-privileged-mounts-work 🇬🇧

ich kann leider nicht nachvollziehen, wie Du aus dem obigen Text, die folgenden Bedingungen für FUSE herausliest:

FUSE-Mounts erfordern immer:

• Der einbindende Prozess muss als root laufen.

• Die Quelldatei /dev/irgendetwas muss für den einbindenden Benutzer lesbar und auch beschreibbar sein, wenn er Schreiben will.

• Das Ziel-Verzeichnis muss für den einbindenden Benutzer les- und beschreibbar sein.

Wo befindet sich die markierte Bedingung bezüglich /dev/... in dem Artikel auf kernel.org und wen meinst Du hier mit "einbindende Benutzer"?

exfat-fuse erlaubt das Einhängen über die /etc/fstab in dem Moment in der Kombination noauto,user(s), wo das SUID-Bit für /usr/sbin/mount.exfat-fuse gesetzt ist. D.h. es langt die Bedingung

• Der einbindende Prozess muss als root laufen.

was IMO auch logisch ist und was ich so auch aus dem von Dir verlinkten Dokument auf kernel.org herauslese. Es kann ja nur ein Verhalten bezüglich des Einbindens "regelgerecht" sein. Entweder das von exfat-fuse oder das von ntfs-3g.

Nach meinem Verständnis verhält sich exfat-fuse hier eher "regelgerechter" als ntfs-3g. Für ntfs-3g gilt IMO das, was im Arch Wiki zu ntfs-3g steht, auch wenn das nur auf extern genutztes FUSE bei ntfs-3g abzustellen scheint:

By default, ntfs-3g requires root rights to mount the filesystem if it is a block device, even with the user option in /etc/fstab. See ntfs-3g-faq for details. The user option in the fstab is still required. Note:

...

• The full explanation is that "user" and "users" work via a setuid mount not dropping its setuid privilege so that the block device can be used without root. However, ntfs-3g has a hard-coded restriction in ntfs-3g that bails on setuid if an external libfuse is used.

• There is no good technical reason for not allowing setuid for external FUSE besides a mistrust of the library. This patch removes the said restriction.

Dabei ist mir allerdings der Unterschied zwischen dem intern kompilierten "libfuse-lite" und externen fuse noch nicht ganz klar.

Jedenfalls macht eine Bedingung

• Die Quelldatei /dev/irgendetwas muss für den einbindenden Benutzer lesbar und auch beschreibbar sein, wenn er Schreiben will.

wenn "einbindender Benutzer" der unprivilegierte Nutzer sein sollte, der das Einhängen initiiere, für mich sicherheitstechnisch überhaupt gar keinen Sinn und widerspräche insofern dem von Dir verlinkten Dokument auf kernel.org bezüglich FUSE.

LG, Newubunti

Max-Ulrich_Farber schrieb:

Ich muss passen. Ich verstehe nur noch "Bahnhof". Nach welchem Plan hast du denn getestet?

Genau diese 4 Fälle für NTFS-3G, sowohl für mount als auch für udisksctl mount:

1. Option users mit "FUSE-Bedingungen" für 1000
   ⇒ mount bindet ein mit Besitzer 1000
   ⇒ udisksctl bindet ein mit Besitzer 1000

2. Option users ohne "FUSE-Bedingungen für 1000"
   ⇒ mount bindet nicht ein
   ⇒ udisksctl bindet nicht ein

3. Option nouser mit "FUSE-Bedingungen für 1000"
   ⇒ mount bindet ein mit Besitzer 1000
   ⇒ udisksctl bindet ein mit Besitzer 0

4. Option nouser ohne "FUSE-Bedingungen" für 1000
   ⇒ mount bindet nicht ein
   ⇒ udisksctl bindet ein mit Besitzer 0

(*) nouser ist in defaults automatisch enthalten und wird bei Bedarf von users überschrieben.
(*) "FUSE-Bedingung" für 1000 bedeutet: SUID-Bit gesetzt und Lese- + Schreibrecht auf Gerätedatei und Einbindepunkt für den aufrufenden Benutzer 1000.

Fazit:

• mount interessiert sich nicht für nouser / users entgegen der Beschreibung in mount. IMHO –⇒ Bug

• udisksctl mount ändert unter users den Besitzer der Dateisystems auf 0. Dies ist nirgendwo so beschrieben und war auch unter 20.04 nicht so. IMHO –⇒ Bug

• udisksctl mount verweigert das Einbinden mit users, wenn die "FUSE-Bedingungen" für 1000 nicht erfüllt sind. Dies finde ich zumindest merkwürdig (und war unter 20.04 nicht so), denn meinem Verständnis nach bedient sich udisksctl immer dem Dienst udisksd, welcher ja unter root läuft, und deshalb dadurch die "FUSE-Bedingungen" erfüllt sein sollten.

Newubunti spricht da ganz genau eines von meinen Problemen an, die ich nicht durcheinander wurschteln will:

Es kann ja nur ein Verhalten bezüglich des Einbindens "regelgerecht" sein. Entweder das von exfat-fuse oder das von ntfs-3g.

Was ist regelgerecht, und was nicht. Das ist bei mir ein Verständnisproblem, das mich beschäftigt.

Ein anderes Problem ist, dass ich auch gerne irgendwann einmal mit NTFS-3G fertig werden und meinen armen Kopf wieder für andere Dinge frei bekommen möchte. Deshalb suche ich unabhängig davon, ob alles jetzt "regelgerecht" ist oder nicht, nach einer möglichst einfachen praktikablen Lösung. Daher meine Frage, ob dier "Weg 1" von kB wirklich "unbedingt" sein muss. Das sehe ich eben bisher noch nicht. Wenn das nicht der Fall ist, würde ich am liebsten ungeachtet aller noch ungeklärter Probleme für NTFS-3G diesen Weg einfach weglassen, ein Bier trinken und laut hörbar aufatmen.

Sollte Weg 1 aber unbedingt nötig sein, dann muss mir Newubunti helfen, dies möglichst kompakt und schmerzfrei über die Bühne zu bringen (das SUID-Bit schmerzt ja schon…). Er versteht vielleicht auch besser als ich, was UlfZibis genau will.

L.G.

Max-Ulrich_Farber schrieb:

Ein anderes Problem ist, dass ich auch gerne irgendwann einmal mit NTFS-3G fertig werden und meinen armen Kopf wieder für andere Dinge frei bekommen möchte. Deshalb suche ich unabhängig davon, ob alles jetzt "regelgerecht" ist oder nicht, nach einer möglichst einfachen praktikablen Lösung. Daher meine Frage, ob dier "Weg 1" von kB wirklich "unbedingt" sein muss.

Falls Du mit Weg 1 diesen hier meinst,

kB schrieb:

• Vorbereitete Einbindung → fstab mit Option noauto und

  1. Entweder Option user, wenn der normale Benutzer mount verwenden soll (was ich nicht empfehle, aber möglich ist und manchmal sogar notwendig sein mag, z.B. wenn die Anwendungssoftware diesen Weg voraussetzt),

dann braucht man den IMO nicht - weil praktisch ist der nicht in vertretbarer Weise nutzbar. Mann sollte aber darauf hinweisen, dass die Optionen user, users praktisch mit ntfs-3g nicht nutzbar sind, weil es eben nur bei ntfs-3g so ist, dass diese Optionen nicht nur nicht wie gewöhnlich funktionieren, sondern für die Verwendung mit udisks seit 22.04 auch noch störend wirken.

Es braucht dann für den Administrator wenigstens noch einen Link zum Vorgehen, wie er einem unprivilegierten Nutzer das Einbinden einer NTFS-Pratition ermöglicht, die von udisks zunächst als HintSystem=True eingestuft wurde. IMO könnte man das aber auch genauso gut in diesem Artikel kurz beschreiben, weil man zwar mehr oder weniger über udisks konfiguriert, aber auf udisks gekommen sind wir ja auf Grund des eigentümlichen Verhaltens von ntfs-3g.

LG, Newubunti

EDIT:

Um es mal konkret zu machen, das hier war mein Entwurf:

UUID=58CC69AFCC6987D8 /media/Bilder ntfs-3g defaults,noauto,windows_names,hide_dot_files 0 0

gio mount -d /dev/sdXY 

# ==1: mount ist nur durch den Benutzer root oder Mitgliedern der Gruppe sudo möglich
# ==0: mount ist auch für unprivilegierte Nutzer möglich
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="362F9B1C209845D1", ENV{UDISKS_SYSTEM}="0"