Grundstruktur¶

Um Freigaben mit Root-Rechten ^[4] temporär systemweit einzubinden, ist ein Eintrag in der Datei /etc/fstab nicht nötig. Möchte man Freigaben jedoch dauerhaft (fest oder statisch) oder ohne Root-Rechte persönlich einbinden, dann lässt sich seit Ubuntu 10.10 ein Eintrag nicht mehr vermeiden. Die Datei /etc/fstab muss in einem Editor ^[3] mit Root-Rechten ^[4] bearbeitet werden.

Derartige Einträge in fstab haben folgende Grundstruktur, die jeweils noch durch zusätzliche Optionen ergänzt werden müssen:

# Allgemein:
//<Server>/<Freigabe> <Mountpunkt> cifs <Liste der Optionen>  0  0
# Beispiel:
//192.168.1.100/Tausch /media/austausch cifs auto  0 0

Optionen¶

Bei den Einträgen in fstab können nur diejenigen Optionen verwendet werden, die für mount.cifs gültig sind. Man findet diese auf SourceForge oder mittels man mount.cifs. Sie stimmen nur zum Teil mit den im Artikel mount beschriebenen, für andere Dateisysteme gültigen Optionen überein.

Hier werden nur die am häufigsten benötigten Optionen aufgeführt:

• auto und noauto: Die Option auto ist standardmäßig voreingestellt. Sie bewirkt, dass die Freigabe beim Abarbeiten der Datei fstab beim Systemstart automatisch eingebunden wird, falls das Netzwerk bereits zur Verfügung steht (ist z.B. bei WLAN nicht unbedingt der Fall). Trägt man statt dessen die Option noauto ein, wird das Einbinden nur vorbereitet. Es muss dann zu einem späteren Zeitpunkt von Hand oder über ein Skript vorgenommen werden.

• user und users: Mit diesen Optionen darf im Prinzip jeder Benutzer die Freigabe einbinden. Bei users darf jeder die Freigabe wieder aushängen, bei user nur derjenige, der sie eingehängt hat. Eine Besonderheit von cifs ist jedoch, für mount.cifs das SUID-Bit gesetzt sein muss und dass grundsätzlich nur der Eigentümer des Mountpunkts die Freigabe einhängen kann. Sollen mehrere Benutzer die gleiche Freigabe einhängen dürfen, so muss für jeden ein eigener Mountpunkt und ein eigener Eintrag in fstab erstellt werden.

• Benutzer und Passwort: Auf manche Freigaben kann nur mittels Benutzername und Passwort zugegriffen werden. Sollen solche Freigaben automatisch eingebunden werden oder möchte man Benutzername und Passwort beim Einbinden nicht interaktiv angeben, muss bei den Optionen ein entsprechender Eintrag erfolgen:

  • Direkte Eingabe im Klartext: Man kann Benutzername, Passwort und nötigenfalls Domänenname direkt als Optionen eingeben

    # Beispiel:
    //192.168.1.100/Tausch /media/austausch cifs username=otto,passwd=geheim,domain=Gruppe1 0 0

    Die Angabe domain=<Domämenname> ist nur dann nötig, wenn sich der Server in einer Windowsdomäne befindet. Diese Methode ist sehr unsicher und kann allenfalls zu Versuchszwecken empfohlen werden.

    Hinweis:

    Von der Kurzform user statt username wird abgeraten, da sie leicht zu Verwechslungen mit der Mount-Option user (s.o.) führt.

  • Eingabe über eine Authentifikationsdatei. Besser ist es, eine Authentifikationsdatei zu verwenden, die über die Option credentials ausgelesen wird. Zunächst erstellt man eine versteckte Textdatei mit beliebigem Namen, z.B. .smbcredentials, im eigenen Homeverzeichnis und trägt folgenden Inhalt ein:

    username=<benutzer>
    password=<passwort>
    domain=<domain>

    Die dritte Zeile ist nur nötig, falls der Server einer Windowsdomäne angehört. Damit die Datei nur vom Besitzer eingesehen werden kann, setzt man die Rechte entsprechend

    chmod 600 ~/.smbcredentials 

    Der Eintrag in fstab lautet dann

    # Beispiel:
    //192.168.1.100/Tausch /media/austausch cifs credentials=/home/otto/.smbcredentials  0 0
    # in fstab muss immer der komplette Pfad angegeben werden!

    
    

    Hinweis:

    Mit einer Live-CD oder durch Erlangen von Root-Rechten kann immer noch jeder diese Datei lesen. Über die Verwendung des verschlüsselten Private-Verzeichnisses kann auch dies verhindert werden. Allerdings kann dann nur der Benutzer selbst die Freigabe einbinden.

  • Wird keine Authentifikationsdatei (credentials) und kein Benutzername angegeben, gilt der jeweils eingeloggte Benutzer. Das Passwort wird dann beim Einbinden interaktiv erfragt. Dies unterbleibt, wenn man die Option guest oder ein leeres Passwort einträgt.

    # Beispiel ohne Passwort (sinnvoll z.B. für USB Speicher ohne Passwort an einer Fritzbox)
    //192.168.178.1/Backup /media/Backup cifs password=  0 0

