Daemonen¶

Die für das Funktionieren des GVFS und damit für die gio-Kommandos nötigen Daemonen befinden sich im Verzeichnis /usr/lib/gvfs. Hauptdaemonen sind unabhängig von den jeweiligen Orten immer aktiv. Neben dem Grund-Daemon gvfsd, der beim Systemstart gestartet wird und über den alle übrigen Daemonen gestartet und angesprochen werden, sind dies die Daemonen gvfsd-fuse und gvfsd-metadata. Diese verwalten den alternativen Mountpunkt für POSIX-Anwendungen und das Serialisieren und Zwischenspeichern von Metadaten zur Sicherung von deren Persistenz. Sie sind für das Funktionieren der gio-Kommandos nicht unbedingt erforderlich (s.u.).

Wie man an den Namen der anderen Daemonen erkennt, sind diese für das Ansprechen spezieller Orte nötig. So können z.B. Server in SMB-Netzwerken ("Windows-Netzwerken") nur angesprochen werden, wenn der Daemon gvfsd-smb aktiv ist, und browsen kann man in ihnen nur mittels gvfsd-smb-browse.

Lokale Dateisysteme¶

Auf alle Dateisysteme, für die ein Eintrag in der Systemdatei /dev besteht ("devices"), kann über das GVfs zugegriffen werden. Sofern diese nicht bereits über einen systemd-Service, einen Eitrag in fstab über den Standard-Befehl mount ins Dateisystem eingebunden sind, muss dies zuerst ohne Root-Rechte mittels

gio mount -d DEVICE 

geschehen. Siehe hierzu auch gio mount.

Netzwerk-Dienste¶

Vom Netzwerk-Dienst NFS unterstützt das GVfs lediglich die (veralteten) Versionen NFSv2 und NFSv3. Das dafür notwendige Backend ist in Ubuntu standardmäßig nicht verfügbar.

Die Unterstützung von Samba wurde zwar für das inzwischen veraltete Protokoll SMBv1 (cifs, NT1) konzipiert, funktioniert aber weitgehend auch mit den modernen Protokollen SMBv2 und SMBv3.

Sonstige Dienste¶

Ähnlich wie Netzwerk-Dienste behandelt das GVfs auch folgende Orte:

Die Tabelle zeigt nur Beispiele und erhebt keinen Anspruch auf Vollständigkeit

Ein- und Aushängen¶

Die gio-Befehle können nur dann ausgeführt werden, wenn die angesprochenen Objekte (Dateisysteme usw.) eingehängt sind. Sofern dies nicht vorher schon anderweitig geschehen ist (z.B. durch Eintrag in /etc/fstab), muss das Einhängen zuerst mit dem Befehl gio mount [OPTIONEN] ORT erfolgen.

Dem Befehl gio mount kommt daher eine besondere Bedeutung zu. Deshalb wird auf diesen in dem Artikel gio mount ausführlich eingegangen.

Übersicht der gio-Kommandos¶

Folgende Tabelle dient zur Übersicht über die gio-Kommandos. Dem jeweiligen Befehl muss noch gio vorangestellt werden.

Shell-Skripte¶

Die gio-Kommandos können grundsätzlich in Shell-Skripten verwendet werden. Ausgeschlossen sind allerdings Skripte, die beim Systemstart bzw. Einloggen des Benutzers vor dem Start des GVfs-Hauptdaemons gvfsd ausgeführt werden sollen. Dies ist beim Erstellen von systemd-Services zu beachten.

Der Eintrag von Start-Skripten in /etc/rc.local ist deprecated und kann auch mit Skripten, die gio-Kommandos enthalten, nicht funktionieren. Außerdem funktionieren solche Skripte nicht in Cronjobs. Dagegen ist ein Eintrag in "Startprogramme"(Xfce: "Sitzung und Startverhalten > Automatisch gestartete Anwendungen") problemlos möglich.

Alternativer Zugriff¶

Für Anwendungen, die einen POSIX-konformen Zugriffspfad brauchen, richtet das GVfs über FUSE einen alternativen Mountpunkt ein. Standardmäßig befindet sich dieser im Ordner /run/user/gvfs/BENUTZER-IP/. Für das Funktionieren der Dateimanager und der gio-Kommandos wird dieser nicht gebraucht.

