ubuntuusers.de

Der Artikel gio mount ist eine umgearbeitete Fortführung des früheren Artikels gvfs-mount (gültig nur bis Ubuntu 16.04) für Ubuntu 18.04 LTS und Folgende. Dabei müssen einige Aussagen geändert bzw. neu formuliert werden.

Einige Abschnitte des früheren Artikels gvfs-mount wurden in den umfassenderen Artikel Baustelle/gio übernommen. Deshalb wurden sie aus dem Artikel gio mount entfernt bzw. dort durch einen Hinweis ersetzt.

Gruß
Max-Ulrich Farber

Hallo,

ok... Review kommt dann, wenn die Baustelle zu gio fertig ist. Alleine reviewen macht nicht so viel Sinn.

Gruß, noisefloor

Hallo,

drei Anmerkungen schon mal:

Lubuntu setzt ab 18.10 auf Qt als Framework. In wie weit dann da noch GTK oder Teile davon im Hintergrund werkeln - keine Ahnung, nutze kein Lubuntu.

Teilweise ist mount noch kursiv geschrieben. Bitte alles einheitlich 'Monospace'.

Frage zum Satz:

Skripte, die das Kommando gio mount oder andere gio-Kommandos enthalten, können nicht beim Systemstart schon vor dem Einloggen des Benutzers und auch nicht in Cronjobs ausgeführt werden.

Gehen denn systemd User Units?

Gruß, noisefloor

Danke, noisefloor.

In wie weit dann da noch GTK oder Teile davon im Hintergrund werkeln - keine Ahnung, nutze kein Lubuntu.

Ich auch nicht. Weiß ich leider auch nicht. Wenn mich da niemand informieren klann, dann nehme ich einfach Lubuntu raus.

Teilweise ist mount noch kursiv geschrieben. Bitte alles einheitlich 'Monospace'.

Die Formatierung ist ja noch nicht fertig. Weil aber der Artikel inhaltlich fast steht, kann ich mich wohl heute oder morgen noch daran machen. Dann wäre dieser Artikel 'mal fertig.

Gehen denn systemd User Units?

Das weiß ich leider nicht. Mit systemd habe ich noch so meine Probleme ☹ Ich denke aber, sie müssten eigentlich gehen. Warum Cronjobs nicht gehen, habe ich auch nicht ganz verstanden. Aber es ist so, sowohl persönlich als auch in /etc/crontab. Könntest Du das mit den systemd User Units vielleicht 'mal testen, mit irgend einem gio-Kommando?

Gruß – Max-Ulrich

EDIT:

Lubuntu muss raus, denn da kann man nichts mehr aussagen, was für 18.04 und 20.04 gemeinsam gilt:

Note, due to the extensive changes required for the shift in desktop environments, the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh install.

Habe das jetzt mal gemacht. Dann mache ich mich jetzt wieder an den Artikel Baustelle/gio, dass diese beiden Artikel fertig werden. Das Problem mit veralteten Bildern besteht da ja nicht. Dann wären wenigstens zwei der Baustellen wieder weg.

Es ist schlimm. Bei jedem Link stoße ich unerwartet wieder auf Aussagen, die so einfach nicht mehr stimmen. Das gilt so gut wie für alles, was mit Heimnetzwerk und Samba zu tun hat. An diesen Artikeln ist einfach zu lange nichts mehr gemacht worden. Ich wollte mich ja eigentlich ganz zurückziehen, doch jetzt stecke ich wider Willen wieder voll drin… Hoffentlich können wir die "Kampagne" dann bald beenden.

Beste Grüße
Max-Ulrich

Ein erster Entwurf für den Artikel ist nun fertig. Ich bitte darum, nun diesen Artikel Baustelle/gio mount und auch den Artikel Baustelle/gio kritisch durchzusehen.

Gruß – Max-Ulrich

Hallo,

habe ein paar Minikorrekturen gemacht, ansonsten IMHO ok.

Bitte in Zukunft _nie_ manuelle Zeilenumbrüche im Fließtext im Wiki verwenden, das ist maximal in Tabellenzellen erlaubt.

Gruß, noisefloor

Hallo,

keine weiteren Rückmeldungen, Artikel ist im Wiki. Danke für's Erstellen ☺

Gruß, noisefloor

Danke auch.

Ich mache dann gleich die entsprechenden Links in den verwandten Artikeln.

Gruß – Max-Ulrich

Hallo,

in ein paar Artikeln habe ich gio schon verlinkt. Kannst gerne aber wo sinnvoll weitere Links hinzufügen.

Gruß, noisefloor

Der Abschnitt gio mount (Abschnitt „Einbinden-lokaler-Dateisysteme“) bedarf wohl einer Überarbeitung. Dort sollte auch das Zusammenspiel mit udiks2 bzw. udisksctl -b /dev/… thematisiert werden.

