staging.inyokaproject.org

gio mount

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:


Du möchtest den Artikel für eine weitere Ubuntu-Version testen? Mitarbeit im Wiki ist immer willkommen! Dazu sind die Hinweise zum Testen von Artikeln zu beachten.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

gio mount ist ein Kommandozeilen-Befehl zum Einbinden von Dateisystemen und anderen Orten in das GVfs (Gnome Virtual File System). Das GVfs ist eine virtuelle Dateisystemebene innerhalb der GTK-basierten grafischen Benutzeroberflächen GNOME, MATE und Xfce (Xubuntu). Da dieses sich im Benutzerbereich ("Userspace") befindet, sind fürs Einbinden mittels gio mount im Gegensatz zum systemweiten Einbinden mit den Kernel-Routinen von mount keine Root-Rechte[3] erforderlich. Es muss dafür auch nirgends ein SUID-Bit gesetzt sein, und es ist auch kein vorbereitender Eintrag in /etc/fstab nötig.

gio mount ersetzt seit Ubuntu 18.04 LTS den früheren Befehl gvfs-mount

Intern wird gio mount auch von den GTK-basierten Dateimanagern Nautilus, Caja und Thunar verwendet, allerdings mit einer eingeschränkten Auswahl an Optionen (siehe z.B Samba Client GNOME).

Auf die ins GVfs eingehängten Orte kann man mittels Dateimanager, mit vielen Anwendungsprogrammen oder im Terminal[2] mit mit dem Kommandozeilenprogramm gio ähnlich wie auf Dateien des lokalen Dateisystems zugreifen.

In KDE (Kubuntu) übernehmen KIO-Slaves weitgehend die Funktionen des GVfs.

Installation

Für das GVfs werden die Pakete gvfs-backends und gvfs-fuse benötigt. Das Kommandozeilenprogramm gio ist im Paket libglib2.0-bin enthalten. Alle drei Pakete sind elementare Bestandteile von Ubuntu und dessen Derivaten, soweit diese GTK einsetzen (z.B. Xubuntu, Ubuntu MATE).

Das Paket gvfs-bin wird normalerweise nicht mehr gebraucht. Es enthält die Weiterleitung des veralteten Befehls gvfs-mount auf den Befehl gio mount.

Anwendung

Dateisysteme und Orte

Die Argumente der Kernel-Routine mount sind Dateisysteme im strengen Sinn. Bei gio mount sind diese weiter gefasst. So kann z.B. auch der Papierkorb, eine Kamera oder sogar die gesamte Netzwerk-Umgebung als Ganzes Argument von gio mount sein. Die Argumente von gio mount werden deshalb allgemein mit ""locations"", auf deutsch "Orte" bezeichnet. Näheres dazu siehe gio.

Mountpunkt

Von den Kernel-Routinen des Pakets mount her ist man gewohnt, dass man zum Einbinden eines Dateisystems immer zuerst einen Einhängepunkt (Mountpunkt) erstellen und diesen dann im mount-Befehl angeben muss. Für das GVfs gilt dies nicht. Dieses erstellt automatisch einen geeigneten Mountpunkt, der im Befehl gio mount nicht anzugeben ist, und der auch beim Aushängen des Dateisystems wieder selbständig gelöscht wird. Wo sich dieser Mountpunkt befindet, hängt von der Art des eingebundenen Ortes ab.

Einbinden lokaler Dateisysteme

Als "lokal" gelten Dateisysteme, die in der Systemdatei /dev eingetragen sind, also interne Datenträger (Festplatten) oder auch direkt am Rechner angeschlossen externe Datenträger wie USB-Sticks, CD-ROM usw. Üblicherweise werden lokale Dateisysteme, die nicht schon anderweitig eingebunden oder per Eintrag in /etc/fstab zum temporären Einbinden vorbereitet sind, vom jeweiligen Dateimanager (Nautilis, Thunar ...) beim ersten Zugriffsversuch über das GVfs eingebunden. Dieser Vorgang geschieht transparent (d.h. vom Benutzer weitgehend unbemerkt) im Hintergrund und wird als "Dynamisches Einbinden" (Dynamisches Mounten) bezeichnet. Das Dateisystem erscheint danach in der Seitenleiste des Dateimamagers als "eingebunden" und bleibt so bis zum Ende der Sitzung. Bei MATE erscheint zusätzlich noch ein Symbol auf dem Desktop.

