staging.inyokaproject.org

Ich finde, wir sollten auch nicht übers Ziel hinausschießen. Die Richtung soll stimmen, doch Kompromisse sind immer nötig. In diesem Fall gilt das vor allem, solange es im Wiki noch kein Artikel zu udisks2 und udisksctl gibt.

Mann sollte sich darauf verständigen, ob in diesem Artikel nun etwas zum Einhängen von NTFS-Partition stehen soll oder ob man das dann in dem übergeordneten Artikel "Windows Partitionen einbinden" verortet. IMO wird es wohl am Ende eher dort landen,

ich denke auch, dort gehört es hin.

ich hatte meinen Vorschlag hier halt überhaupt erst mal dagelassen, damit die Infos nicht verloren gehen. Denn da steckt schon einiges an Tests und Recherche dahinter.

+1 👍

Kann man so machen, wichtig wäre IMO aber, dass am Ende irgendwo im Wiki zusammenhängend steht, wie der Nutzer unter *buntu eine NTFS-Partition "mittels" ntfs-3g einhängt.

+1. Doch sollte man dabei den Artikel wo möglich durch Links zu allgemeineren, übergeordneten Artikeln entlasten.

die als HintSystem vom System eingestuft wurde, was standardmäßig immer für Partitionen gilt, die an "internen" Schnittstellen (z.B. SATA) hängen

Das wusste ich nicht. Es ist zweifellos interessant, aber IMO allenfalls für "Experten" von Bedeutung, wenn wir uns an folgendes Standard-Vorgehen halten:

• Systemweit eingebunden wird mit mount und fstab. Dafür sind Root-Rechte nötig. Das Arbeiten mit dem SUID-Bit ist kein Standard, sondern ein "Schleichweg" mit Sicherheitsrisiko. Statt dessen gibt es in Desktop-Systemen andere Wege:

• Für's Einbinden als User ohne Root-Rechte gibt es (in Desktop-Systemen) als Standard und ohne SUID-Bit gio mount und udisksctrl. Die GUI und die Dateimanager verwenden gio mount.

• Eine Besonderheit ist allenfalls das mittels fstab-Eintrag vorbereitete Einbinden ohne Root-Rechte mittels user bzw. users und noauto. Doch ob man dieses hier überhaupt noch als Standard ansehen sollte, weiß ich nicht. Denn – soweit ich sehe – kann man das gleiche immer auch mit einer udev-Regel oder udisksctrl ohne SUID-Bit bewerkstelligen (??).

• Experten können es, wenn sie wollen, auch anders machen. Das ist dann ihre Sache. In Linux gibt es (fast) immer verschiedene Wege.

An dem Begriff "unprivilegiert" hänge ich nicht, mir ist erst mal kein besserer eingefallen.

Ist doch ok. "unterprivilegiert" sollte nur ein scherzhaftes Wortspiel sein.

"GUI" ist IMO allgemeiner, wie "gio"

das stimmt natürlich, das gio ist Bestandteil der GUI, auch wenn man den Befehl gio mount im Terminal verwendet. In der Konsole geht er nicht. Nur denkt der User bei GUI eben an DM und Mausklick, und in Kommandozeile und Terminal sieht er das Gegenteil zur GUI. Und das stimmt so eben nicht.

udisks2 ist bei Debian-basierten Systemen der Unterbau der grafischen Datenträger-Verwaltung und damit der kleinste gemeinsame Nenner des Einhängens über welche Desktop-Umgebung auch immer. Da aber im Wiki (noch) nicht behandelt, dementsprechend für "das Wiki unbekannt".

Da bin ich mir eben auch selbst nicht recht über die "Hierarchie" der Befehle im klaren. Ist "udisksctrl mount" dem Befehl "gio mount" übergeordnet und wird von diesem verwendet, oder handelt es sich um zwei "gleichrangige" Verfahren nebeneinander? Wenn du mir da etwas Klarheit verschaffen kannst, bin ich dankbar. Nach obiger Aussage müsste ja das erste der Fall sein.

Zwischen exFAT und NTFS gibt es in dieser Hinsicht einen grundsätzlichen Unterschied:

