ubuntuusers.de

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. Ein vorbereitender Eintrag in /etc/fstab ist nicht nötig, bei lokalen Dateisystemen (s.u.) jedoch möglich.

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

Lokale Dateisysteme, also interne Datenträger (Festplatten) oder auch direkt am Rechner angeschlossen externe Datenträger wie USB-Sticks, CD-ROM usw. werden über eine Gerätedatei im Ordner /dev/ repräsentiert. Üblicherweise werden externe (entfernbare) Datenträger bereits beim Einstecken in das laufende System automatisch eingebunden ("Hotplug"). Noch nicht eingebundene lokale Datenträger (interne oder externe) werden dann beim ersten Zugriffsversuch vom Dateimanager aus ohne weiteres Zutun eingebunden. In allen diesen Fällen spricht man von "Dynamischem Einbinden".

Beim Dynamischen Einbinden (dynamischem Mounten) wird das betreffende Dateisystem transparent (d.h. unbemerkt im Hintergrund) mittels gio mount ins GVfs eingebunden. Je nach Dateimanager erscheint dann der eingebundene Ort in der Seitenleiste, oder wird er dort als "eingebunden" gekennzeichnet 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[3] Dateisysteme bzw. Orte mittels gio mount auch unabhängig vom Dateimanager direkt ins GVfs einbinden. Dies geschieht ohne Root-Rechte[3] in einem Terminal oder Shell-Skript mit einer Kommandozeile folgender Art:

gio mount -d /dev/sdb1 

Die Option -d bzw. --device ist bei lokalen Dateisystemen unbedingt erforderlich. Zur Benennung des betreffenden lokalen Dateisystems ist nur dessen Eintrag in /dev (keine UUID oder Label) zulässig..

Möchte man für das Einbinden einzelner Dateisysteme (Datenträger bzw. Partitionen) Mountpunkt und Mount-Optionen selbst bestimmen, so ist dies über einen vorbereitenden Eintrag in /etc/fstab möglich. Dieser muss jedoch mit Root-Rechten[3] vorgenommen werden und die Option noauto enthalten; die Optionen users oder user sowie das Setzen eines SUID-Bit sind nicht nötig. Beim Einbinden des betreffenden Dateisystems führt dann gio mount -d /dev/… genau diesen Eintrag aus. Zur Kennzeichnung des einzubindenden Dateisystems dürfen in /etc/fstab, nicht aber in der Befehlszeile von gio mount, außer dem Eintrag in /dev auch UUID oder Label verwendet werden. Der fstab-Eintrag bleibt auch nach Beenden der Sitzung weiterhin bestehen.

Ist das Einbinden eines lokalen Dateisystems nicht durch einen Eintrag in /etc/fstab vorbereitet, dann greift gio mount auf seine Standard-Einstellungen zurück. Den Mountpunkt für lokale Dateisysteme erstellt gio mount 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. Die Mount-Optionen legt das gio mount passend zum Dateisystem-Typ selbst fest. Selbständig erstellte Mountpunkte (nicht aber durch einen fstab-Eintrag festgelegte) werden beim Aushängen des Dateisystems oder Beenden der Sitzung auch selbständig wieder entfernt.

Durch Hotplug, dynamisch mit dem Dateimanager oder in der Kommandozeile mittels gio mount -d /dev/… eingebundene lokale Dateisysteme (aber nur solche) werden dann genau so wie jedes andere mit der Kernel-Routine mount eingebundene Dateisystem in die Datei /etc/mtab eingetragen, und sie werden auch beim Befehl mount (ohne Parameter) mit angezeigt. Auf sie kann auch in genau gleicher Weise zugegriffen werden. Die Kommandozeile für gio mount 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 gio mount mit dem grafischen Werkzeug Gigolo. Auch dieses bietet die Möglichkeit für einen Autostart.

Experten-Info:

gio mount -d /dev/… greift in genau gleicher Weise wie udisksctl -h /dev/… zum Einbinden lokaler Dateisysteme auf UDisks zurück. Deshalb können auch die generellen Einstellungen von gio mount -d (Mountpunkt, Mount-Optionen und seit Ubuntu 23.10 auch, wenn nötig, Dateisystem-Treiber) in einer Datei /etc/udisk2/mount_options.conf festgelegt bzw. verändert werden. Außerdem kann UDisks auch über Regeln für udev konfiguriert werden. Bei einander widersprechenden Angaben gilt folgende Priorität: fstab – Voreinstellung – mount_options.confudev-Regel.

im Gegensatz zur mount kann gio mount -d Dateisysteme, für die bereits ein Eintrag in /etc/mtab besteht nicht noch zusätzlich ein weiteres mal einbinden

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 (leider abgesehen vom Browsen) auch mit den modernen Protokollen SMBv2 und SMBv3. Für sonstige Dienste, die vom GVfs ähnlich wie Netzwerk-Dienste behandelt werden, siehe gio.

Hinweis:

Beim Einhängen von Netzwerk-Dateisystemen ins GVfs werden im Gegensatz zu lokalen Dateisystemen vorbereitende Einträge in /etc/fstab mit der Option noauto nicht ausgeführt, und es erfolgt auch kein Eintrag in die 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 Dateimanagers 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. Um diese Variante zu verwenden ist es nötig, dass die Freigabe im Skript genau so bezeichnet wird, wie sie nach dem Einhängen im grafischen Dateimanager erscheint! Also zum Beispiel nicht als smb://heimserver.was-auch-immer.example/Fotos sondern als smb://heimserver.local/Fotos wenn im Dateimanager sie als „Fotos auf heimserver.local“ angezeigt wird. Erst damit ist es für gio dieselbe Freigabe und die Angabe von weiteren Infos verzichtbar.

  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, muss 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 3. August 2024 06:03 von kB erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Xfce, Netzwerk, GNOME, GVfs