In den meisten Fällen erweist sich dieses Dynamische Mounten als sehr praktisch. Es hat jedoch den Nachteil, dass man dann, wenn man nicht über den Dateimanager, sondern direkt mit einem Anwendungsprogramm oder auch über das Netzwerk auf eine solche Datei zugreifen möchte, leicht übersieht, dass diese eventuell noch gar nicht eingebunden ist. Dies gilt umso mehr, wenn in der Seitenliste des betreffenden Dateimanagers auch Dateisysteme angezeigt werden, die zwar vorhanden, aber nicht eingebunden sind.

Deshalb kann jeder Anwender ohne Root-Rechte[4] Dateisysteme dieser Art mittels GVfs auch unabhängig vom Dateimanager direkt einbinden. Im Terminal[1] oder in einem Shell-Skript geschieht dies mit dem Befehl gio mount und der Option -d bzw. --device, wie z.B.:

gio mount -d /dev/sdb1 

Den Mountpunkt für lokale Dateisysteme erstellt das GVfs selbständig im Ordner /media/USER. Als Namen für den Mountpunkt entnimmt es aus dem Eintrag in /dev das Label oder, falls nicht vorhanden, die UUID des Datenträgers. Auf das so eingebundene Dateisystem kann dann genau so wie auf jedes andere mit der Kernel-Routine mount eingebundene Dateisystem zugegriffen werden. Die Kommandozeile kann man auch als Startprogramm eintragen . Dies stellt dann eine einfache, benutzerbezogene Alternative zum systemweiten statischen Mounten mittels Eintrag in /etc/fstab oder systemd-Service dar.

Hinweis:

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.

Noch einfacher gestaltet sich das temporäre oder statische Einbinden mittels GVfs mit dem grafischen Tool Gigolo.

Experten-Info:

Orte aus der Gerätedatei /dev, die bereits über einen Eintrag in /etc/fstab oder ein systemd-Service systemweit eingebunden sind, und für die deshalb schon ein Eintrag in /etc/mtab besteht, können mit gio mount nicht noch einmal eingebunden werden. Normalerweise darf jeder Benutzer auch ohne Root-Rechte[3] jedes in /dev eingetragene, noch frei verfügbare Gerät (z.B. in einem Dual-Boot-System auch die fremden Systemdateien) mit dem GVfs einbinden. Sollte dies einmal nicht erwünscht sein, so lässt sich dies dadurch unterbinden, dass man durch einen Eintrag in fstab mit der Option noauto, aber ohne die Optionen user bzw. users ein temporäres Mounten vorbereitet, das dann aber nur mit Root-Rechten[3] möglich ist.

Lokale Dateisysteme, die mittels GVfs dynamisch über den Dateimanager oder manuell mit dem Kommando gio mount -d DATEISYSTEM eingebunden wurden, sind genau so wie Dateisysteme, die mit der Kernel-Routine mount eingebunden wurden, in /etc/mtab eingetragen und unterscheiden sich in der praktischen Anwendung nicht von diesen. Für andersartige Orte und vor allem auch für entfernte Orte (Netzwerk-Dateisysteme) ist dies nicht der Fall. Für diese gelten andere Regeln.

Einbinden von Netzwerk-Dateisystemen

Vom GVfs unterstützte Netzwerk-Dienste
Dienst Ort Erklärung
Samba smb://… Netzwerk-Verbindungen mittels SMB/cifs ("Windows-Netzwerke")
FTP ftp://… File Transfer Protocol, Netzwerkprotokoll zur Übertragung von Dateien über IP-Netzwerke
SSH ssh://… Secure Shell, Netzwerkprotokoll für verschlüsselte Verbindungen
SFTP sftp://… Für die Secure Shell (SSH) entworfene Alternative zum File Transfer Protocol (FTP)
WebDav dav://…, davs://… Netzwerkprotokoll zur Bereitstellung von Dateien über das Internet (wahlweise verschlüsselt)
MTP mtp://… Protokoll für über USB angeschlossene Smartphones
OBEX-FTP obex://… Protokoll zum Browsen und Datenaustausch über Bluetooth)

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. Für sonstige Dienste, die vom GVfs ähnlich wie Netzwerk-Dienste behandelt werden, siehe gio.

Beim Einhängen von Netzwerk-Dateisystemen ins GVfs erfolgt kein Eintrag in der Datei /etc/mtab.

Auflösung von Rechnernamen