• das neue exFAT Kernelmodel von Samsung (nicht das alte von Paragon) ist anscheinend sehr stabil und auch weitgehend mit dem FUSE-Treiber kompatibel. Es gibt ein paar Unterschiede, aber im Vergleich zu NTFS sind die marginal.

• die Optionen beim Kernel-Treiber sind umfassender als beim FUSE-Treiber.

• Es gibt auch eine auf den Kerneltreiber abgestimmte Sammling exfatprogs von Werkzeugprogrammen

• Es gibt demnach kaum Gründe, den FUSE-Treiber zu verlangen.

• Bei NTFS ist es gerade umgekehrt: NTFS-3G ist offenbar stabiler als ntfs3

• NTFS-3g bietet ein viel größeres Spektrum an Optionen

• nur NTFS-3G bietet User-Mapping für Dual-Boot Mehrbenutzer-Systeme

• nur NTFS-3G bietet (bislang) eine (integrierte) Sammlung von Werkzeugprogrammen.

• Es gibt demnach mehrere Gründe, NTFS-3G zu verlangen.

Man kann die zwei Dateisysteme exFAT und NTFS also in dieser Hinsicht nicht gleich behandeln.

Max-Ulrich_Farber schrieb:

udisks2 ist bei Debian-basierten Systemen der Unterbau der grafischen Datenträger-Verwaltung und damit der kleinste gemeinsame Nenner des Einhängens über welche Desktop-Umgebung auch immer. Da aber im Wiki (noch) nicht behandelt, dementsprechend für "das Wiki unbekannt".

Da bin ich mir eben auch selbst nicht recht über die "Hierarchie" der Befehle im klaren. Ist "udisksctrl mount" dem Befehl "gio mount" übergeordnet und wird von diesem verwendet, oder handelt es sich um zwei "gleichrangige" Verfahren nebeneinander? Wenn du mir da etwas Klarheit verschaffen kannst, bin ich dankbar. Nach obiger Aussage müsste ja das erste der Fall sein.

Ich fühle mich zwar maximal eher als der Einäugige unter den Blinden - denn udisks2 ist bis zu der Diskussion hier an mir unbemerkt vorbeigezogen - aber ich verstehe das so:

• udisks2 ist der Unterbau, der sich um die Verwaltung von Geräten - wozu auch das Einhängen gehört - kümmert

• gvfs ist dann IMO eher auf der Ebene der Dateisysteme angesiedelt

Schaut man sich mit apt depends die Abhängigkeiten von gvfs und udisks2 an, dann ist dementsprechend auch gvfs von udisks2 abhängig, udisks2 aber nicht von gvfs.

Und auch bei den beiden grafischen Programmen Laufwerke und Nautilus spiegelt sich das Prinzip wieder:

• Laufwerke (gnome-disk-utility) ist direkt von udisks2 abhängig, aber nicht von gvfs. Allerdings kann man mit dem Programm Laufwerke nicht auf Dateien und Ordner zugreifen.

• Nautilus ist direkt erst mal nur von gvfs abhängig, damit aber indirekt in zweiter Linie auch von udisks2. Mit Nautilus kann man als Endverbraucher mit der durch Laufwerke einhängbaren Partition dann erst tatsächlich etwas anfangen.

Hilft Dir das weiter?

LG, Newubunti

Hilft Dir das weiter?

Ja, auf jeden Fall! Das GVfs hat ja mehrere Teile, die AFAIK weitgehend voneinander unabhängig sind:

• der Zugriff auf entfernte Geräte und "Orte" usw., die nicht POSIX-konforme Bezeichnungen erhalten wie z.B. smb://…'' oder ftp://'' usw. Diese erhalten dann über FUSE einen Mountpunkt mit POSIX-Syntax in /run/user/<UID>/gvfs/

• das Einhängen von "systemnahen" Geräten (Partitionen) ohne Root-Rechte mit einem Mountpunkt in /media/<USER>/…

Etwas ins Unreine gesprochen führt das GVfs zwei ganz verschiedene Vorgänge in DM- und GUI-gerechter Form zusammen.

Vielleicht greift das GVfs (oder besser gesagt gio mount) bei dem zweiten Teil auf udisks2 bzw. udisksctrl zurück? – Mir war udisks2 auch vor dieser Diskussion noch ganz unbekannt. Aber es scheint mir jetzt doch recht wichtig zu sein.