• Simulierte Dateirechte: Die Simulation von Dateirechten mit den Optionen uid, gid, dir_mode und file_mode ist nur dann von Bedeutung, wenn die cifs-UNIX-Erweiterungen nicht aktiv sind. Sie wird weiter unten erklärt.

• Zeichensatz: Früher war es noch nötig, für Sonderzeichen in Datei- und Ordnernamen den verwendeten Zeichensatz anzugeben, z.B. iocharset=utf8. Dieser Zeichensatz ist inzwischen Standard, sodass man auf diese Option üblicherweise verzichten kann.

Systemweites Automount¶

Im günstigsten Falle werden die Freigaben bereits beim Systemstart automatisch eingebunden, wenn man beim Eintrag in fstab die Option noauto vermeidet (also die Standard-Einstellung auto verwendet) und einen Mountpunkt wählt, der Besitz von root ist. Bedingung ist allerdings, dass die Netzwerk-Verbindung bereits beim Abarbeiten von fstab zur Verfügung steht, was keineswegs immer der Fall sein muss.

Handelt es sich nur um eine einfache Verzögerung beim Aufbau der Netzwerk-Verbindung, kann man mit sleep arbeiten. Dies geschieht beispielsweise, indem man in die Datei /etc/rc.local folgende Zeilen einfügt:

sleep 20
mount -a
exit 0
# die Zeile exit 0 ist schon vorhanden

Die Zahl 20 kann man dann schrittweise verringern, bis die Verzögerung gerade noch ausreicht. Bei dem Befehl mount -a werden diejenigen Freigaben, bei denen die Option noauto eingetragen ist, nicht mit gemountet.

Es ist aber auch möglich, dass die Netzwerk-Verbindung erst bei oder nach dem Einloggen des jeweiligen Benutzers hergestellt wird (z.B. bei einem WPA-verschlüsselten WLAN). Dann führt auch dies nicht zum Ziel. Wie ein systemweiter Automount über ein "Post-Connection-Script" trotzdem gelingen kann, ist auf den Wiki-Seiten der Netzwerk-Manager NetworkManager und Wicd bzw. auf der Seite interfaces beschrieben.

Persönliches Automount¶

Freigaben lassen sich am einfachsten über einen Eintrag in "Startprogramme" (GNOME: "System -> Einstellungen -> Startprogramme", KDE: "Systemeinstellungen -> Erweitert -> Autostart", XFCE: "Einstellungen -> Alle Einstellungen -> Autostarted apps"; Einzelheiten siehe hier) persönlich fest einbinden.

Hierzu erstellt man für jede der betreffenden Freigaben einen Eintrag in fstab mit den Optionen noauto und users sowie einem Mountpunkt, dessen Eigentümer der betreffende Benutzer ist. Dann öffnet man einen Editor ^[3] und erstellt ein kleines Skript (ausführbare Textdatei) folgender Art:

#! /bin/sh
#
mount <Mountpunkt1>
mount <Mountpunkt2>
...

Für <Mountpunkt1> usw. können (im Gegensatz zu fstab) auch die relativen (verkürzten) Pfade der Mountpunkte eingetragen werden.

Man muss dann nur noch das Skript in Nautilus über -> "Eigenschaften -> Zugriffsrechte" oder mittels

sudo chmod +x <Skript> 

ausführbar machen und den Pfad zum Skript als Startprogramm eintragen.

Automount erst beim Zugriff¶

Eine Möglichkeit, Freigaben nicht schon beim Systemstart oder beim Einloggen, sondern erst beim Zugriff automatisch einzubinden und sie auch automatisch wieder auszuhängen, wenn über längere Zeit kein Zugriff erfolgt, bietet das Tool Autofs. Seit Ubuntu 16.04 bietet auch systemd bereits standardmäßig diese Möglichkeit, allerdings mit weniger Optionen als Autofs.

