Zugriff auf Netzwerkverzeichnisse mit Nautilus

»Immer Ärger mit Nautilus« wäre eigentlich eine treffendere Überschrift. In diesem Text geht es darum, wie Sie mit dem Gnome-Dateimanager auf Windows- oder Samba-Netzwerkverzeichnisse zugreifen. Dieses Programm hieß ursprünglich Nautilus (der Paketname lautet weiterhin so), später bekam es den nichtssagenden Namen Dateien bzw. im Englischen Files. Ich bleibe hier bei Nautilus, wobei der Name ja noch das geringste Problem ist …

Wie es früher funktionierte

Vor langer Zeit führten Sie in Nautilus das Menükommando Orte / Netzwerk aus. Nautilus zeigte eine Liste aller Windows-Rechner bzw. Samba-Server im lokalen Netzwerk an. Per Doppelklick wählten Sie einen Rechner aus und bekamen eine Liste von Netzwerkverzeichnissen (shares) zu sehen. Ein weiterer Doppelklick öffnete das Verzeichnis. Wenn das Verzeichnis mit einem Passwort abgesichert wurde, mussten Sie sich entsprechend anmelden. Alles in allem ein unkomplizierter Prozess.

Mittlerweile ist die Sache schwieriger, und warum das so ist, bedarf einer etwas längeren Erklärung …

SMB-Grundlagen

Die Basis aller Windows- bzw. Samba-Netzwerkverzeichnisse ist das Protokoll Server Message Block, kurz SMB (Wikipedia). Dieses Protokoll gibt es in verschiedenen Versionen seit 1983 (!!). Die folgende Tabelle fasst überblicksmäßig einige wichtige SMB-Versionen zusammen — und ab welcher Windows- bzw. Samba-Version diese unterstützt werden. (Die Samba-Versionsnummer ist aber mit Vorsicht zu genießen, weil neue SMB-Funktionen oft erst Schritt für Schritt über mehrere Samba-Versionen implementiert wurden. Die Tabelle soll nur als Richtlinie dienen.)

SMB 1.0     Windows 2000       ???
SMB 2.0     Windows Vista      ab Samba 3.6
SMB 2.1     Windows 7          ab Samba 3.6
SMB 3       Windows 8          ab Samba 4.1
SMB 3.1     Windows 10         ab Samba 4.3

Aus Gründen der Abwärtskompatibilität unterstützen Windows und Samba alle Versionen parallel. Client und Server kommunizieren also miteinander, stellen fest, welche Version die Gegenseite unterstützt, und einigen sich auf die bestmögliche Lösung.

In den letzten Jahren haben sich allerdings gravierende Sicherheitsprobleme in SMB 1 herausgestellt, die unter anderem von der Schadsoftware WannaCry ausgenutzt wurde. Microsoft empfiehlt schon seit 2016, SMB 1 explizit zu deaktivieren. In aktuellen Windows-Versionen ist dies standardmäßig der Fall. Auch in aktuellen Samba-Versionen ist SMB 1 mittlerweile standardmäßig deaktiviert; es kann aber bei geeigneter Konfiguration weiterhin aktiviert werden.

Längerfristig werden also immer weniger Netzwerkverzeichnisse SMB 1 unterstützen, ganz egal ob diese von Windows-Rechner, NAS-Geräten oder Linux-Servern angeboten werden. Und in ein paar Jahren ist SMB 1 hoffentlich (endlich) ausgestorben. Wer also auf Windows- oder Samba-Netzwerkverzeichnisse zugreifen will, muss zumindest SMB 2 verstehen.

Browsing

Woher weiß ein Windows- oder Linux-Rechner, welche Netzwerkverzeichnisse im lokalen Netzwerk verfügbar sind? Bis SMB 1 hieß die Antwort Browsing. Das Protokoll SMB enthielt also spezielle Funktionen, um anderen Rechnern mitzuteilen, welche SMB-Server sich im Netzwerk befinden, welche Verzeichnisse (shares) sie anbieten usw.