Der Artikel gio mount, an dem ich damals auch maßgeblich beteiligt war, beschäftigt sich ausschließlich mit dem ersten Teil. Von udisks2 ist dort noch überhaupt nicht die Rede. Der Artikel gehört deshalb dringend aktualisiert! Gleiches gilt auch für den Artikel gio

off topic:

Eigentlich wollte ich mich ja schon länger aus Altersgründen aus der Wiki-Arbeit ganz zurückziehen. Doch es tut einfach weh, zu sehen wie Artikel, an denen man einst intensiv gearbeitet hatte, ohne Aktualisierungen langsam veralten und unbrauchbar werden.

EDIT

eben probiert: udisksctl mount -b /dev/mmcblk0p1 macht genau das gleiche wie gio mount -d /dev/mmcblk0p1

Erst mal noch konkreter zu diesem Artikel: ☺

Wenn ich es richtig überblicke, dann sind wir mehr oder weniger der gleichen Meinung, ich stimme Dir im Prinzip auch bei dieser Aussage zu:

Die Gliederung nach "GIO mit Nautilus und Mausklick" einerseits und "Terminal bzw Kommandozeile andererseits" finde ich nicht glücklich. Besser fände ich eine Gliederung nach dem jeweils verwendeten mount-Programm: mount, gio mount und udisksctl. Alle können per Kommandozeile oder von irgendeinem Programm aus aufgerufen werden, und die graphischen Werkzeuge verwenden in GTK-Flavours eben das GVfs mit gio mount.

Allerdings stelle ich mir gerade die Frage, wie ich das dann sonst benenne ohne dabei technisch weniger bewanderte Leser/Anwender zu überfordern. Von daher fand ich die Unterscheidung in

• in der GUI geht es unter diesen und jenen Voraussetzungen

• im Terminal funktioniert es so ...

wiederum - zwar technisch unter der Haube sehr unpräzise - aber aus Anwendersicht vom Ansatz her irgendwie zweckmäßig.

Ansonsten:

Max-Ulrich_Farber schrieb:

... Etwas ins Unreine gesprochen führt das GVfs zwei ganz verschiedene Vorgänge in DM- und GUI-gerechter Form zusammen.

Vielleicht greift das GVfs (oder besser gesagt gio mount) bei dem zweiten Teil auf udisks2 bzw. udisksctrl zurück? ...

So in etwa nehme ich das bis jetzt auch wahr.

eben probiert: udisksctl -u /dev/mmcblkop1 macht genau das gleiche wie gio mount -d /dev/mmcblk0p1

Ich nehme mal an, Du meintest hier udisksctl -b /dev/mmcblkop1?

"Genau das gleiche" schien mir auf den ersten Blick auch erst mal so. Aber udisksctl funktioniert ganz ohne grafische Sitzung, gio mount aber nicht. Womit wir IMO schon wieder sehr dicht an Deiner Erklärung von oben sind:

Vielleicht greift das GVfs (oder besser gesagt gio mount) bei dem zweiten Teil auf udisks2 bzw. udisksctrl zurück?

Wobei gvfs/gio etwas machen, was udisks2 alleine wahrscheinlich nicht macht(?): Das Bereitstellen in einer grafischen Sitzung. Auf der anderen Seite greift gio mount wahrscheinlich auf Fähigkeiten bzw. Infrastruktur von udisks2 zurück. Z.B. scheint mir das bei den Zugriffsberechtigungen für das Einhängen an sich, für die udisks2 Polkit verwendet, der Fall zu sein.

Das wird sichtbar, wenn man von einem unprivilegierten Nutzer einen Mountversuch mit gio mount versucht und dann aber bei der Passwortabfrage des Systemverwalter-Passwortes abbricht. Man findet dann in den Logs mittels

sudo journalctl -b0 --no-pager 

Feb 26 21:46:53 jammyvm01 polkitd(authority=local)[513]: Operator of unix-session:20 FAILED to authenticate to gain authorization for action org.freedesktop.udisks2.filesystem-mount-system for system-bus-name::1.260 [/usr/libexec/gvfs-udisks2-volume-monitor] (owned by unix-user:test01)