Shutdown und Reboot¶

Falls beim Herunterfahren ("shutdown") und beim Neustart ("reboot") des Client noch Freigaben eingehängt sind, bekommt man vom cifs-vfs unter Unständen Fehlermeldungen der folgenden Art, die zu erheblichen Verzögerung führen:

CIFS VFS: server not responding. No response for cmd 50 ...

Dies tritt vor allem bei systemweit eingebundenen Freigaben aus einem verschlüsselten WLAN auf, wenn die Verbindung zu diesem mit einem der Netzwerk-Manager Network-Manager oder Wicd hergestellt wurde, und ist in einem Problem der Start-Reihenfolge beim Boot-Vorgang begründet.

Nach einiger Wartezeit wird der Vorgang trotzdem fortgesetzt. Es kann daher nicht allgemein empfohlen werden, das Problem dadurch zu lösen, dass man das cifs-vfs früher aushängt, etwa indem man in /etc/rc0.d und /etc/rc6.d die Priorität des Links zur Datei /etc/init.d/umountnfs (in üblicherweise S31) verändert. Die möglichen Datenverluste wiegen schwerer als die Verlängerung der Wartezeit.

Das Problem lässt sich dadurch umgehen, dass man entweder die systemweit eingebundenen Freigaben vor dem Herunterfahren manuell aushängt oder die Freigaben nur persönlich einbindet. Wurden die Freigaben mit der Option users eingehängt, dann eignet sich zum Aushängen auch folgendes Skript, für das man auch einen Starter anlegen kann:

#! /bin/sh
# Samba-Freigaben aushängen
#
umount -f <Mountpunkt1>
umount -f <Mountpunkt2>
...

Das Skript muss ausführbar gemacht werden und kann z.B. unter /usr/local/smb-umount.sh abgelegt werden.

Das folgende unter /etc/init/smb-umount.conf mit Root-Rechten anzulegende Skript führt dazu, dass die Freigaben automatisch bereits vor dem Abarbeiten der rc-Scripte ausgehängt werden:

description "unmount the smb-connection"

start on starting rc
task
exec /usr/local/smb-umount.sh

Man muss in diesem Fall jedoch selbst darauf achten, dass zu diesem Zeitpunkt keine Programme mehr laufen, die auf die Freigabe schreiben, da diese erst später automatisch beendet würden und es so zu Datenverlusten kommen könnte.

Stellt man Verbindung zum Netzwerk ohne Netzwerk-Manager durch einen Eintrag in /etc/network/interfaces her, tritt das Problem üblicherweise gar nicht auf.

Einträge in /etc/fstab werden beim Systemstart nicht eingebunden¶

Einträge in /etc/fstab) sollten beim Systemstart automatisch eingebunden werden (wenn nicht noauto eingetragen ist). Bei Freigaben mit cifs-vfs funktioniert dies manchmal nicht. Der Grund ist, dass die Netzwerk-Verbindung und das Dateisystem noch nicht vollständig aktiviert sind, wenn fstab abgearbeitet wird.

In diesem Fall lassen sich die Freigaben mit

sudo mount -a 

von einem Terminal aus nachträglich einbinden. Wie man dies automatisieren kann, ist bereits oben beschrieben.

CIFS-UNIX-Erweiterungen und ältere Samba-Versionen¶

Versucht man, Freigaben mit aktivierten UNIX-Erweiterungen auf Clients mit älteren Samba-Versionen mittels cifs-vfs einzuhängen, kann es zu Fehlern kommen. Auch beim Zugriff mit neueren Samba-Versionen auf Server mit älteren Versionen (z.B. ein NAS) kann es sein, dass Datei-Attribute falsch interpretiert und Ordner nicht als solche erkannt werden (mount error 20 = Not a directory). Man sollte dann entweder auf dem Server oder auf dem Client die UNIX-Erweiterungen deaktivieren (siehe oben).

DFS und ältere Samba-Versionen¶

Seit Ubuntu 8.10 (Samba Version 3.2.3) kommt es gelegentlich zu Problemen mit der Unterstützung von DFS bei Verbindungen zu Servern mit älteren Samba-Versionen (vorwiegend bei NAS-Systemen). Dabei werden die gleichen Fehlermeldungen ausgegeben wie bei Fehlern durch UNIX-Extensions. Hier hilft meistens die Option nodfs im Mount-Befehl oder im fstab-Eintrag.

Probleme mit Bytebereich-Sperrung¶