Diese Funktionen wurden allerdings mit SMB 2 entfernt. Als Ersatz kommt unter Windows das Protokoll WS-Discovery (WSD) zum Einsatz. Linux kann mit Avahi zumindest andere Server/Geräte im lokalen Netz erkennen, allerdings nicht feststellen, welche Netzwerkverzeichnisse diese anbieten. Umgekehrt sehen auch Windows-Rechner nicht, welche Ressourcen ein Samba-Server anbietet. Die bessere Integration von WSD-Diensten unter Linux/Samba ist seit mehr als einem Jahrzehnt eine offene Baustelle.

Vorsicht, Firewall

Unter Debian und Ubuntu gibt es standardmäßig keine Firewall, die den Zugriff auf Windows-Verzeichnisse blockiert. Unter CentOS, Fedora, (open)SUSE und RHEL ist dies hingegen der Fall. Losgelöst von allen SMB-Protokollproblemen wird der Zugriff auf Netzwerkverzeichnisse nie funktionieren, wenn eine Firewall die entsprechenden Ports blockiert. Sie müssen also SMB explizit erlauben. Die Firewall-Konfigurationsprogramme aller genannten Distributionen bieten diese Möglichkeit.

Ärger mit Nautilus

Nach diesem langen Exkurs zurück zu Nautilus. Dieses Programm verwendet für den Zugriff auf SMB-Shares die Bibliothek gvfs-smb. (Die betreffenden Dateien sind je nach Distribution im Paket gvfs-backends versteckt.) Leider funktioniert der Umgang mit Netzwerkverzeichnissen seit Jahren erbärmlich, und daran sind nicht nur die (zugegebenermaßen komplizierten) technische Gegebenheiten schuld. Nautilus stürzt sang- und klanglos ab, zeigt unsinnige bzw. nicht zielführende Fehlermeldungen an und lässt seine Nutzer dumm sterben, um es etwas drastisch zu formulieren.

Dank Avahi erkennt Nautilus in der Regel die meisten im Netzwerk befindlichen anderen Geräte/Rechner/Server/Arbeitsgruppen. Der Versuch, per Doppelklick eine Verbindung zu einem Rechner mit Windows-Netzwerkverzeichnissen herzustellen, scheitert aber zumeist mit einer Fehlermeldung (siehe die Abbildungen am Beginn des Blog-Beitrags). Was nun?

Unter »Andere Orte« zeigt Nautilus Rechner bzw. Geräte im lokalen Netzwerk

Im Internet werden Sie auf diverse Anleitungen stoßen, Client- oder Server-seitig das Protokoll SMB 1 zu erzwingen. Das ist aber selten eine gute Idee. Die Anweisung client max protocol = NT1 in /etc/samba/smb.conf auf dem lokalen Rechner nützt nichts, wenn der Server (der Windows-Rechner, das NAS-Gerät) zumindest SMB 2 voraussetzt; das ist, wie oben erläutert, zunehmend der Regelfall. Und bei eigenen Samba-Servern handeln Sie sich mit server max protocol = NT1 alle erdenklichen Sicherheitsprobleme ein.

Eine deutlich bessere Lösung gibt es, wenn Sie wissen, wie der Name des Netzwerkverzeichnisses lautet: Dann drücken Sie in Nautilus zuerst Strg+L und geben dann smb://hostname/sharename ein, wobei Sie hostname durch den Namen des Rechners/Geräts ersetzen und sharename durch den Namen des Netzwerkverzeichnisses (in der folgenden Abbildung also users/ms/pictures). Anschließend gelangen Sie in einen Login-Dialog, in dem Sie den Benutzernamen für das Netzwerkverzeichnis und das dazugehörende Passwort angeben.

Mit Strg+L können Sie den Host- und Share-Namen per Tastatur eingeben
Passwortdialog

Nicht immer ist offensichtlich, welchen Share-Namen ein Netzwerkverzeichnis hat. Wenn das Verzeichnis von einem Windows-Rechner angeboten ist, klicken Sie es dort im Dateimanager mit der rechten Maustaste an und führen das Kontextmenükommando Eigenschaften / Freigaben aus.

Unter Windows den Namen des Netzwerkverzeichnisses herausfinden

In den meisten Fällen werden Sie wie oben beschrieben zum Ziel kommen. Dann empfiehlt es sich, das Netzwerkverzeichnis gleich als Lesezeichen zu speichern, damit Sie sich den Ärger beim nächsten Mal ersparen: Klicken Sie in der Seitenleiste von Nautilus auf das Netzwerkverzeichnis und führen den Kontextmenüeintrag Lesezeichen hinzufügen aus!