Was gvfs-udisks2-volume-monitor genau macht und wann gio mount darauf zurückgreift, überblicke ich aber bei weitem noch nicht vollständig.

Bei udisks2 steht ja auch in der man-Page:

AUDIENCE

The intended audience of udisks include operating system developers working on the higher-level parts of the operating system, for example the desktop shell (such as GNOME^[5]) and disk management applications (e.g. GNOME's Disks^[6] application).

Aber wenn wir ehrlich sind Max-Ulrich_Farber müssten wir diese Fragen eher bei gio mount diskutieren, oder?

OT:

Eigentlich wollte ich mich ja schon länger aus Altersgründen aus der Wiki-Arbeit ganz zurückziehen. Doch es tut einfach weh, zu sehen wie Artikel, an denen man einst intensiv gearbeitet hatte, ohne Aktualisierungen langsam veralten und unbrauchbar werden.

Es ist (leider) aus meiner Erfahrung so, dass es bei einem Wiki beim Überarbeiten eines Artikels nur in wenigen Ausnahmefällen bei genau dieser einen Überarbeitung bleibt, sondern man sich ganz schnell im Dunstkreis von ganz schnell bis zu 10 Artikeln oder auch mehr bewegt.

Davon abgesehen finde ich, dass Du hier über die Jahre ganz hervorragende Arbeit geleistet hast! Dass Dein Herz damit mehr oder weniger an diesen Artikeln hängt, kann ich gut verstehen, trotzdem musst Du Dich damit nicht für ewig für diese Artikel verantwortlich fühlen - (wenn es Dir natürlich weiter Freude bereitet, kannst Du es natürlich weiterhin tun).

LG, Newubunti

EDIT:

Das habe ich gerade noch gefunden:

https://gitlab.gnome.org/GNOME/glib/-/issues/2195#note_901896

... If the drive is detected by udisks and gvfs is used, then udisks_filesystem_call_mount is used, otherwise mount is spawned. ...

Ich nehme mal an, Du meintest hier udisksctl -b /dev/mmcblkop1?

Natürlich! Sorry, habe ich schon korrigiert.

Ich will jetzt kein "großes Fass aufmachen" und an allen Stellen gleichzeitig herumkorrigieren. Trotzdem: Wir sollten diese Diskussion in einen anderen Thread verlagern. Da es (bislang) keinen Artikel zu udisks2 bzw. udisksctl gibt, vielleicht in die Diskussion des Artikels gio mount. Ich habe den Artikel nochmal genau gelesen, und so viel ist davon gar nicht überholt (Selbstlob ☺ ); was es zu aktualisieren gäbe, ist wohl im Moment der erste Abschnitt, betreffend gio mount -d /dev/…

Dann könnte man sich hier wieder auf das eigentliche Thema konzentrieren!

Dein Einverständnis voraussetzend zitiere ich deinen letzten Beitrag in der Diskussion von gio mount, und wir führen die allgemeine Diskussion zu udisks2 bzw. udisksctl dort weiter.

zurück zum Thema:

Ich muss nochmal testen, wie sich gio mount -d bzw. udisksctl mount -b verhält, was nach meinen bisherigen Beobachtungen auf das gleiche herauskommt, wenn das Mounten in fstab vorbereitet ist oder eben nicht. Das wird für die Gliederung des Artikels NTFS-3G nicht ganz unwesentlich sein. Eventuell kann man damit dann den ganzen Kram mit SUID-Bit und users usw. ganz weglassen. bzw. in einen "Einzeiler" für Experten verbannen. Mit udev-Regeln kenne ich mich nicht so gut aus, wenn du da helfen könntest, wäre ich dankbar.

Max-Ulrich_Farber schrieb:

zurück zum Thema:

Ich muss nochmal testen, wie sich gio mount -d bzw. udisksctl mount -b verhält, was nach meinen bisherigen Beobachtungen auf das gleiche herauskommt,

Also im Ergebnis kommt bei beiden, wenn man das in einer grafischen Sitzung nutzt, das gleiche heraus, weil gio mount auf den udisks2 Mount-Systemcall zurückgreift.

Unter der Haube mag es etwas komplexer sein, was aber für diesen Artikel IMO keine Rolle spielt.

wenn das Mounten in fstab vorbereitet ist oder eben nicht. Das wird für die Gliederung des Artikels NTFS-3G nicht ganz unwesentlich sein. Eventuell kann man damit dann den ganzen Kram mit SUID-Bit und users usw. ganz weglassen.

Man kann und sollte auch das mit dem SUID-Bit weglassen, weil man es nicht (mehr) braucht. Bei users bin ich mir über das ganze Zusammenspiel von gio mount, udisks2 und fuse noch nicht sicher, wie das genau abläuft.

Im Ergebnis kann man aber auch das users weglassen.

Ich werde mir jetzt mal noch Kubuntu ziehen, um zu testen, ob udisksctl mount dort auch funktioniert.

Falls ja, dann ist doch meine Überarbeitung im Endeffekt, gar nicht so verkehrt, oder? Die technische Unschärfe meiner Überarbeitung, müsste man dann in den jeweils spezifischeren Artikeln ausräumen.

LG, Newubunti

Alles sieht doch IMO recht gut und in der Anwendung sehr einfach aus:

• wenn ein fstab-Eintrag mit noauto da ist (also "vorbereitetes Einbinden…"), mit oder ohne users, dann wird der Eintrag mittels gio mount -d /dev/… oder auch mittels disksctl mount -b /dev/… ohne Root-Rechte und ohne Passwort-Abfrage ausgeführt, ungeachtet ob der Benutzer "privilegiert" ist oder nicht. Gleiches gilt auch für Mausklick im DM.

• Auch Aushängen geht ohne Root-Rechte, allerdings nicht im DM (Thunar), weil der DM den Mountpunkt nicht findet.

• Ohne fstab-Eintrag wird eben der Standard-Mountpunkt in /media/<user>/angelegt (Label oder UUID der Partition) und mit Standard-Optionen gemountet. Dafür kann man dann mit dem DM wieder aushängen, weil der den Mountpunkt an der richtigen Stelle sucht

Mehr braucht man eigentlich nicht: Mit Root-Rechten mount, ohne Root-Rechte gio mount und fertig. Kein SUID-Bit, kein users und wohl auch kein allow other in fuse.conf (?).

Getestet habe ich das bisher nur für NTFS-3G, aber ich denke, das wird für ntfs3 wohl genau so sein.

Es fragt sich, ob wir da überhaupt die udev-Regel bzw. das Blacklisting von ntfs3 brauchen. In fstab einen Eintrag mit noauto und ntfs-3g anlegen und fertig. Das Blacklisting könnte dann einen "Einzeiler" für Experten geben, aber "Experten" sollten eigentlich allein auf diese Idee kommen.

Dann hätten wir ja erreicht, was ich wollte: Den Artikel schlanker gemacht.

Die Grundsatzdiskussion zu gio mount bzw diskctl2 führen wir dann dort weiter. Es würde mich interessieren, ob und ggf. wie man die Standard-mount-Optionen für gio mount (z.B. Ordner für Mountpunkt oder z.B. generell permissions) festlegen kann. fstab-Eintrag bzw. udev-Regel betreffen ja immer eine einzelne Partition.

Könntest du bitte trotzdem noch prüfen, ob das so immer geht, damit es ja kein "Haar in der Suppe" gibt (z.B. HINT-System).

Die verwendete Partition /dev/mmcblk0p1 ist eine NTFS-SD-Karte im Cardreader des Laptop, nicht über USB eingebunden (lsusb zeigt den Reader nicht, wohl aber lspci). Eine wirklich "interne" NTFS-Partition habe ich zurzeit nicht.

Max-Ulrich_Farber schrieb:

Alles sieht doch IMO recht gut und in der Anwendung sehr einfach aus:

• wenn ein fstab-Eintrag mit noauto da ist (also "vorbereitetes Einbinden…"), mit oder ohne users, dann wird der Eintrag mittels gio mount -d /dev/… oder auch mittels disksctl mount -b /dev/… ohne Root-Rechte und ohne Passwort-Abfrage ausgeführt,

Meiner Erfahrung nach funktioniert es mit users eben nicht. Deshalb finde ich, dass es in den Artikel gehört, dass sich ntfs-3g an users stört.

ungeachtet ob der Benutzer "privilegiert" ist oder nicht. Gleiches gilt auch für Mausklick im DM.

Laut Newubunti ist das nicht egal, wenn ich ihn richtig verstanden habe.

Es fragt sich, ob wir da überhaupt die udev-Regel bzw. das Blacklisting von ntfs3 brauchen. In fstab einen Eintrag mit noauto und ntfs-3g anlegen und fertig. Das Blacklisting könnte dann einen "Einzeiler" für Experten geben, aber "Experten" sollten eigentlich allein auf diese Idee kommen.

Ja ich denke auch, dass wir uns das sparen können.

Meiner Erfahrung nach funktioniert es mit users eben nicht. Deshalb finde ich, dass es in den Artikel gehört, dass sich ntfs-3g an users stört.

Ja, das ist offenbar so. Ich hatte zuerst gedacht, es betreffe nur mount mit SUID-Bit. Man muss also vor dieser (absolut unnötigen) Option warnen.

Laut Newubunti ist das nicht egal, wenn ich ihn richtig verstanden habe.

Ich muss nochmal genau nachlesen, unter welchen Umständen das nicht egal ist. In dem von mir beschriebenen Fall hat es jedenfalls keine Rolle gespielt.

Ja ich denke auch, dass wir uns das sparen können.

Zumindest die udev-Regel. Wenn man generell nur NTFS-3G zulassen will, dann ist wohl Blacklisting die einzige Möglichkeit (?).

Schon ein mal schnell vorweg:

@Max-Ulrich_Farber:

Bitte führe bei der Betrachtung Deines NTFS-Laufwerkes bzw. Deiner NTFS-Partition doch bitte ein mal den Befehl:

udisksctl info -b /dev/sdXY | grep -E 'HintSystem'  

aus.

Meine Aussagen, bezüglich Unterscheidung "unprivilegierter Nutzer" betrifft in aller Regel nur "interne" Partitionen, weil die eben vom System standardmäßig mit "HintSystem = True" klassifiziert werden. Solche Partitionen können nur mit Root-Rechten eingebunden werden.

"Wechseldatenträger" - insbesondere an USB angeschlossene - werden bei mir dagegen als "HinteSystem = False" eingebunden. Diese können grundsätzlich auch von "unprivilegierten" Nutzern eingebunden werden.

Bei Ubuntu kommt - was die Analyse der besagten Unterschiede anbelangt - "erschwerend" hinzu, dass Mitglieder der Gruppe sudo bei Verwendung der GUI für einige Aktionen, die Root-Rechte erfordern - wie das Einhängen einer "HintSystem = True"-Partition - kein Passwort eingeben müssen. Da scheint es entsprechende polkit-Regeln zu geben.

Deswegen fällte einem der Unterschied nur auf, wenn man tatsächlich einen Nutzer verwendet, der nicht Mitglied von sudo ist.

Daher einfach einen Nutzer mittels

sudo adduser test01 

anlegen, neu starten und dann mit diesem Konto anmelden und den Unterschied wahrnehmen.

LG, Newubunti

EDIT:

Max-Ulrich_Farber schrieb:

Es fragt sich, ob wir da überhaupt die udev-Regel bzw. das Blacklisting von ntfs3 brauchen. In fstab einen Eintrag mit noauto und ntfs-3g anlegen und fertig. Das Blacklisting könnte dann einen "Einzeiler" für Experten geben, aber "Experten" sollten eigentlich allein auf diese Idee kommen.

Naja, nicht vergessen: Man kann auch einfach nur grafisch ohne fstab-Eintrag einhängen wollen. Und wenn man das nicht häufig macht, dann vergisst man das mit dem Eintrag in der /etc/fstab vielleicht. Mounted man dann eine neue Partition, dann verwendet man unter Umständen mit ntfs3.

udev-Regel und/oder Blacklist-Eintrag stellen sicher, dass man immer mit ntfs-3g einhängt, ohne dass der Benutzer noch mal tätig werden muss. Das muss wie schon weiter oben erwähnt nicht unbedingt gänzlich hier stehen, aber sollte IMO entsprechend wenigstens verlinkt sein - wobei ich das hier auch nicht so sehr fehl am Platze finde.

Newubunti schrieb:

Ich werde mir jetzt mal noch Kubuntu ziehen, um zu testen, ob udisksctl mount dort auch funktioniert.

Erwartungsgemäß funktioniert gio mount -b ... unter Kubuntu 22.04.4 nicht. Der Befehl gio steht grundsätzlich zur Verfügung, aber es mangelt am Paket gvfs.

udisksctl mount -d ... funktioniert aber anstandslos.

LG, Newubunti

EDIT:

Newubunti schrieb:

... Bei Ubuntu kommt - was die Analyse der besagten Unterschiede anbelangt - "erschwerend" hinzu, dass Mitglieder der Gruppe sudo bei Verwendung der GUI für einige Aktionen, die Root-Rechte erfordern - wie das Einhängen einer "HintSystem = True"-Partition - kein Passwort eingeben müssen. Da scheint es entsprechende polkit-Regeln zu geben. ...

Geregelt wird das in der /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla:

[Mounting, checking, etc. of internal drives]
Identity=unix-group:admin;unix-group:sudo
Action=org.freedesktop.udisks.filesystem-*;org.freedesktop.udisks.drive-ata-smart*;org.freedesktop.udisks2.filesystem-mount-system;org.freedesktop.udisks2.encrypted-unlock-system;org.freedesktop.udisks2.filesystem-fstab;
ResultActive=yes
...

Für einen deutschsprachigen Schnelleinstieg in polkit-pkla-Regeln empfehle ich:

https://edv.mueggelland.de/das-linux-policykit-verstehen/ 🇩🇪

LG, Newubunti

weil die eben vom System standardmäßig mit "HintSystem = True" klassifiziert werden.

und so war es bei mir eben nicht. Auch bei "echt internen" Partitionen war es = False.

Bitte führe bei der Betrachtung Deines NTFS-Laufwerkes bzw. Deiner NTFS-Partition doch bitte ein mal den Befehl: udisksctl info -b /dev/sdXY | grep -E 'HintSystem' aus.

Genau das habe ich ja gemacht – mit Ergebnis "False"

Für einen deutschsprachigen Schnelleinstieg in polkit-pkla-Regeln empfehle ich:

werde ich 'mal tun, aber heute nicht mehr.

Max-Ulrich_Farber schrieb:

weil die eben vom System standardmäßig mit "HintSystem = True" klassifiziert werden.

und so war es bei mir eben nicht. Auch bei "echt internen" Partitionen war es = False.

Bitte führe bei der Betrachtung Deines NTFS-Laufwerkes bzw. Deiner NTFS-Partition doch bitte ein mal den Befehl: udisksctl info -b /dev/sdXY | grep -E 'HintSystem' aus.

Genau das habe ich ja gemacht – mit Ergebnis "False"

Aber das widerspricht ja im Prinzip nicht meiner Beobachtung, dass bei HintSystem = True das Einhängen für unprivilegierte Nutzer erschwert ist bzw. dann nur Root mounten kann.

Es belegt "nur", dass die Aussage, dass "interne" Partitionen als HintSystem = True eingestuft werden, so nicht zu stimmen scheint.

Wenn bei Dir alles auf HintSystem = False steht, dann erklärt das damit eben auch, warum Du den Unterschied sudo-Mitlgied vs. unprivilegierter Nutzer bei Deinem System erst mal nicht nachvollziehen kannst.

Du könntest einfach per udev-Regel Deine NTFS-Partition auf HintSystem = True setzen und dann gehe ich davon aus, dass Du den Unterschied bei Dir nachvollziehen kannst. Musst Du nicht machen, weil ich mir recht sicher bin, dass das so ist, aber die udev-Regel dazu wäre:

Neue Datei /etc/udev/rules.d/99-udisks2-set-to-system-partition.rules anlegen, mit Inhalt:

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

362F9B1C209845D1 ist dabei durch die zuvor bei IdUUID ausgegebene UUID der betreffenden NTFS-Partition zu ersetzen.

LG, Newubunti