Grundsätzlich werden Rechner im Netzwerk über ihre IP-Adresse angesprochen. Liegt ein entsprechender Eintrag in der Datei /etc/hosts vor, kann statt dessen auch der Rechnername verwendet werden. Manche Dienste stellen auch eigene Dienste zur Namensauflösung zur Verfügung (z.B. nmbd bei Samba), auf die das GVfs zurückgreifen kann.

Unabhängig davon unterstützt das GVfs auch die Namensauflösung über Avahi. Hierzu muss an den Rechnernamen noch .local angehängt werden (Beispiel: Heimserver.local). Über Avahi werden nur Rechner erkannt, auf denen ebenfalls ein Zeroconf-Service läuft (Avahi bei Linux oder Bonjour bei Mac OS X). Avahi gehört in Ubuntu zur Standard-Ausrüstung.

Transparente Verwendung im Dateimanager

Bindet man Netzwerk-Freigaben mit dem Dateimanager ("Netzwerk durchsuchen", über "Orte → Netzwerk" oder auch über die Adresszeile) ein, so wird dabei im Hintergrund gio mount verwendet (siehe auch z.B. Samba Client GNOME). Da hier das Einbinden erst beim ersten Zugriff bzw. beim Öffnen des entsprechenden Manager-Fenster erfolgt, nennt man es auch "dynamisch". Das eingebundene Dateisystem erscheint dann in der Seitenleiste des Dateimamagers und bleibt dort bis zum Ende der Sitzung. Bei MATE erscheint zusätzlich noch ein Symbol auf dem Desktop.

Kann auf die Freigaben wahlweise mit und ohne Eingabe von Benutzername und Passwort zugegriffen werden (z.B. bei Samba-Freigaben mit erlaubtem Gast-Zugang), und möchte man als Gast zugreifen, so kann man die Aufforderung zur Eingabe von Benutzername und Passwort einfach überspringen. Möglicherweise hat man dann aber auf der Freigabe weniger Rechte.

Mit gio mount werden Freigaben immer temporär, d.h. maximal für die jeweilige Sitzung, eingebunden. Nach einem Benutzerwechsel oder Neustart müssen sie wieder neu gemountet werden. Dies kann jedoch automatisiert werden.

Hinweis:

In der Seitenleiste zeigt der Dateimanager in gleicher Weise Freigaben an, die über die Kernel-Routine mount, evtl. mit Hilfsprogramm, systemweit eingebunden sind und solche, die mit gio mount im GVfs eingebunden wurden. Möglicherweise gelten in beiden Fällen ganz verschiedene Mount-Optionen und Zugriffsrechte.

Gigolo

Ein grafisches Frontend speziell für gio mount ist das Tool Gigolo. Es ist nicht nur dann von Interesse, wenn der verwendete Dateimanager das GVfs nicht unterstützt (z.B. auch ältere Versionen von Thunar oder PCManFM), denn es bietet Optionen, die über die eines gewöhnlichen Dateimanagers hinausgehen, wie z.B. das Erstellen von Lesezeichen und das automatische Einbinden von Freigaben beim Einloggen des Benutzers (Autostart).

Im Gegensatz zu Gigolo verwendet Smb4K kein GVfs.

gio mount im Terminal

gio mount lässt sich auch im Terminal[1] und in Skripten verwenden. Eine knappe Übersicht über die Syntax bietet:

gio help mount        #alternativ: gio mount -h 

Einhängen

Wie bei lokalen Dateisystemen benötigt gio mount auch beim Einbinden entfernter Orte über ein Netzwerk-Protokoll keine Angabe eines Mountpunktes. Für die Netzwerk-Freigaben wird dann aber im Gegensatz zu lokalen Dateisystemen kein Mountpunkt in /media erstellt, sondern diese werden anschließend mit genau der gleichen Syntax angesprochen, mit der sie eingehängt wurden. Um die Samba- bzw. Windows-Freigabe Musik des Servers Heimserver einzuhängen, genügt also die Befehlszeile

gio mount smb://Heimserver/Musik 

Eventuell noch benötigte Angaben von Benutzername, Domain und Passwort werden interaktiv erfragt. Anschließend erscheint in GNOME, MATE oder Unity auf dem Desktop oder im verwendeten Dateimanager das Symbol für den Netzwerk-Ordner "Musik auf Heimserver", genau wie wenn das Einbinden grafisch über Nautilus erfolgt wäre. Vom Anwendungsprogramm angesprochen wird die eingebundenen Freigabe in der Form \smb://Heimserver/Musik.

Aushängen

Zum Aushängen verwendet man auch den Befehl gio mount mit dem Parameter -u, wier z.B:

gio mount -u smb://Heimserver/Musik 