Letzter Ausweg: Terminal

Ich hatte allerdings auch schon Fälle, wo Strg+L samt der Angabe der korrekten Share-Bezeichnung nicht funktionierte, zuletzt unter Ubuntu 19.04. Dann gilt die alte Linux-Regel, dass es im Terminal immer eine Lösung gibt. Erzeugen Sie also ein lokales Verzeichnis, in dem Sie das Netzwerkverzeichnis einbinden möchten, und führen Sie danach mount -cifs wie im folgenden Beispiel aus:

sudo mkdir /media/nas
sudo mount -t cifs -o user=myname,uid=1000 //myhostname/mysharename /media/nas
Password for myname@//myhostname/mysharename:  ******

Dabei geben Sie mit user=myname den Login-Namen für das Netzwerkverzeichnis an. myhostname ersetzen Sie durch den Namen des Windows-Rechners oder NAS-Geräts, mysharename durch den Namen des Netzwerkverzeichnisses. Dank uid=1000 hat der Standardbenutzer Ihres Linux-Rechners Zugriff auf das Netzwerkverzeichnis. Wenn es auf Ihrem Linux-Rechner mehrere Benutzer gibt, ermitteln Sie die richtige UID-Nummer des aktuellen Accounts mit dem Kommando id. In Nautilus können Sie nun das Verzeichnis /media/nas öffnen.

Wenn Sie fertig sind, lösen Sie mit umount das Netzwerkverzeichnis wieder.

sudo umount /media/nas

Quellen