Dazu verweise ich auf eine umfangreiche Diskussion in de Diskussion des Artikels NTFS-3G, die aber eher hierher gehört. Newubunti schreibt dort:

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 denke, wir sollten die Diskussion hier fortführen.

Natürlich war das oben erwähnte Zitat ein Fehler von mir. Es muss vielmehr heißen:

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

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

das entspricht meiner Beobachtung, allerdings in umgekehrter Priorität: Wenn ein fstab-Eintrag vorhanden ist, dann mount is spawned, andernfalls: then udisks_filesystem_call_mount is used. Das spiele ich jetzt nochmal durch, und zwar mit beidem, gio mount -d und disksctl mount -b, und berichte dann hier darüber.

Hallo,

ich habe hier eine recht gute Erklärung zum Verhältnis udisks2 und gvfs gefunden:

https://unix.stackexchange.com/questions/746279/how-does-automount-work-in-modern-linux-distributions-like-ubuntu/746282#746282

Was dort beschrieben ist, deckt sich soweit auch mit meinen Beobachtungen unter Ubuntu 20.04-23.10, so dass mir das eine ziemlich zutreffende Erklärung und zudem auch IMO recht verständlich zu sein scheint.

LG, Newubunti

Max-Ulrich_Farber schrieb:

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.

Das geht über die /etc/udisks2/mount_options.conf. Mache mal folgendes:

sudo cp /etc/udisks2/mount_options.conf.example /etc/udisks2/mount_options.conf 

Dann mit

sudoedit /etc/udisks2/mount_options.conf 

öffnen und bei folgenden Zeilen das # entfernen:

...
### For the reference, these are the builtin mount options:
[defaults]
...
# # ntfs3, ntfs-3g and the legacy ntfs kernel driver options
ntfs_defaults=uid=$UID,gid=$GID,windows_names
ntfs_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case,windows_names,compression,nocompression,big_writes,nls,nohidden,sys_immutable,sparse,showmeta,prealloc

Die Zeile ntfs_defaults=... gibt die Standards für NTFS an. Dort müsstest Du also z.B. permissions setzen. Aber Du musst das auch bei ntfs_allow= eintragen, weil Du bei den Defaults nur das verwenden kannst, was unter *allow auch erlaubt wurde.

Die Datei ist ja eigentlich recht selbsterklärend und zeigt nebenbei eben auch die bei udisks2 einprogrammierten Standards. Die Datei gibt es wohl erst ab udisks2-Version 2.9.0. In Ubuntu damit ab 22.04.

Es kann so weit ich gelesen habe vorkommen, dass udisks2 über die mount_options.conf Parameter nicht akzeptiert, auch wenn vom Treiber eigentlich unterstützt. Das habe ich bis jetzt aber weder veri- noch falsifiziert.

LG, Newubunti

Es ist für mich sehr interessant, dass sich da in den letzten Ubuntu-Versionen "im Hintergrund" doch einiges getan hat, was ich nicht wusste. Vor allem betrifft dies den Themenkreis udisks2 bzw. damit auch udisksctl. Dafür wäre nun eigentlich ein eigener Wiki-Artikel angebracht (bzw. nötig)!

Meine Beobachtungen möchte ich nun so zusammenfassen: gio mount -d /dev/… ruft offenbar udiscsctl mount -b /dev/… auf. Alle im Zusammenhang mit der Option -d relevanten Vorgaben bzw. Einstellungen für gio mount werden mittels udisks2 festgelegt (Entsprechend verfährt KDE bei Mounten mittels Dolphin. Doch davon verstehe ich nichts).

Ohne die Option -d hat gio mount aber mit udisks2 bzw. udisksctl nichts zu tun.

Stimmt das alles so?

Wenn es so ist, dann gehört der ganze Abschnitt gio mount (Abschnitt „Einbinden-lokaler-Dateisysteme“) eigentlich in den (leider noch nicht existierenden) Artikel udisks2, und dieser wäre dann entsprechend zu verlinken. gio mount -d /dev/… war ja immer schon ein "Fremdkörper" bei gio mount, weil da alles andere wie vor allem das Zusammenspiel mit FUSE nicht zutraf.

EDIT:

Es kann so weit ich gelesen habe vorkommen, dass udisks2 über die mount_options.conf Parameter nicht akzeptiert, auch wenn vom Treiber eigentlich unterstützt. Das habe ich bis jetzt aber weder veri- noch falsifiziert.

Könnte es sein, dass da ganz einfach der Eintrag in xyz_allow=… fehlte?

Hallo,

es gibt dazu schon was im Wiki: DeviceKit. Den Artikel habe ich damals beim Schreiben ziemlich kurz gehalten, weil zumindest per Stand damals man als "normaler" Anwender sehr selten direkt damit interagieren muss.

Gruß, noisefloor