Außerdem lassen sich mit gio mount eingebundene Freigaben auch im Dateimanager mittels Mausklick wieder aushängen.

Automatisches Einbinden

Eine sehr bequeme Möglichkeit zum automatischen Einbinden von Freigaben bietet das graphische Tool Gigolo. Alternativ ist dies auch über ein Mount-Skript möglich.

Mount-Skript

Für Freigaben, die ohne Angabe von Benutzername und Passwort eingebunden werden können, genügt es, die Befehlszeilen unverändert in ein Skript zu übernehmen:

#!/bin/bash
gio mount smb://Heimserver/Fotos
gio mount smb://Heimserver/Musik

Sind jedoch zusätzliche Eingaben (z.B. von Benutzername und Passwort) nötig, wird man diese beim Abarbeiten eines Skripts nicht gerne interaktiv vornehmen. gio mount bietet zwar selbst keine Optionen an, um die Zugangsdaten im Skript zu übergeben. Es gibt aber zwei Lösungsansätze, die dieses Manko umgehen:

  1. Man kann die Zugangsdaten von GNOME speichern lassen und wird deshalb im Skript von gio mount nicht mehr nach den Zugangsdaten gefragt. Dazu genügt es, das Laufwerk einmal mit dem Dateimanager einzuhängen und bei der Frage nach den Zugangsdaten die Option "nie vergessen" auszuwählen. Das Passwort wird dabei im Schlüsselbund (Menü: "System → Einstellungen → Passwörter und Verschlüsselung") abgelegt. Da der GNOME-Schlüsselbund selbst standardmäßig mit dem Login-Passwort verschlüsselt ist und erst bei der Anmeldung des Benutzers wieder entschlüsselt wird, ist diese Methode sicherheitstechnisch die bessere. Ein fremder Benutzer kann selbst mit Root-Rechten[3] die so gespeicherten Passwörter nicht lesen.

  2. Man kann gio mount die Antworten auch durch eine Eingabe-Umleitung übergeben. Dazu wird der Inhalt einer Credentials-Datei als "Standard-Eingabe" an gio mount übergeben. Dies ist eine Textdatei mit beliebigem Namen, die man vorzugsweise versteckt im eigenen Heimverzeichnis anlegt (z.B. /home/BENUTZERNAME/.smbcreds). Diese enthält in jeder Zeile der Reihe nach die Antwort auf jede sonst interaktiv gestellte Frage. Braucht eine Frage nicht beantwortet zu werden, ist dafür eine Leerzeile vorzusehen. Um zu wissen, in welcher Reihenfolge die Fragen gestellt werden und wie viele Zeilen nötig sind, genügt es, die Befehlszeile vorher einmal direkt im Terminal[1] einzugeben.

Beispiel:

Zum Einbinden der Samba- bzw. Windows-Freigaben Dokumente und Texte auf dem Server Heimserver fragt gio mount nacheinander nach Benutzername, Domain und Passwort. Der Samba-Benutzername sei Udo, die Angabe einer Domain ist nicht erforderlich, und das Passwort laute geheim. Dann hat die Credentials-Datei folgenden Inhalt (die Leerzeile für die Domain ist bei Samba (smb) wichtig, entfällt jedoch bei anderen Diensten):

Udo

geheim

Die Befehlszeile im Skript lautet dann

#!/bin/sh
...
gio mount smb://Heimserver/Dokumente </home/udo/.smbcreds
gio mount smb://Heimserver/Texte </home/udo/.smbcreds

Wegen des unverschlüsselt eingetragenen Passworts sollte die Credentials-Datei noch mit:

chmod 0600 /home/udo/.smbcreds 

vor fremden Blicken geschützt werden. Das Mount-Skript muss dann nur noch ausführbar gemacht werden [2]

Achtung!

In einem unverschlüsselten Heimverzeichnis können auch solcherart geschützte Dateien immer noch von Fremden mit Root-Rechten[3] oder mittels einer Live-CD eingesehen werden!

Hinweis:

Der Aufbau der Credentials-Datei stimmt bei gio mount und mount.cifs (siehe mount.cifs) nicht überein.

Automatisches Mounten beim Einloggen