7 Gedanken zu „Zugriff auf Netzwerkverzeichnisse mit Nautilus“

  1. Weist du details zum Problem mit dem erkennen der Verzeichnissen. Warum ist das eine so grosse Baustelle?

  2. Ich nutze Ubuntu 18.04. mit Gnome, also Standard. Als ich den Beitrag sah dachte ich „jetzt hat jemand eine Lösung“. Daraufhin habe ich es noch einmal in Nautilus probiert ob da diese Fehlermeldung auftritt. Aber alles geht so “ wie es früher einmal funktionierte“. Bin überrascht weil ich es lange nicht mehr so nutzte sondern auch nur die SMB Adresse eingegeben habe.

  3. Dank den Ubuntus 18.04 sind im Nautilus auch viele Lesezeichen. Für das Einbinden der smb-, nfs- und webdav-Freigaben nutze ich derweilen die fstab mit cifs und auto bzw. manuelles mounten der Verzeichnisse. Dann sind die Verzeichnisse bequem nutzbar.
    Aber autofs bietet ja das automatische ein- und aushängen an sowie die Anzeige der Shares im Dateisystem (nautilus/mc).
    https://wiki.ubuntuusers.de/Autofs/
    Diese Umstellung ist nächstes Projekt für mich.

  4. Hast du schon einmal probiert einen Symlinks mit Nautilus zu erzeugen und dabei die SMB3 Protokoll Version benutzt?
    Links werden erzeugt und gespeichert. Folgen kann Nautilus diese dann leider nicht mehr (Ubuntu 18.04.3 LTS).
    Nautilus öffnet ein neues Fenster im gleichem Verzeichnis.

    Bei der SMB3 Version werden „mfsymlinks“ (Minshall+French symlinks) erzeugt anstatt „symbolic links“.

    https://askubuntu.com/q/1109766

  5. Hallo Michael

    Danke für den verständlichen Artikel. Als ich vor vier Jahren etwa zu openSUSE mit Gnome gewechselt bin, hat mich diese Baustelle etliche graue Haare gekostet.
    Für das Verwalten meiner Shares verwende ich anstelle der von Dir empfohlenen Favoriten ein Tool namens Gigolo https://wiki.ubuntuusers.de/Gigolo/ Das macht mir das Leben wesentlich leichter.

    Gruß;
    James

  6. Ich kämpfe auch alle Jahre wieder mal mit diesem Problem und hoffe noch immer, dass sich an dieser Front etwas tut.

    Selbst wenn man dann mittels gvfs auf eine samba-freigabe zugreifen kann — performanter Netzwerkdursatz sieht anders aus…
    Das liegt wohl an einer zu klein gewählten Blockgröße beim Kompilieren von libsmbclient, welches von gvfs-smb benutzt wird¹.

    An der Arbeit, wo mein samba-server immer verfügbar ist, benutze ich /etc/security/pam_mount.conf.xml bzw. ~/.pam_mount.conf.xml aus dem debian Paket libpam-mount. Dabei werden die shares beim Login seamless gemountet. Wenn der Server aber mal nicht da ist, summiert jedes einzubindende Share 30sec auf den Loginvorgang. Das ist äußerst nervig im Fall der Ausfälle ;-)

    Zu Hause mit einer synology diskstation benutze ich die autofs Funktionalität von systemd. Im nautilus habe ich ein bookmark auf /home/thorsten/NetShares und ein Klick darauf mountet automatisch alle Ordner.

    Der Nachteil ist aber, dass das nicht mit systemd user units funktioniert, sondern global im system zu konfigurieren ist.
    (bei mir leider ebenfalls nur mit smbversion 1.0)

    root@mobi:/etc/systemd/system# cat home-thorsten-NetShares-video.mount
    [Unit]
    Description=cifs mount script for video
    Requires=network-online.target
    After=network-online.service

    [Mount]
    What=//diskstation.local/video
    Where=/home/thorsten/NetShares/video
    Type=cifs
    Options=credentials=/home/thorsten/.smbcredentials,vers=1.0,user

    [Install]
    WantedBy=multi-user.target

    und das hier ist zu enablen

    root@mobi:/etc/systemd/system# cat home-thorsten-NetShares-video.automount
    [Unit]
    Description=cifs mount script for video
    Requires=network-online.target
    After=network-online.service

    [Automount]
    Where=/home/thorsten/NetShares/video
    TimeoutIdleSec=30

    [Install]
    WantedBy=multi-user.target

    und die Zugangsdaten, die diesmal nicht aus pam kommen:

    cat /home/thorsten/.smbcredentials
    user=BenutzerName
    password=GeheimesPasswort

    Schöner und mit ein wenig mehr Durchsatz ist da die NFS Variante:

    root@mobi:/etc/systemd/system# cat home-thorsten-NetShares-videoNFS.mount
    [Unit]
    Description=NFS mount script for videoNFS
    Requires=network-online.target
    After=network-online.service

    [Mount]
    What=diskstation.local:/volume1/video
    Where=/home/thorsten/NetShares/videoNFS
    Type=nfs
    Options=vers=4,rw,user

    [Install]
    WantedBy=multi-user.target

    Wie gesagt, bisher ist es mir noch nicht gelungen den systemd-automount Mechanismus als user-unit umzusetzen, sodaß es für ein multiuser System geeignet wäre.

    Die libpam-mount Variante ist toĺl – solange man immer im gleichen Netz ist und das Datengrab auch angeschaltet ist. Sie taugt auch für ein multiuser System dank Platzhaltern wie uid=%(USER) in der XML Datei. nautilus ist zu langsam und leidet unter den von dir beschriebenen Problemen.

    Zu KDE2 Zeiten habe ich LinNeighborhood, jetzt pyneighborhood genutzt. Aber das bricht meinen Workflow, integriert sich nur unzureichend in die Desktopumgebung. Und einen python3 kompatible Version auf pypi hat erst Version 0.1.1. gigolo fühlt sich (bei mir unter mate) tatsächlich am natürlichsten an.

    Ich bin ein ansible-Fan und wünsche mir eine scriptbare/automatisierbare Lösung für ein multiuser System. Auch im Jahr 2019 scheint mir NFS die am einfachsten zu implementierende Möglichkeit zu sein auf ein Netzwerkshare zuzugreifen. Das bedingt aber idealerweise zwecks Sicherheit eine LDAP/Kerberos Umgebung. Also nix für Ottonormal. (Ich arbeite mit dem univention ucs-Server, der exportiert shares sowohl mit cifs, als auch per nfs, wenn man das möchte).

    Ich würde mich freuen, wenn du das Thema in deinem Blog nochmal beleuchten könntest und einen Überblick zum einfachen aber sicheren Umgang mit Netzwerkspeichern vorstellen würdest.

    Vllt haben sich Dropbox/$Cloud Lösungen deswegen so weit verbreitet, weil sie einfach funktionieren :-/

Kommentare sind geschlossen.