Samba Client cifs
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Ubuntu 18.04 Bionic Beaver
Ubuntu 16.04 Xenial Xerus
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:
Das CIFS-VFS ist ein virtuelles Dateisystem in Linux, das den Zugang sowohl zu modernen SMBv3-Servern als auch zu älteren SMB(cifs)-Servern gestattet. Im Vergleich zum GVfs, das von den gtk-orientierten Dateimanagern (z.B Nautilus oder Thunar zum Einhängen entfernter Orte verwendet wird, unterstützt das CIFS-VFS mehr Optionen des jeweiligen SMB-Protokolls. Allerdings können ins CIFS-VFS nur einzelne Freigaben eingehängt werden. Man kann damit nicht ganze Server oder das gesamte Netzwerk als Orte einhängen und auf diesen browsen.
Hinweis:
Die Bezeichnung "cifs" in diesem Artikel betrifft das CIFS-VFS und nicht den SMB-Dialekt cifs (=SMBv1).
Dieser Artikel betrifft das Einbinden von Windows- bzw. Samba-Freigaben mit dem virtuellen Dateisystem CIFS-VFS in das lokale Dateisystem des Client. In vielen Fällen bietet auch das GVfs eine einfachere Alternative zum CIFS-VFS. Siehe hierzu gio mount und Samba Client GNOME.
Installation¶
Um das CIFS-VFS verwenden zu können, müssen folgende Pakete installiert[1] werden:
cifs-utils (main)
keyutils (main)
Paketliste zum Kopieren:
sudo apt-get install cifs-utils keyutils
Oder mit apturl installieren, Link: apt://cifs-utils,keyutils
Das Paket keyutils ist nicht in jedem Fall nötig, aber dennoch zu empfehlen.
Nutzung¶
mount.cifs¶
Das Einbinden mittels CIFS-VFS geschieht durch einen Aufruf von mount.cifs
. Dieser sollte nur indirekt über den Befehl mount mit der Option -t cifs
oder über einen Eintrag in der Datei /etc/fstab (s.u.) erfolgen. Das Aushängen geschieht mittels umount
. Den früheren Befehl umount.cifs
gibt es nicht mehr.
Im Folgenden wird zwischen "Einbinden mit hohen Privilegien" und "Einbinden mit niedrigen Privilegien" unterschieden:
Einbinden mit hohen Privilegien/systemweit: Um Freigaben mittels
mount.cifs
bzw.mount -t cifs
systemweit einzubinden, werden Root-Rechte benötigt.Einbinden mit niedrigen Privilegien: Um Freigaben auch ohne Root-Rechte persönlich einbinden und wieder aushängen zu können, muss für
mount.cifs
das SUID-Bit gesetzt sein. Dies ist standardmäßig der Fall. Sollte es jedoch einmal nicht der Fall sein, so lässt es sich mit folgender Befehlszeile nachholen:sudo chmod +s /sbin/mount.cifs
Achtung!
Der Einsatz des SUID-Bit ist eine mögliche Sicherheitslücke und sollte nur mit Bedacht verwendet werden.
Mountpunkt erstellen¶
Um eine Freigabe einzubinden, muss zunächst ein Mountpunkt erstellt werden. Dieser kann im Prinzip an jeder beliebigen Stelle im Dateiverzeichnis gewählt werden. Üblich ist jedoch folgendes Vorgehen:
Einbinden mit hohen Privilegien: Der Mountpunkt muss Eigentum von
Root
sein. Soll die Freigabe dauerhaft gemountet werden, eignet sich ein leerer Ordner im Verzeichnis /media. Möchte man die Freigabe nur vorübergehend einbinden, empfiehlt sich ein leerer Ordner in /mnt. Beispiel:sudo mkdir /media/austausch
Einbinden mit niedrigen Privilegien: Der Mountpunkt muss Eigentum des jeweiligen Benutzers sein. Es empfiehlt sich ein leerer Ordner in dessen Heimverzeichnis. Beispiel:
mkdir ~/Daten
Weitere Informationen finden sich auch in den Artikeln mount und Datenverwaltung.
Server ansprechen¶
mount.cifs führt selbst keinen Rundspruch ("Broadcast") zur Namensauflösung durch. Deshalb werden üblicherweise die Server über ihre IP-Adresse angesprochen.
Möchte man zur besseren Übersichtlichkeit trotzdem lieber Namen ("Netbios-Namen") verwenden, müssen diese entweder vom Domain Controller bereitgestellt werden oder auf dem Client in einer der Dateien /etc/samba/lmhosts (nötigenfalls anlegen) oder /etc/hosts eingetragen sein. Beispiel:
192.168.1.100 Ubuntu-Desktop
Wird die IP-Adresse über DHCP bezogen, so muss diese auf dem DHCP-Server (z.B. Router) als "permanent" gekennzeichnet sein (FritzBox: "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen").
Für Server, auf denen ein Zeroconf-Dienst läuft (Bonjour, Avahi) im gleichen Subnetz kann man die Auflösung des Servernamens Avahi überlassen. Hierfür ist der Servername mit dem Zusatz .local
zu versehen. Ansonsten ist eine definierte Auflösung des Rechnernamens nur möglich, wenn winbind installiert ist. In der Datei /etc/nsswitch.conf muss dann in der Zeile hosts
das Schlüsselwort wins
hinzugefügt werden.
Eintrag in /etc/fstab¶
Grundstruktur¶
Um Freigaben mit Root-Rechten[4] systemweit einzubinden, ist ein Eintrag in /etc/fstab nicht erforderlich, möglicherweise aber trotzdem sinnvoll. Dagegen ist ein Eintrag in /etc/fstab unbedingt nötig, um Freigaben ohne Root-Rechte persönlich einbinden zu können.
Um die Datei /etc/fstab in einem Editor[3] zu bearbeiten, sind Root-Rechte[4] nötig. Die Einträge in fstab haben folgende Grundstruktur:
Allgemein:
//SERVER/FREIGABE MOUNTPUNKT cifs OPTIONEN 0 0
FREIGABE meint hierbei den Namen der Freifabe und nicht den Zugriffspfad auf dem Server.
Beispiel:
//192.168.178.10/Tausch /media/austausch cifs rw,guest,uid=1000 0 0
Optionen¶
Passwort in der fstab hinterlegen¶
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
undnoauto
: Die Optionauto
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 Optionnoauto
ein, wird das Einbinden nur vorbereitet. Es muss dann zu einem späteren Zeitpunkt von Hand oder über ein Skript vorgenommen werden.user
undusers
: Mit diesen Optionen darf im Prinzip jeder Benutzer die Freigabe einbinden. Beiusers
darf jeder die Freigabe wieder aushängen, beiuser
nur derjenige, der sie eingehängt hat. Eine Besonderheit voncifs
ist jedoch, dass fürmount.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
undPasswort
: 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,password=geheim,domain=Gruppe1 0 0
Die Angabe
domain=DOMÄN-NAME
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:
Die früher zulässige und auch häufig verwendete Kurzform user=
statt username=
wird seit Samba-4 nicht mehr akzeptiert, da sie leicht zu Verwechslungen mit der Mount-Option user
(s.o.) führt. Ebenso ist auch die Kurzform passwd=
statt password=
nicht mehr zulässig.
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=PASSWORD 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.
Interaktiv¶
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
undfile_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.
Experten-Info:
Kerberos-Authentifikation.
Noch besser ist es, das Passwort werder im Klartext in der fstab noch in einer Authentifikationsdatei (credentials
) zu hinterlegen, sondern das Kerberos-Ticket des aktiven Nutzers zu benutzen (siehe auch Kerberos).
Beispiel: //192.168.1.100/Tausch /media/austausch cifs sec=krb5i,user,noauto 0 0
Als Sicherheitsoption sollte sec=krb5i
gewählt werden, damit die Pakete signiert werden.
Da der Nutzer beim Systemstart nicht angemeldet ist und es deshalb noch kein Ticket gibt, sollte "noauto" genutzt werden.
Alternativ kann auch ein Maschienenaccount oder PAM Mount genutzt werden.
Temporäres Einbinden¶
"Temporäres Einbinden" bedeutet, dass danach die Freigaben nur für die betreffende Sitzung zur Verfügung stehen und nicht beim Systemstart oder beim Einloggen des Benutzers automatisch wieder eingebunden werden.
Systemweit werden Freigaben mit Root-Rechten eingebunden.
Falls ein Eintrag in fstab mit der Option
noauto
vorhanden ist, genügt die Befehlszeile
Allgemein:
sudo mount MOUNTPUNKT
Beispiel:
sudo mount /media/austausch
Ist kein Eintrag in fstab vorhanden, müssen alle Eingaben – mit etwas anderer Syntax – in die Befehlszeile übernommen werden:
Allgemein:
sudo mount -t cifs -o OPTION(EN) //SERVER/Freigabe MOUNTPUNKT
Beispiel mit Credentialsdatei:
sudo mount -t cifs -o credentials=~/.smbcredentials //192.168.1.100/Tausch /media/austausch
Beispiel mit Kerberos:
sudo mount -t cifs -o username=USERNAME@DOMAIN.IT,cruid=UID_DES_NUTZERS,sec=krb5i,vers=3.0 //192.168.1.100/Tausch /media/austausch
Näheres zur Syntax siehe mount.
Persönlich bindet man Freigaben ohne Root-Rechte ein. Für /sbin/mount.cifs muss das SUID-Bit gesetzt sein (s.o.), und es muss ein Eintrag in fstab mit der Option
user
bzw.users
und einem Mountpunkt bestehen, der Eigentum des einbindenden Benutzers ist, also z.B.:
Beispiel mit Credentialsdatei:
//192.168.1.100/Daten /home/otto/Daten cifs noauto,users,credentials=/home/otto/.smbcredentials 0 0 # in fstab muss immer der komplette Pfad angegeben werden!
Beispiel mit Kerberos:
//192.168.1.100/Daten /home/otto/Daten cifs cifs sec=krb5i,vers=3.0,user,noauto 0 3 # in fstab muss immer der komplette Pfad angegeben werden!
Dann genügt zum Einbinden die Befehlszeile:
Allgemein:
mount MOUNTPOINT
Beispiel:
mount ~/Daten
Festes Einbinden¶
"Festes" oder "Statisches Einbinden" bedeutet, dass die betreffenden Freigaben nach jedem Systemstart oder nach dem Einloggen des jeweiligen Benutzers automatisch wieder zur Verfügung stehen.
Systemweit fest einbinden¶
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/crontab folgende Zeile einfügt:
@reboot root sleep 20 && mount -a
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.
Ist es nicht sicher, ob das Netzwerk beim Mounten überhaupt zur Verfügung steht (z.B. bei Laptops), so vermeidet man mit den Mount-Optionen _netdev,nofail
lästige Verzögerungen und Fehlermeldungen.
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önlich fest einbinden¶
Freigaben lassen sich am einfachsten über einen Eintrag in "Startprogramme" (XFCE/Xubuntu: "Sitzung und Atartverhalten > Automatisch gestartete Anwendungen") persönlich fest einbinden. Einzelheiten siehe Autostart
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[5] ausführbar machen und den Pfad zum Skript als Startprogramm eintragen.
Hinweis:
Benötigt man keine der speziellen Optionen, die nur mit CIFS-VFS zur Verfügung stehen, können Freigaben auch mittels gio mount (bis Ubuntu 16.04 gvfs-mount) ohne Eintrag in fstab persönlich fest eingebunden werden. Besonders einfach geht dies mit dem graphischen Tool Gigolo.
Beim ersten Zugriff einbinden ("Automount")¶
Es gibt verschiedene Möglichkeiten, 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. Diese sind im Artikel Automount beschrieben. Besonders vielseitig ist der Automounter Autofs. Wesentlich schlichter und einfacher in der Anwendung ist der systemd-Automounter, der auch über die Mount-Optionen x-systemd.automount
und x-systemd.idle-timeout
im fatab-Eintrag zur Verfügung steht (siehe fstab (Abschnitt „Automount-mit-systemd“)).
Besitz- und Zugriffsrechte¶
Für die Besitz- und Zugriffsrechte zeigt CIFS-VFS
ein unterschiedliches Verhalten, je nachdem, ob die cifs-UNIX-Erweiterungen aktiv sind oder nicht.
Die UNIX-Erweiterungen sind standardmäßig aktiv, wenn die Freigaben sich auf einem Samba-Server befinden und das verwendete SMB-Protokoll sie unterstützt, aber nicht, wenn die Freigaben sich auf einem Windows-Server befinden.
Hinweis:
Die ursprünglich für das Protokoll SMBv1 entwickelten UNIX Erweiterungen unterstützen die POSIX-ACLs nicht und haben sich zudem als unsicher erwiesen. Deshalb wurden sie für das Nachfolge-Protokoll SMBv2 nicht mehr übernommen. Im Protokoll SMB-3.1.1 ist nun unter der Bezeichnung POSIX Extensions eine erweiterte, völlige Neubearbeitung integriert, die auch die POSIX-ACLs unterstützen soll. In Samba und damit in Ubuntu ist diese bis jetzt leider noch nicht verfügbar (Stand Juni 2020, Ubuntu 20.04 LTS, Samba 4.11.6). Deshalb sind die folgenden Ausführungen derzeit nur für das veraltete Protokoll SMBv1 gültig.
Übertragung der Rechte mit cifs-UNIX-Erweiterungen¶
Sind die cifs-UNIX-Erweiterungen aktiv (auf dem Samba-Server: unix extensions = yes
, Standard), so werden die echten Besitz- und Zugriffsrechte zwischen Server und Client übertragen. Ändert man auf dem Client mittels chmod oder chown oder über den Eigenschaften-Dialog der GUI die Rechte, ist die Änderung ebenso auch auf dem Server und auf allen anderen Clients wirksam, die auf die Freigabe zugreifen.
Die Angaben in der Datei /etc/samba/smb.conf auf dem Server legen dabei den Rahmen fest, in dem Zugriffsrechte auf dem Client Gültigkeit haben. Ist z.B. eine Freigabe in smb.conf nur zum Lesen freigegeben, können für sie von keinem Client aus Schreibrechte festgelegt werden. Ist sie aber in smb.conf auch für Schreibzugriffe freigegeben, kann sie von jedem Client aus mittels chmod für "nur lesen" eingeschränkt werden. Ebenso können Freigaben, die auf dem Server den Status "nur lesen" haben, aber in smb.conf mit Schreibrechten eingetragen sind, vom Client aus mit Schreibrechten versehen werden.
Die UNIX-Erweiterungen haben Vorrang vor anderen Angaben für Besitz- und Zugriffsrechte. Sollten im Eintrag in /etc/fstab oder in der Mount-Befehlszeile solche Angaben vorhanden sein, so werden diese bei aktiven UNIX-Erweiterungen ignoriert.
Hinweis:
Da die Synchronisation der Rechte über die Übertragung von uid, gid, dir_mode
und file_mode
erfolgt, funktioniert sie nur dann richtig, wenn die zugreifenden Benutzer auf dem Server und dem Client die gleiche Benutzerkennung (UID) und Gruppenkennung (GID) haben. Diese müssen nötigenfalls noch angepasst werden.
Da eine Veränderung der Benutzer- und Gruppenkennung weitreichende Folgen haben kann, lässt sich diese nicht einfach vom GNOME-Menü aus durchführen, sondern man muss dazu im Terminal den Befehl usermod
verwenden. Siehe hierzu auch man usermod
.
Hinweis:
Befinden sich die Freigaben auf dem Samba-Server in einem FAT-Dateisystem, so wird die Funktionalität der cifs-UNIX-Erweiterungen dadurch eingeschränkt. Gleiches gilt auch für ein NTFS-Dateisystem, falls dieses ohne die Optionen permissions
und acl
eingebunden ist.
Simulation von Rechten ohne cifs-UNIX-Erweiterungen¶
Wenn der Server ein Windows-Rechner ist oder wenn auf einem Samba-Server in /etc/samba/smb.conf im Teil [global]
die Zeile unix extensions = no
eingetragen ist, werden die UNIX-Erweiterungen nicht unterstützt. Dann bindet mount.cifs
auf dem Client normalerweise alle Freigaben als Besitz desjenigen Benutzers ein, der sie gemountet hat, und überträgt eventuell vorhandene Schreibrechte nur auf diesen. Da das Einbinden in der Regel mit Root-Rechten[4] (oder über /etc/fstab) erfolgt, hat dann also nur Root
Schreibrechte.
Durch zusätzliche Angaben von uid
, gid
, file_mode
und dir_mode
können beim Mounten auf dem Client andere Besitz- und Zugriffsrechte festgelegt werden (siehe dazu auch Benutzer und Gruppen). Im fstab-Eintrag sieht dies dann so aus:
# Allgemein //SERVER-IP/FREIGABE MOUNTPUNKT cifs credentials=/PFAD/ZU/.smbcredentials,uid=UIG,gid=GID,file_mode=MODE,dir_mode=MODE 0 0 # Beispiel //192.168.1.100/Tausch /media/austausch cifs credentials=/home/otto/.smbcredentials,uid=1000,gid=1000,file_mode=0644,dir_mode=0755 0 0
Wird ohne Eintrag in fstab gemountet, ist der Mount-Befehl so zu verändern:
Allgemein:
sudo mount -t cifs -o username=BENUTZER,password=PASSWORD,uid=UID,gid=GID,file_mode=MODE,dir_mode=MODE //SERVER-IP/FREIGABE MOUNTPUNKT
Beispiel:
sudo mount -t cifs -o username=otto,password=geheim,uid=1000,gid=1000,file_mode=0660,dir_mode=0770 //192.168.1.100/Tausch /media/austausch
Werden zu file_mode
und dir_mode
keine Angaben gemacht, so gelten die Standard-Werte file_mode=0644
und dir_mode=0755
(Siehe hierzu auch Rechte sowie chmod). Bei fehlenden Angaben gilt für uid
und gid
der Wert 0
(Root).
Die so festgelegten Besitz- und Zugriffsrechte werden aber nur auf dem Client simuliert und nicht wirklich auf den Server übertragen. Werden auf dem Client Zugriffsrechte geändert oder in freigegebenen Ordnern Dateien mit anderen Besitzern angelegt, so gelten diese Änderungen nur auf dem Client und nur bis zum Aushängen (umount) der Freigabe. Beim Neustart des Client oder beim erneuten Einbinden der Freigabe gelten dann wieder die beim Einbinden (mount oder Eintrag in /etc/fstab) festgelegten Rechte.
Experten-Info:
Seit Samba 4.0 werden ACLs, die auf einem Windows-Client für Samba-Freigaben gesetzt werden, bei entsprechender Einstellung auf den (Linux-)Samba-Server übernommen und dort in POSIX-ACLs umgewandelt. Diese können dann die dort bzw. beim Mounten auf dem Linux-Client festgelegten Dateirechte überdecken. Das Verfahren hat eine gewisse Ähnlichkeit mit den cifs-UNIX-Erweiterungen (UNIX Extensions), ist aber mit diesen keineswegs identisch. Unbeabsichtigt von einem Windows-Client aus gesetzte ACLs können auf dem Server und auf Linux-Clients zu einem zunächst unerwarteten Verhalten der eingebundenen Freigaben führen.
SMB-Protokoll-Versionen¶
Das SMB-Protokoll existiert in den Versionen 1.0, 2.0, 2.1 und 3.0…3.11, die untereinander nicht vollständig kompatibel sind. Eine Kommunikation kommt nur zustande, wenn sich Client und Server auf eine gemeinsame Version einigen. Dazu ist es manchmal erforderlich, die zu verwendende Version anzugeben.
SMB1 Support¶
Vor Ubuntu 17.10 Artful Aardvark verwendet mount.cifs
standardmäßig die SMB-Version 1.0, welche alle SMB-Geräte sprechen sollten. Ab 17.10 muss man jedoch beim Einbinden die Version 1.0 per Option vers=1.0
explizit angeben, wenn man mit alten Geräten kommunizieren will. Dies betrifft insbesondere die FritzBox vor FritzOS 7.20:
sudo mount -t cifs -o vers=1.0,username=otto,password=geheim //fritz.nas/FREIGABE MOUNTPOINT
Achtung!
Das Protokoll SMBv1 (cifs, NT1) gilt als unsicher und sollte deshalb auf Rechnern mit sensiblen Daten oder in unsicheren Netzen nicht mehr zugelassen werden.
Ab Samba Version 4.11 (ab Ubuntu 20.02 LTS) ist SMBv1 sowohl auf Servern als auch auf Clients standardmäßig nicht mehr zugelassen. Es kann aber durch folgende Zeilen im Teil [global]
der Datei /etc/samba/smb.conf wieder reaktiviert werden:
server min protocol = NT1 client min protocol = NT1
SMB2 Support¶
Um die Vorteile des ab Samba 3.6 unterstützten Protokolls SMB2 zu nutzen, kann man dies mit entsprechende Option einstellen.
sudo mount -t cifs -o vers=2.0,username=otto,password=geheim //192.168.1.100/Tausch /media/austausch
Entsprechendes gilt auch für die neueren Versionen vers=2.1
und vers=3.0…3.11
, wobei allerdings noch nicht immer alle Features unterstützt werden.
Seit Samba Version 4.11 (Ubuntu 20.02 LTS) ist SMB2_02 das niedrigste standardmäßig zugelassene SMB-Protokoll. Diese Einstellung sollte nur verändert werden, wenn dies dringend nötig ist.
SMB3 Support¶
SMB v3 unterteilt sich in mehrere Unterversionen:
SMB 3.0 supported seit Kernel 3.12 für Windows 8 / Windows 2012
SMB 3.02 supported seit Kernel 3.12 für Windows 8.1 / Windows 2012 R2
SMB 3.11 supported (vollständig) seit Kernel 5.1 und für Windows 10
sudo mount -t cifs -o vers=3.1.1,username=otto,password=geheim //192.168.1.100/Tausch /media/austausch
Das Default-Protokoll, welches mount.cifs
auswählt, wenn kein Eintrag vers=xxx
vorliegt, wurde mehrmals geändert:
bei einem Kernel vor 4.13 war dies SMB1.0
bei einem Kernel ab 4.13 vor 4.13.5 war dies SMB3.0
seit Kernel 4.13.5 einigt sich der Client mit dem Server auf das höchste Protokoll, das beide verstehen und das auf beiden zugelassen ist. Bei modernen Geräten ist dies standardmäßig SMB3.11 (= vers3.1.1).
Welche Kernel-Version aktiv ist, zeigt uname -r
im Terminal.
Grafische Tools¶
Von den grafischen Tools ("Frontends"), die Browsen (mit Namensauflösung) und Einbinden ins Dateisystem miteinander verbinden, verwendet nur das KDE-Programm Smb4K das CIFS-VFS.
Weitere Einzelheiten¶
Zeitstempel¶
Sind die cifs-UNIX-Erweiterungen aktiv, dann wird beim Kopieren oder Verschieben von Ordnern und Dateien der Zeitstempel (Datum, Uhrzeit) genau so übertragen, wie wenn sich Ursprung und Ziel im gleichen Dateisystem befinden würden. Andernfalls wird der Zeitstempel nur dann übertragen, wenn die Besitzer auf dem Server und dem Client übereinstimmen; sonst gelten die kopierten Dateien als neu angelegt.
Umlaute und Sonderzeichen¶
Werden in Datei- und Ordnernamen innerhalb der Freigaben Umlaute und Zeichen wie ß
, é
usw. nicht richtig dargestellt, so ist der falsche Zeichensatz eingestellt. Die Optionen iocharset=utf8
behebt dies und bewirkt, dass beim Schreiben von neuen Dateien auch richtige Umlaute erzeugt werden. Die Angabe einer Codepage ist nicht mehr notwendig; ein entsprechender Eintrag wird von mount.cifs
ignoriert. In neueren Samba-Versionen ist als Zeichensatz UTF-8 meist voreingestellt, sodass sich die Option iocharset=utf8
erübrigt.
Wenn die cifs-UNIX-Erweiterungen aktiv sind, dürfen in Dateinamen alle auch sonst in Linux zulässigen Zeichen verwendet werden. Sonst sind – wie auch in smbfs – nur diejenigen Zeichen zulässig, die auch in Windows für Dateinamen erlaubt sind.
cifs-UNIX-Erweiterungen am Server deaktivieren¶
Um die cifs-UNIX-Erweiterungen vom Server aus zu deaktivieren, trägt man dort in der Datei /etc/samba/smb.conf im Teil [global]
folgende Zeile ein:
unix extensions = no
Dies gilt dann generell für alle Freigaben dieses Servers.
cifs-UNIX-Erweiterungen am Client deaktivieren¶
Auf dem Client kann man hingegen auch für einzelne Freigaben festlegen, dass die cifs-UNIX-Erweiterungen nicht berücksichtigt und statt dessen die Rechte gemäß den Optionen uid
, gid
, file_mode
und dir_mode
simuliert werden. Hierzu gibt man einfach bei den Mount-Optionen bzw. bei den Optionen im fstab-Eintrag noch zusätzlich die Option nounix
an.
Hinweis:
Beim Einhängen mittels GVfs werden die cifs-UNIX-Extensions grundsätzlich nicht berücksichtigt. Dies erklärt die manchmal unterschiedlichen Dateirechte von Freigaben, je nachdem ob diese mittels GVfs oder – wie hier beschrieben – mittels CIFS-VFS eingehängt wurden.
Problembehebung¶
Starten und Beenden¶
Shutdown und Reboot¶
Sind beim Shutdown noch cifs- oder NFS-Freigaben eingehängt, so kann sich dieses dadurch um bis zu 120 Sekunden verzögern. Dies ist ein altes Problem (siehe Fehlerberichte 211631 und 1577885) Die älteren Workarounds sind aber wegen der Umstellung auf systemd nun unwirksam. Auch ein Dispatcher-Skript bleibt wirkungslos, da der NetworkManager seit Version 0.9.8 beim Shutdown keine Dispatcher-Skripte mehr ausführt.
Oftmals genügt es, im NetworkManager-Applet die Option "Alle Benützer dürfen dieses Netzwerk verwenden" anzukreuzen. Dadurch wird das Netzwerk früher verbunden und deshalb später wieder getrennt. Führt dies nicht zum Ziel, so empfiehlt es sich, gemountete Samba- oder auch NFS-Freigaben vor dem Shutdown manuell auszuhängen.
Experten-Info:
Das Aushängen der gemounteten Freigaben vor dem Shutdown lässt sich durch ein "Systemd Service Unit" z.B. auf folgende Weise automatisieren:
Man verfasst ein kurzes Skript
#! /bin/sh # cifs-Freigaben aushängen # umount -alf -t cifs
Dann macht man dieses ausführbar und legt es an geeigneter Stelle ab, z.B. als /usr/local/smb-umount.sh
Dann verfasst man ein Systemd Service Unit
[Unit] Description=UmountSharesAtShutdown [Service] RemainAfterExit=true ExecStart=/bin/true ExecStop=/usr/local/smb-umount.sh [Install] WantedBy=multi-user.target
und legt dies unter folgendem Pfad ab: /usr/local/systemd/system/UmountShares.service
Nun aktiviert man das Service Unit mit folgendem Befehl
sudo systemctl enable /usr/local/systemd/system/UmountShares.service
Nach einem System-Neustart ist das Shutdown-Problem dauerhaft behoben, denn die cifs-Shares werden nun immer vor dem Beenden des multi-user.target, d.h. gleich zu Beginn des Shutdown-Prozesses, automatisch ausgehängt.
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 im Abschnitt sleep beschrieben.
Oder man verwendet einen systemd-Automounter, indem man in einem fstab-Eintrag die mount-Option x-systemd.automount
einträgt. Ein Eintrag in /etc/fstab könnte dann so aussehen:
# Beispiel: //192.168.1.100/Tausch /media/austausch cifs x-systemd.automount,credentials=/root/.smbcredentials,sec=ntlmv2,sfu,vers=1.0 0 0
Sonstige Probleme¶
Probleme mit Bytebereich-Sperrung¶
Samba unterstützt standardmäßig die Bytebereich-Sperrung (Byte-Range Lock). Einige Programme (z.B. OpenOffice.org) 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 Fehler auftreten.
Wenn das verwendete Protokoll noch SMBv1 ist, dann sollte man prüfen, ob man ein neueres Protokoll verwenden kann. Oft löst das das Problem.
Lässt sich SMBv1 nicht vermeiden, dann kann das Problem meist durch Deaktivieren des sog. "Opportunistic Locking" behoben werden. Dazu muss man in der Datei /proc/fs/cifs/OplockEnabled der Wert von '1' auf '0' ändern. Die Änderung gilt nur für die jeweilige Sitzung.
Linux Kernel ab 4.13¶
Problem: die Freigabe kann nicht geöffnet werden, in der dmesg
-Ausgabe findet sich:
No dialect specified on mount. Default has changed to a more secure dialect, SMB3 (vers=3.0), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 specify vers=1.0 on mount. For somewhat newer servers such as Windows 7 try vers=2.1. CIFS VFS: cifs_mount failed w/return code = -512
Mit Linux-Kerneln ab 4.13 ist SMB3 der Standard, vorher SMB1. Können ältere Shares nicht geöffnet werden (z.B. von Windows XP), hilft es, beim Mounten mit cifs vers=1.0
als Option anzugeben oder für Windows 7 vers=2.1
.
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 (Abschnitt „Benutzerverwaltung“)).
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.
Links¶
Verwandte Seiten¶
Samba: Überblick über das Themengebiet
Samba Client GNOME: Über GNOME/Nautilus und verwandte GUIs auf Freigaben zugreifen
Samba Client KDE: Über KDE auf Freigaben zugreifen
Smb4K: Ein entsprechendes Frontend für KDE (Kubuntu)
mount: Dateisysteme ins System einbinden
fstab: Aufbau der Datei /etc/fstab
systemd: System- und Sitzungs-Manager (Init-System) für Ubuntu u.a.
gvfs-mount: Eine einfachere Alternative zum CIFS-VFS, jedoch mit weniger Optionen (bis Ubuntu 16.04 LTS)
gio mount: Einhängen lokaler und entfernter Orte im GVfs (ab Ubuntu 18.04 LTS)
Gigolo: Ein graphisches Frontend für das GVfs
Autofs: Freigaben beim Zugriff automatisch einbinfen.
Extern¶
man mount.cifs: Linux-Manpage 🇬🇧
Samba-Wiki 🇬🇧
Linux CIFS Client Guide 🇬🇧 ⮷ (PDF)
Stop Using SMB1 🇬🇧 Ein Aufruf von Microsoft mit Erläuterungen