Um ein Skript beim Einloggen des Benutzers automatisch auszuführen, wird sein Zugriffspfad in "Startprogramme" (Xfce: "Sitzung und Startverhalten → Automatisch gestartete Anwendungen") eingetragen (siehe Autostart). Sollte sich Probleme ergeben, weil vielleicht die Netzwerk-Verbindung noch nicht bereit ist, so kann man entweder etwas Wartezeit vorsehen (z.B. eine Zeile sleep 20 vor der ersten Zeile mit cifs-mount einfügen) oder auch das Skript direkt beim verwendeten Netzwerk-Manager als "Post-Connection-Script" eintragen (siehe dazu Dispatcher).

Hinweis:

Trägt man in "Startprogramme" das Skript nicht direkt ein, sondern mit vorgestelltem gnome-terminal -e, so erscheint eine eventuelle Passwortabfrage von gio mount nach dem Login in einem Terminal[2] Fenster und kann dort beantwortet werden.

Obwohl sich gio mount problemlos in allen Start-Skripten verwenden lässt, die nach dem Einloggen des jeweiligen Benutzers abgearbeitet werden, ist die Verwendung in Cronjobs leider nicht möglich.

GVfs und FUSE, alternativer Zugriff

Die vom GVfs für den Zugriff auf Netzwerk-Freigaben verwendete Syntax (smb://…, ftp://… usw.) entspricht nicht dem POSIX-Standard. Für die meisten Dateimanager und Anwendungsprogramme ist dies kein Problem. Ein Zugriff über ein Terminal[2] ist mit dieser Syntax jedoch nur über das Kommandozeilenprogramm gio möglich. Außerdem gibt es immer noch einige Programme, die für den Dateizugriff einen POSIX-konformen Zugriffspfad verlangen.

Deshalb bindet gio mount Netzwerk-Dateisysteme (nur diese) noch zusätzlich – falls vorhanden – über FUSE an anderer Stelle ein. Standardmäßig wird /run/user/UID/gvfs/… verwendet. UID ist die Benutzerkennung desjenigen Benutzers, der den Ort eingehängt hat. Beim Erstbenutzer ist diese 1000.

Wegen des komplizierten Zugriffspfades und Namens kann es nützlich sein, für die eingebundenen Freigaben einfacher zugängliche Symbolische Verknüpfungen einzurichten.

Experten-Info:

Die für das Funktionieren des GVfs nötigen Daemonen befinden sich im Verzeichnis /usr/lib/GVfs. Beim Systemstart wird der Hauptdienst GVfsd gestartet, der seinerseits dann die übrigen Dienste aufruft.

Für den alternativen Zugriff ist der Daemon gvfsd-fuse nötig. Mit gvfsd-fuse mountpoint [options] werden der Mountpunkt für den alternativen Zugriff und ggf. noch verschiedene Mount-Optionen festgelegt. Möchte man den standardmäßig voreingestellten Mountpunkt verändern, dann empfiehlt es sich, erst den Hauptdienst mit gvfsd -r --no-fuse neu zu starten und dann anschließend gfvsd-fuse mit dem gewünschten Mountpunkt aufzurufen. Dies lässt sich auch mit einem Skript automatisieren.

Da immer weniger Anwendungen den alternativen Zugriff über fuse überhaupt noch brauchen, kann es sinnvoll sein, diesen zu deaktivieren. Temporär geschieht dies mit dem Kommando gvfsd -r --no-fuse und dauerhaft mit dem Eintrag export GVFS_DISABLE_FUSE=1 in der Datei ~/.profile .

Gelegentlich gibt es auch Probleme mit dem Daemon gvfsd-metadata. Siehe hierzu Artikel gio

Einbinden von Online-Speichern

Internet-Provider bieten oftmals noch Online-Speicher (Cloud-Speicher) an, auf den über den Webbrowser zugegriffen werden kann. Manchmal möchte man diesen auch gerne als Netzwerk-Ordner einbinden. Die vom Provider dafür bereitgestellte Software ist aber oftmals für Linux nicht geeignet. Da für den Datenaustausch WebDAV verwendet wird, lässt sich der Zugriff aber leicht mit gio mount bewerkstelligen. So lautet z.B. die Befehlszeile fürs Einbinden des T-Online-Mediencenters ("MagentaCloud"):

gio mount davs://magentacloud.de:443 

Die Port-Angabe (:443) ist meist nicht nötig. Als Benutzername muss in diesem Beispiel die T-Online-E-Mail-Adresse und als Passwort das mit T-Online vereinbarte Passwort angegeben werden. Wie oben beschrieben, lässt sich dies natürlich auch automatisieren.

Eine Liste mit Zugangsdaten verschiedener WebDAV-Anbieter findet sich hier.

Problembehebung

Freigaben lassen sich nicht einbinden

SMB-Protokoll

Ältere Server oder NAS-Geräte verstehen oftmals nur das SMB-Protokoll SMBv1. Dieses ist aber seit Samba 4.11 (ab Ubuntu 20.04 LTS) standardmäßig deaktiviert. Um auf solche Server zugreifen zu können, muß man auf dem Client im Bereich [global] der Datei /etc/samba/smb.conf folgende Zeile eintragen:

 client min protocol = NT1

Die Reaktivierung des veralteten Protokolls SMBv1 kann ein Sicherheitsrisiko sein. Deshalb sollte man diesen Eintrag nur dann vornehmen, wenn dies wirklich nötig ist. Näheres hierzu siehe Samba Client GNOME.

Authentifikation

Manchmal lassen sich Freigaben von älteren Windows-Servern oder NAS-Geräten trotz gemeinsamem SMB-Protokoll und korrekter Eingabe von Benutzername und Passwort nicht einbinden. Der Grund kann sein, dass die für die Authentifikation verwendete Verschlüsselung vom Server nicht verstanden wird.

Samba-Clients verwenden standardmäßig nur noch die starke NTLMv2-Verschlüsselung, um Kontakt mit einem Server aufzunehmen. Ältere Server (vor allem auch NAS) kommen manchmal mit den neueren Verschlüsselungen nicht klar. Zur Abhilfe kann man auf dem Client die Datei /etc/samba/smb.conf mit Root-Rechten[4] editieren und dort im Teil [global] folgende Befehlszeilen einfügen:

client NTLMv2 auth = no

und nur noch in sehr seltenen Fällen (nicht empfohlen, unsicher!):

client lanman auth = yes

Ungeeignete Namen

Obwohl nicht empfohlen, sind die üblichen Sonderzeichen wie Umlaute, "ß" usw. in den Namen von Server und Freigaben möglich. Nicht zulässig sind dagegen einige Zeichen wie z.B. Doppelpunkt (Kolon), Slash, Backslash usw. Außerdem darf der Servername nicht länger sein als 15 Zeichen. Bei Zugriffs-Problemen sollte man deshalb auch an unzulässige Namen denken.

Entstellte Datei- und Ordnernamen

Automatisch erzeugte Datei- und Ordnernamen (z.B. durch Kameras oder CD-Ripper) werden im GVfs gelegentlich bis zur Unkenntlichkeit entstellt. Grundsätzlich dürfen Datei- und Ordnernamen im GVfs auch nationale Sonderzeichen (Umlaute, Akzente) sowie Leerzeichen enthalten. Einige Zeichen wie z.B. : , / führen jedoch zu Problemen bei plattformübergreifender Nutzung. Dann gibt es keinen anderen Ausweg, als diese Dateinamen auf dem Server zu ändern – oder die Freigaben ohne GVfs (z.B. mit mount.cifs, siehe Samba Client cifs) einzubinden. Eventuell ist auch ein Zugriff mittels smbclient möglich.

Manche Dateimanager (z.B. Thunar) gestatten es nicht, symbolische Verknüpfungen zum Mountpunkt in /run/user/BENUTZER-UID/GVfs herzustellen. Der Grund dafür sind die Sonderzeichen "=", "," und ":", die dort von gio mount im Dateinamen verwendet werden. Die gewünschten Verknüpfungen lassen sich aber trotz der Sonderzeichen problemlos in einem Terminal[2] mit dem Befehl ln -s QUELLE ZIEL erstellen, wenn den Sonderzeichen ein Backslash ("\") vorangestellt oder der ganze Namen in Anführungszeichen gesetzt wird.

Beispiel:

ln -s /run/user/1000/GVfs/smb-share\:server\=diskstation\,share\=public ~/Diskstation/Public 

Zeitstempel (Datum und Uhrzeit) werden verändert

Manche Netzwerk-Protokolle erlauben die Übertragung der Dateiattribute zwischen Server und Client, z.B. Samba über die "cifs-UNIX-Extensions". Wenn dies von gio mount nicht unterstützt wird, gelten auf den Server kopierte Dateien dort als neu angelegt (erhalten das Datum des Kopiervorgangs). Vor allem bei bidirektionaler Datensynchronisation (Abgleich in beide Richtungen, siehe z.B. Unison oder FreeFileSync) kann dies zu erheblichen Problemen führen.

Intern

Extern

Diese Revision wurde am 4. Mai 2021 22:22 von ubot erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Xfce, Netzwerk, GNOME, mount, Dateisysteme, Einhängen, GVfs