Der alternative Mountpunkt wird nur noch selten gebraucht. Er wird vom Daemon gvfsd-fuse erstellt und verwaltet. Möchte man von ihm zur Erhöhung der Performance und zur Schonung der Ressourcen keinen Gebrauch machen, so kann der Daemon gvfsd mit der Option --no-fuse laufen. Weil aber der Daemon gvfsd beim Systemstart automatisch ohne diese Option gestartet wird, muss man ihn hierfür über die Zeile

`gvfsd -r --no-fuse`  

Dauerhaft lässt sich der Daemon gvfsd-fuse über die Systemvariable GVFS_DISABLE_FUSE deaktivieren. Hierzu trägt man in der Datei in der Datei ~/.profile folgende Zeile ein:

 export GVFS_DISABLE_FUSE=1

Metadaten¶

Beachtung verdient auch der Dienst gvfsd-metadata. Über diesen werden zur Sicherheit bei allen gio-Operationen (auch den lokalen), die Metadaten verändern (also z.B. Speichern oder Verschieben), diese zur Sicherheit im Ordner ~/.local/share/gvfs-metadata zwischengespeichert und nach erfolgreicher Operation wieder gelöscht, sodass sie bei einem ungewollten Abbruch noch verfügbar bleiben. Unter Umständen kann dies jedoch zu einer erheblichen Verzögerung von Dateioperationen und zu einer großen Belastung von Prozessor, Netzwerk und Festplatte (wichtig z.B. bei SSD) führen. Manchmal kann es deshalb sinnvoll sein, den Daemon gvfsd-metadata zu deaktivieren. Dies kann durch folgende Kommandos geschehen bzw. rückgängig gemacht werden:

systemctl --user mask gvfs-metadata.service
systemctl --user unmask gvfs-metadata.service 

Die Maskierung ist für die betreffende Sitzung wirksam und muss nötigenfalls bei jedem Einloggen wiederholt werden. Möchte man den Daemon mitten in einer Sitzung deaktivieren, so kann zusätzlich noch folgende Zeile nötig sein:

systemctl --user stop gvfs-metadata.service 

Ob der Daemon aktiv ist, überprüft man mit folgendem Befehl:

systemctl --user status gvfs-metadata.service 

gio und GVfs mit Root-Rechten¶

gio ist für die Verwendung im Userspace ohne Root-Rechte konzipiert. Wie auch die Dateimanager (z.B. Nautilus, Thunar), so sollte auch gio möglichst nicht mit Root-Rechten^[2] ausgeführt werden. Ist dies jedoch nicht vermeidbar, so muss der Befehl sudo mit dem Parameter -H verwendet werden.

Früher stand für die Ausführung graphischer Anwendungen mit Root-Rechten der Befehl gksudo aus dem Paket gksu zur Verfügung. Seit Ubuntu 18.04 LTS ist dies aus Gründen der Sicherheit nicht mehr der Fall. Mit dem Ort admin://... bietet das GVfs seit Ubuntu 17.10 nun einen Ersatz.

Beispiele:

nautilus admin:/// 

startet den Dateimanager Nautilus mit Root-Rechten, und mittels

gedit admin:///etc/fstab 

kann man die Systemdatei /etc/fstab mit Root-Rechten bearbeiten. Die Kommandos können im Gegensatz zu sudo -H auch ohne Terminal^[1] verwendet werden; die Abfrage des Passworts erfolgt in einem besonderen Fenster.

Alternativen¶

Die gio-Kommandos für den Ort smb:// sowie dessen Server und Freigaben funktionieren auch mit dem neueren Protokollen SMBv2 und SMBv3. Allerdings werden bei diesen nicht alle Features unterstützt. Eine Alternative bietet das Tool smbclient aus dem gleichnamigen Paket

• smbclient

Befehl zum Installieren der Pakete:

sudo apt-get install smbclient 

Oder mit apturl installieren, Link: apt://smbclient

Mittels

smbclient -L SERVER 