Neuere Samba-Versionen unterstützen die Bytebereich-Sperrung (Byte-Range Lock). Einige Programme (z.B. OpenOffice.org, TrueCrypt) kommen damit nicht zurecht und können deshalb auf gemountete Samba-Freigaben trotz korrekter Berechtigungen nicht schreiben. Abhilfe schafft hier die Mount-Option nobrl.

Symbolische Verknüpfungen in Freigaben¶

Grundsätzlich können Symbolische Verknüpfungen ("symbolic links", "symlinks") auf dem Server über Samba freigegeben werden. Bei entsprechender Konfiguration des Samba-Servers wird ihnen dann dort gefolgt, wenn sie vom Client aus aufgerufen werden. Da jedoch Symlinks in Verbindung mit den cifs-UNIX-Extensions ein Sicherheitsrisiko darstellen können, ist diese Möglichkeit bei neueren Samba-Versionen standardmäßig deaktiviert.

Möchte man, dass beim Aufruf vom Client aus auch Verknüpfungen gefolgt wird, muss man auf dem Server entweder die Symlinks durch den Befehl mount --bind (siehe mount) bzw. einen entsprechenden Eintrag in fstab ersetzen oder aber in smb.conf die UNIX-Extensions mit dem Eintrag unix extensions = no deaktivieren und im Teil [global] noch folgende Zeilen einfügen:

follow symlinks= yes 
wide links= yes

Probleme beim Versand größerer Datenmengen¶

Beim Versand größerer Datenmengen können auf manchen Systemen ähnliche Fehlermeldungen wie auch oben beschrieben auftreten. Durch ein Deaktivieren des sog. "Opportunistic Locking" kann dies behoben werden. Dazu muss in der Datei /proc/fs/cifs/OplockEnabled der Wert von '1' auf '0' geändert werden. Da die Datei beim Start von cifs geschrieben wird, muss sie bei jedem Systemstart geändert werden. Dies wird durch ein Einfügen folgender Zeilen

modprobe cifs
echo 0 > /proc/fs/cifs/OplockEnabled

# die Zeile exit 0 ist schon vorhanden
exit 0

in /etc/rc.local erreicht.

mount error(13): Permission denied¶

Die Fehlermeldung "mount error(13): Permission denied" kann verschiedene Ursachen haben. Häufig treten folgende auf:

• Dateirechte und Freigabe-Optionen. Auf eine Freigabe kann nur derjenige zugreifen, dem dies auf dem Server sowohl von den Freigabe-Optionen als auch von den UNIX-Dateirechten und ggf. noch von den ACLs her gestattet ist. Schlägt der Versuch eines Gast-Zugriffs fehl (Option guest), liegt dies meist an unzureichenden Dateirechten auf dem Server. Tritt bei einem persönlichen Zugriff mit Benutzername und Passwort diese Fehlermeldung auf, so kann es auch sein, dass die Credentials-Datei fehlerhaft ist oder dass man vergessen hatte, für diesen Benutzer auf dem Server einen eigenen Samba-Account mit sudo smbpasswd -a USER einzurichten (siehe hierzu Samba Server).

• Authentifizierung. Mit Ubuntu 13.04 wurde die Authentifizierung in Samba/cifs aktualisiert (Details) . Standardmäßig wird nun dafür nur noch die stärkere Verschlüsselung NTLMSSP/NTLMv2 benützt. Möchte man ab Ubuntu 13.04 eine Samba- oder Windows-Freigabe eines Servers mounten, der diese Verschlüsselung noch nicht unterstützt, bekommt man beim Versuch des Mountens ein "mount error(13): Permission denied" oder auch "mount error(5): Input/output error". Das betrifft z.B. ältere FritzBoxen oder NAS Geräte. Abhilfe bringt es, eine "einfachere/ältere" Verschlüsselung zu nutzen und diese explitit beim Mounten als Option anzugeben (z.B. sec=ntlm oder bei sehr alten Servern auch sec=lanman). Alle zulässigen sec=... Optionen liefert wie üblich man mount.cifs.
  Alternativ kann man auch für den gesamten Client die Verschlüsselung zurücksetzen, indem man im Teil [global] der Datei /etc/samba/smb.conf folgende Zeile einfügt:

   client NTLMv2 auth = no 

• FritzBox: Auf aktuellen FritzBox Modellen muss ggf. vorher ein entsprechender zusätzlicher neuer Benutzer mit Passwort angelegt werden: FRITZ!Box --> System --> FRITZ!Box-Benutzer --> Benutzer. Dieser Benutzer und das Passwort wird dann für den Zugriff per cifs verwendet.