kann man die Freigaben auf dem Server anzeigen (ähnlich gio list smb://SERVER), und mit

smbclient //SERVER/FREIGABE 

öffnet man dort eine Shell für viele Kommandos, die dort zum Teil ähnliche Funktionen ausführen wie gio-Kommandos, ohne dass dafür der Server bzw. die Freigabe eingehängt (gemounted) werden müsste.

gio mount und gio open¶

Die Kommandozeile

gio mount smb://diskstation/public; gio open $_ 

hängt die Freigabe public auf dem Server diskstation ein und öffnet zu ihr ein Fenster. Gleiches lässt sich auch für das Windows-Netzwerk als Ganzes durchführen:

gio mount smb://; gio open $_ 

gio tree¶

Das Kommando gio tree [OPTION] ORT ersetzt das Kommando tree, ohne dass dafür das Paket tree zusätzlich installiert werden müsste. Verbunden mit grep eignet es sich als Suchfunktion:

gio tree smb://Heimserver/Bilder | grep Aachen 

sucht in dem auf Heimserver freigegebenen und mittels gio mount auf dem Client eingehängten Ordner Bilder und dessen Unterordnern alle Dateien, in deren Namen "Aachen" enthalten ist. Vorsicht: Bei extrem vielen Dateien kann dies zum Abbruch mit der Fehlermeldung "zu viele offene Dateien" führen!

gio info und gio set¶

Dateiattribute auslesen: Das Kommando gio info [OPTION] ORT liefert wesentlich mehr Informationen als ein Klick mit der rechten Maßtaste und dann "Eigenschaften" im Dateimanager. Die sehr umfangreiche Ausgabe kann man mit Optionen einschränken. So erhält man z.B. mit

gio info -a time ORT
gio info -a metadata ORT 

den Zeitstempel und die metadata-Informationen.

Attribut "trusted" setzen: Ein Benutzer hat nun z.B. einige Skripte erstellt, für diese im Ordner ~/.Desktop Programmstarter erstellt und diese ausführbar gemacht. Doch beim Aufruf bekommt er die Meldung, diese seien nicht vertrauenswürdig. Nötig ist noch das Dateiattribut metadata::trustet true. Mit folgendenm kleinen Skript trust-desktop.sh kann er dieses für alle Programmstarter in ~/.Desktop setzen:

#!/bin/bash
# trust-desktop.sh
# alle Programmstarter in .Desktop auf "vertrauenswürdig" setzen:
#
for i in ~/.Desktop/*.desktop; do
  [ -f "${i}" ] || continue
  gio set "${i}" "metadata::trusted" true
done

Dieses muss nur noch mit

sudo chmod +x trust-desktop.sh 

ausführbar gemacht werden

Ikon für Ordnersymbol: Der Benutzer Tim möchte den Ordner /home/Tim/Photos/Eva, der Bilder von seiner Freundin enthält, mit einem netten Icon verzieren. Ein solches ist z.B. /home/Tim/Icons/Eva.png. Dies geschieht nun so:

gio set -t 'string' /home/Tim/Photos/Eva 'metadata::custom-icon' 'file:///home/Tim/Icons/Eva.png' 

gio list smb://SERVER funktioniert nicht¶

Mittels gio list smb://SERVER erhält man eine Liste aller auf dem mittels gio mount smb://SERVER eingehängten Server vorhandenen Freigaben. Dies funktioniert allerdings nur dann, wenn auf dem Server das Protokoll SMBv1 verfügbar ist. Bei neueren Servern (Windows 10, Ubuntu ab Version 20.04 LTS) ist aber SMBv1 standardmäßig deaktiviert. Man kann dies auf dem Server wieder aktivieren – in Ubuntu z.B. durch den Eintrag der Zeile

server min protocol = NT1

im Abschnitt [global] der Datei /etc/samba/smb.conf, muss sich aber dabei bewusst sein, dass dies die Sicherheit des Netzwerks beeinträchtigen kann.

Kann oder möchte man den Eintrag auf dem Server nicht vornehmen, so kann man auf dem Client statt gio list auch das Kommandozeilen-Tool smbclient verwenden (s.o.). Mit diesem erhält man auch ohne SMBv1 eine Freigaben-Liste des Servers. Hierzu braucht dieser nicht einmal eingehängt zu sein.

gvfs-metadata braucht zu viel Ressourcen¶

In seltenen Fällen kommt es vor, dass der Service gvfs-metadata ungewöhnlich viel Prozessorleistung und Speicherplatz beansprucht. Dann kann es sein, dass sich ein fehlerhafter Prozess in einer Dauerschleife verfangen hat und dass sich dabei bis zum Timeout (oder Absturz) erhebliche Mengen von Datenschrott im Ordner ~/.local/share/gvfs-metadata angesammelt haben, die diesen unbrauchbar machen und so die weitere Ausführung von GVfs/GIO behindern.

Da der Inhalt dieses Ordners nur sehr selten wirklich gebraucht wird, kann man in einem solchen Fall den Ordner – nötigenfalls von der Konsole aus – mit folgender Befehlszeile einfach löschen:

rm -rf ~/.local/share/gvfs-metadata 

Bei Bedarf wird dann automatisch ein neuer, leerer Ordner angelegt.