[[Vorlage(getestet, noble)]] [[Inhaltsverzeichnis(2)]] {{{#!vorlage Wissen [:Pakete_installieren:Pakete installieren] [:Terminal: Ein Terminal verwenden] [:Editor:Einem Editor verwenden] [:mit Root-Rechten arbeiten:] [:Rechte/#Datei-ausfuehrbar-machen: Dateien ausführbar machen] [:fstab:Systemdatei '''/etc/fstab'''] }}} Dieser Artikel betrifft das Einbinden von SMB-Freigaben von z. B. Windows- und Samba-Servern als virtuelles Dateisystem [https://www.kernel.org/doc/html/latest/admin-guide/cifs/usage.html CIFS vfs] {en} in das lokale Dateisystem des Clients. Dazu wird das Kernel Modul [https://wiki.samba.org/index.php/LinuxCIFSKernel cifs.ko] {en} in Verbindung mit dem Programm [https://linux.die.net/man/8/mount.cifs mount.cifs] {en} genutzt. mount.cifs ist Bestandteil der [https://wiki.samba.org/index.php/LinuxCIFS_utils cifs-utils] {en}. In vielen Fällen bietet auch das [:gio mount:GVfs] eine einfachere Alternative zum CIFS vfs (siehe hierzu [:gio mount:] und [:Samba Client GNOME:]). 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. {{{#!vorlage Hinweis Dieser Artikel betrifft nur das Einhängen mittels CIFS-Vfs. Für das GVfs gelten andere Regeln. Die Bezeichnung "cifs" in diesem Artikel betrifft das CIFS-vfs und nicht den SMB-Dialekt cifs (=SMBv1). }}} = Installation = Um das CIFS vfs mit dem Programm `mount.cifs` verwenden zu können, wird das standardmäßig installierte Paket `cifs-utils` benötigt. Sollte das Paket nicht vorhanden sein, kann es nachinstalliert[1] werden: {{{#!vorlage Paketinstallation cifs-utils, main }}} = Nutzung = == Einbindung == {{{#!vorlage Hinweis `mount.cifs` sollte nur transparent über `mount -t cifs` aufgerufen werden, d. h. `mount.cifs` tritt für den Benutzer nicht explizit in Erscheinung. }}} Das Einbinden als CIFS vfs geschieht durch einen Aufruf des Befehls [:mount:] mit der Option `-t cifs` oder über einen Eintrag in der Datei '''/etc/fstab'''[6]. Das Aushängen geschieht mittels `umount`. Zum grundsätzlichen der 4 Felder in einer Datenzeile der Datei '''/etc/fstab'''[6] lese deren Artikel: {{{QUELLE MOUNTPUNKT cifs OPTIONEN,CIFS-OPTIONEN }}} Die Bedeutung der ersten 3 Felder und des Teils OPTIONEN in 4. Feld wird in diesem Artikel vorausgesetzt und es werden nur die [#Optionen-fuer-cifs spezifischen Optionen für `cifs`] erläutert. Im Folgenden wird zwischen "Einbinden mit hohen Privilegien" und "Einbinden mit niedrigen Privilegien" unterschieden: * Einbinden mit hohen Privilegien/systemweit: Um Freigaben mittels `mount -t cifs` (bzw. `mount.cifs`) systemweit einzubinden, werden [:sudo: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 [:Rechte#Sonderrechte: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:{{{#!vorlage Befehl sudo chmod +s /sbin/mount.cifs }}} Siehe Hinweise in [:mount/#Virtuelle-Netzwerkdateisysteme: virtuelle Netzwerkdateisysteme]. == Mountpunkt erstellen == Um eine Freigabe einzubinden, muss zunächst ein [:mount: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: Soll die Freigabe in der GUI sichtbar sein, eignet sich ein leerer Ordner im Verzeichnis '''/media/''', anderenfalls kann man z.B. einen leerer Ordner in '''/mnt/''' verwenden. Beispiel: [[Vorlage(Befehl, "sudo mkdir -p /media/austausch" ) ]] * Einbinden mit niedrigen Privilegien: Der einbindende Benutzer benötigt Schreib- und Leserecht für den Mountpunkt, daher eignet sich gut ein leerer Ordner in dessen Heimverzeichnis. Beispiel: [[Vorlage(Befehl, "mkdir -p ~/Daten" ) ]] Weitere Informationen finden sich auch in den Artikeln [:mount:] und [:Datenverwaltung:]. == Server ansprechen == Servernamen werden von `mount.cifs` grundsätzlich (per DNS) aufgelöst (siehe [https://wiki.samba.org/index.php/Mounting_samba_shares_from_a_unix_client#General_description hier] {en}). Um mögliche Fehlerquellen bei der Namensauflösung auszuschließen, ist die Verwendung der IP des Servers jedoch die bevorzugte Methode. [[Anker(Optionen) ]] == Optionen für cifs == Allgemeine Optionen siehe [:fstab/#Feld-4-Optionen:]. === Allgemein === `mount.cifs` muss mittels diverser Optionen bedarfsgerecht genutzt werden. Bspw. ist die Angabe eines (Gast-)Benutzers und Passworts zwingend notwendig, um auf die SMB-Freigaben zuzugreifen. Nachfolgend werden häufig genutzte Optionen aufgeführt: * `guest`: Zugriff auf die Freigabe als Gast. Die Angabe eines Passwortes ist hier nicht erforderlich. * `username` und `password`: Auf manche Freigaben kann nur mittels Benutzername und Passwort zugegriffen werden. Siehe dazu den nachfolgende Abschnitt [:mount.cifs/#Benutzer-und-Passwort: Benutzer und Passwort]. * `uid` / `gid`: Mit den Optionen `uid` (Benutzer) bzw. `gid` (Gruppe) wird der Eigentümer aller Dateien gesetzt, die eingehangen werden. * `vers`: Erzwingen einer bestimmten SMB-Protokollversion, z. B. `vers=1.0`. * `noserverino`: Mit `noserverino` werden keine inodes des Servers verwendet, sondern nur die inodes des Clients. Diese Option kann im Fehlerfall verwendet werden. * `cache`: Die Deaktivierung des Caches `cache=none` kann helfen, falls die SMB-Freigaben nicht korrekt eingehangen werden. * `nobrl`: Deaktivierung der Bytebereich-Sperrung (Byte-Range Lock). Einige Programme kommen mit dem Byte-Range Lock nicht zurecht und können deshalb auf gemountete SMB-Freigaben trotz korrekter Berechtigungen nicht schreiben. Abhilfe schafft hier die Mount-Option `nobrl`. * `posix`: Aktivierung fer SMB3-POSIX-Erweiterungen (ab SMB 3.1.1) === Benutzer und Passwort === Sollen 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 }}}Die Angabe `domain=DOMÄNENNAME` 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. {{{#!vorlage 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. }}} 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 {{{#!vorlage Befehl chmod 600 ~/.smbcredentials }}} Der Eintrag in '''fstab''' lautet dann{{{ # Beispiel: //192.168.1.100/Tausch /media/austausch cifs credentials=/home/otto/.smbcredentials }}}{{{#!vorlage Hinweis Mit einer Live-CD oder durch Erlangen von Root-Rechten kann immer noch jeder diese Datei lesen. Über die Verwendung eines mit ecryptfs 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= }}} * 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 [#Simulation-von-Rechten 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. {{{#!vorlage Experten '''Kerberos-Authentifikation''' Noch besser ist es, das Passwort weder im Klartext in der '''fstab''' noch in einer Authentifikationsdatei (`credentials`) zu hinterlegen, sondern das Kerberos-Ticket des aktiven Nutzers zu benutzen. Beispiel: {{{//192.168.1.100/Tausch /media/austausch cifs sec=krb5i,user,noauto \}}} 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. }}} == Statisches Einbinden == === Grundstruktur === Um Freigaben mit Root-Rechten[4] systemweit einzubinden, ist ein Eintrag in [:fstab:/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 4 Felder (Die beiden optionalen Felder 5 und 6 haben beim Dateisystemtyp `cifs` immer die Werte `0 0` und können daher entfallen.) und haben folgende Grundstruktur: Allgemein: {{{ //SERVER/FREIGABE MOUNTPUNKT cifs OPTIONEN }}} * FREIGABE meint hierbei den Namen der Freigabe und nicht den Zugriffspfad auf dem Server. * MOUNTPOINT bezeichnet einen existierenden Ordner und muss in fstab muss immer mit komplettem Pfad angegeben werden. * OPTIONEN siehe: [#VFS-Optionen VFS-Optionen] und [#Optionen Optionen] Beispiel: {{{ //192.168.178.10/Tausch /media/austausch cifs _netdev,noauto,user,username=SMB-USERNAME }}} [[Anker(VFS-Optionen) ]] === Wichtige Optionen für das statische Einbinden === Man kann die generellen Optionen von `mount` benutzen, welche unabhängig vom Dateisystem sind (z. B. noauto, _netdev, user, users) und solche, welche speziell `mount.cifs` mitbringt (z. B. username, password, serverino, cache, guest). Nachfolgend werden häufig genutzte 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, dass 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. * `_netdev`: Die Option gibt an, dass sich das Dateisystem auf einem Gerät befindet, das Netzwerkzugriff erfordert (wird dazu verwendet, das System an Versuchen zum Einhängen des Dateisystems zu hindern, bevor das Netzwerk auf dem System aktiviert wurde). * `nofail`: Die Option meldet keine Fehler für dieses Gerät, wenn es nicht existiert. Insbesondere in Kombination mit `noauto` nützlich, wenn der SMB-Server nicht dauerhaft im Netzwerk erreichbar ist. * `x-systemd.device-timeout=1ms`: Konfiguriert, wie lange systemd auf das Auftauchen eines Gerätes warten soll, bevor es bei einem Eintrag aus /etc/fstab aufgibt. In Kombination mit `noauto` und `nofail` nützlich. Zu den Optionen von mount.cifs wird auf Abschnitt [:mount.cifs/#Optionen: Optionen] verwiesen. == 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 [:sudo:Root-Rechten] eingebunden. * Falls ein Eintrag in '''fstab''' mit der Option `noauto` vorhanden ist, genügt die Befehlszeile Allgemein: {{{#!vorlage Befehl sudo mount MOUNTPUNKT}}}Beispiel:{{{#!vorlage Befehl sudo mount /media/austausch }}} * Ist kein Eintrag in '''fstab''' vorhanden, müssen alle Eingaben – mit etwas anderer Syntax – in die Befehlszeile übernommen werden:\\ Allgemein: {{{#!vorlage Befehl sudo mount -t cifs -o OPTION(EN) //SERVER/Freigabe MOUNTPUNKT}}} Beispiel mit Credentialsdatei: {{{#!vorlage Befehl sudo mount -t cifs -o credentials=~/.smbcredentials //192.168.1.100/Tausch /media/austausch}}} Beispiel mit Kerberos: {{{#!vorlage Befehl 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 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 }}} Beispiel mit Kerberos: {{{ //192.168.1.100/Daten /home/otto/Daten cifs sec=krb5i,vers=3.0,user,noauto 0 3 }}} Dann genügt zum Einbinden die Befehlszeile:\\ Allgemein: {{{#!vorlage Befehl mount MOUNTPOINT}}} Beispiel: {{{#!vorlage Befehl 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 '''[:Cron:/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/Dispatcher:NetworkManager] bzw. auf der Seite [:interfaces:] beschrieben. === Persönlich fest einbinden === Freigaben lassen sich am einfachsten über einen Eintrag in ''"Startprogramme"'' (XFCE/[:Xubuntu:]: ''"Sitzung und Startverhalten > 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. {{{#!vorlage Hinweis Benötigt man keine der speziellen Optionen, die nur mit CIFS vfs zur Verfügung stehen, können Freigaben auch mittels [:gio 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 fstab-Eintrag zur Verfügung steht (siehe [:fstab/#Automount-mit-systemd: Automount-mit-systemd]). = Besitz- und Zugriffsrechte = Für die Besitz- und Zugriffsrechte zeigt `CIFS vfs` ein unterschiedliches Verhalten, je nachdem, ob die [:Samba#CIFS:SMB3-POSIX-Erweiterungen] aktiv sind oder nicht. == Übertragung der Rechte mit SMB3-POSIX-Erweiterungen == Im veralteten Protokoll SMBv1 (=cifs), von dessen weiterer Verwendung dringend abgeraten wird, gab es zur Übertragung von UNIX-Dateirechten die '''cifs-UNIX-extensions'''. Diese haben sich als instabil und unsicher erwiesen. Deshalb wurden sie nicht weiter entwickelt und in das Nachfolge-Protokoll SMBv2 __nicht mehr__ übernommen. Über Jahre hinweg wurde bereits an einem Ersatz für die cifs-UNIX-Erweiterungen für SMB 3 gearbeitet (Arbeitstitel smb3 UNIX extensions). Seit Samba 4.18 stehen diese nun im Protokoll ab SMB 3.1.1 (SMB 3.11) in erweiterter und performanterer Form als SMB3-POSIX-Erweiterungen grundsätzlich zur Verfügung und wurden für Samba 4.22 mit Unterstützung der '''[wikipedia:Sovereign Tech Agency:]''' noch einmal von Grund auf überarbeitet. Sie ersetzen die cifs-UNIX-Erweiterungen, sind aber keine Weiterentwicklung derselben, sondern technisch gesehen eine komplette Neukonzeption. {{{#!vorlage 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`. }}} {{{#!vorlage Hinweis Befinden sich die Freigaben auf dem Samba-Server in einem FAT- bzw. exFAT-Dateisystem, so wird die Funktionalität der SMB3-POSIX-Erweiterungen dadurch eingeschränkt. Gleiches gilt auch für ein NTFS-Dateisystem, falls dieses ohne die Optionen `permissions` und `acl` (im Kernel-Dateitreiber [:ntfs3:] automatisch vorhanden) eingebunden ist. }}} {{{#!vorlage experten * die cifs-UNIX-Extensions hatten versucht, die UNIX-Dateirechte (rwx, uid, gid) im Betrieb ständig zu synchronisieren, wodurch in einem gemischten Netzwerk Samba-Clients genau wie Windows-Clients erscheinen sollten. Dazu werden die UNIX-Dateirechte auf die Windows SID bzw. NT-ACL gemappt, die dann bei jedem Zugriff von einem Linux-Client übersetzt und ggf. neu synchronisiert werden. Die Windows-SID enthält also alle Dateirechte, für Windows- und UNIX-Clients. * dieses Ziel ist technisch sehr schwierig und grundsätzlich nur unvollkommen erreichbar. Dies führte zu unvermeidbaren Stabilitätsproblemen und Missverständnissen. * Bei den SMB3-POSIX-Erweiterungen findet diese teilweise Synchronisation der Windows- und POSIX (=UNIX)-Dateirechte einmalig beim Erstellen eines Ordners bzw. einer Datei Datei oder beim ersten Zugriff über das Netzwerk statt. Der Datei werden dann aber auf dem Server ggf. sowohl die Windows-SID als auch die UNIX-Dateirechte zugeordnet. Im weiteren Verlauf bleiben dann die Rechtesysteme von einander getrennt, und damit bleibt jedes davon in sich konsistent. Dies bedeutet: Jeder Ordner und jede Datei kann sowohl Windows-Dateirechte (SID) als auch UNIX-Dateirechte (rwx, UID, GID) besitzen. Die Windows-Rechte (SID) sind nur für Windows-Clients sichtbbar und können nur über diese verwaltet werden. Die UNIX-Rechte sind hingegen nur für den Server und Samba-Clients sichtbar und können nur über diese verwaltet werden. * Durch diese strikte Trennung der Dateisysteme ist es zwar möglich, für die gleiche Datei im Windows-Bereich und im UNIX-Bereich verschiedene Dateirechte festzulegen (was mit den cifs-UNIX-Erweiterungen in einigen Fällen unbeabsichtigt leider auch geschehen konnte), aber jedes Dateisystem kann in seiner Funktionalität vollkommen realisiert werden. Für Linux-Clients bedeutet dies, dass geeignet eingebundene ([:mount.cifs:gemountete]) Samba-Freigaben ohne Einschränkungen auf dem Client genau so behandelt werden können wie Dateien des lokalen Dateisystems – einschließlich z.B. Hard- und Softlinks, Dateiattribute usw.. "Interferenzen" mit der Windows-Welt sind ausgeschlossen.}}} Die SMB3-POSIX-Erweiterungen erfordern das Protokoll SMB 3.1.1 (bzw. 3.11) und können (theoretisch) ab Samba 4.18 experimentell verwendet werden. Voll funktionsfähig sind sie erst seit Samba 4.22, standardmäßig aktiviert sind sie dann ab Samba 4.23 (12.09.2025). Gegenüber den UNIX-Erweiterungen von SMBv1 bieten die POSIX-Erweiterungen u.a. folgende Verbesserungen: * bessere Sicherheit und Performance * Kein Abbilden (Mapping) von UNIX-Dateirechten auf Windows-SID und -ACLs * keine gegenseitige Beeinflussung von UNIX-Dateirechten (rwx, UID, GID) und Windows-Rechten (SID, NT-ACL) * volle Unterstützung von Hard-und Symlinks. Zurzeit (2026) ist eine Übertragung der in Linux optional verwendeten POSIX-[:ACL:] auch in den SMB3-POSIX-Erweiterungen noch nicht direkt implementiert. Angeblich ist dies weniger ein technisches Problem als vielmehr das Problem einer fehlenden einheitlichen Normung. Vor Samba 4.23 müssen die SMB3-POSIX-Erweiterungen auf dem Server durch den Eintrag `smb3 unix extensions = yes` in der Datei '''[:smb.conf:]''' und durch die Mount-Option `posix` auf dem Client aktiviert werden, was eine durchgängige Verwendung des Protokolls SMB 3.1.1 voraussetzt. Ab Samba 4.23 sind sie serverseitig standardmäßig aktiviert. Von auf dem Client mittels [:mount.cifs:] und SMB 3.1.1 gemounteten Freigaben werden sie dann automatisch genutzt, wobei evtl. vorhandene Optionen wie `uid=…` oder `umask=…` ignoriert bzw. anders interpretiert werden. Durch die Mount-Option `noposix` lassen sich aber die POSIX-Erweiterungen clientseitig unterbunden, sodass wieder die genannten anderen Optionen wirksam sind. Einfach gesagt: Der Server bieter ab Samba 4.23 die POSIX-Erweiterungen immer an, doch der Client kann diese für jede Freigabe einzeln annehmen oder ablehnen. {{{#!vorlage Hinweis Leider ist bisher noch für keine der aktuellen Ubuntu-Versionen die offiziell freigegebene, stabile Samba-Version 4.23 in den Repositorien enthalten (Stand 2025). Sie kann aber aus PPAs installiert (dies kann u.u. das System gefährden) oder selbst aus dem Quelltext compiliert werden}}} Zurzeit (2026) werden die SMB3-POSIX-Extensions nur von ''mount.cifs'' (`mount -t cifs …`), aber noch nicht vom [:gio mount:GVfs:] direkt unterstützt. == Simulation von Rechten == Wenn der Server ein Windows-Rechner ist oder wenn auf einem Samba-Server in [:Samba_Server:/etc/samba/smb.conf] im Teil `[global]` die Zeile `smb3 posix extensions = no` eingetragen ist, werden die POSIX-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:Benutzer und Gruppen]). Im '''fstab'''-Eintrag sieht dies dann so aus: {{{# Allgemein //SERVER-IP/FREIGABE MOUNTPUNKT cifs credentials=/PFAD/ZU/.smbcredentials,uid=UID,gid=GID,file_mode=MODE,dir_mode=MODE # Beispiel //192.168.1.100/Tausch /media/austausch cifs credentials=/home/otto/.smbcredentials,uid=1000,gid=1000,file_mode=0644,dir_mode=0755 }}} Die Auswirkung dieser Einträge unterscheidet sich wesentlich, je nachdem ob die SMB3-POSIX Erweiterungen aktiv sind oder nicht: * ohne SMB3-POSIX Erweiterungen gelten die eingetragenen Werte auf dem Client unabändrlich für alle Ordner und Dateien der Freigabe * mit den SMB3-POSIX-Erweiterungen bekommt der aktuell eingeloggte Benutzer erst mit dem Eintrag uid=UID den vollen Besitz der unter seiner UID vom Server bezogenen Ordner bzw. Dateien. Ohne diesen Eintrag werden die Dateien Root zugeordnet (uid=0), und als Fallback gelten dann die übrigen Einträge. Durch diese einfache Schutzmaßnahme wird wirksam verhindert. dass ein nicht privilegierter Benutzer jemals ohne Erlaubnis Änderungen an den Dateirechten auf dem Server vornehmen kann. * Für Dateien, für die noch keine UNIX-Dateirechte festgelegt sind (z.B. in Windows erstellte Dateien oder Dateien auf einem einschränkenden Dateisystem wie exFAT) gelten grundsätzlich die eingetragenen Werte für uid, gid, fmask, dmask und umask (Fallback). Wird ohne Eintrag in '''fstab''' gemountet, ist der Mount-Befehl so zu verändern: Allgemein: {{{#!vorlage Befehl sudo mount -t cifs -o username=BENUTZER,password=PASSWORD,uid=UID,gid=GID,file_mode=MODE,dir_mode=MODE //SERVER-IP/FREIGABE MOUNTPUNKT }}} Beispiel: {{{#!vorlage Befehl 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 [:Rechte: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 ([:mount: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. {{{#!vorlage Experten Seit Samba 4.0 werden SID und NT-ACLs, die auf einem Windows-Client für Samba-Freigaben gesetzt werden, auf den Samba-Server übernommen und dort der betreffenden Datei bzw. Ordner zugeordnet, sind aber dort nicht direkt sichtbar. Für Windows-Clients bleiben sie dann verbindlich. Sie überdecken für diese dann evtl. anders festgelegte UNIX-Dateirechte und können nur von einem Windows-Client aus verwaltet und ggf. verändert werden. Für Linux-Clients sind sie jedoch irrelevant.}}} = 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. 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. Über die Option `vers=` kann das verwendete SMB-Protokoll explizit festgelegt werden: {{{#!vorlage Befehl sudo mount -t cifs -o vers=3.1.1,username=otto,password=geheim //192.168.1.100/Tausch /media/austausch }}} = Weitere Einzelheiten = == Zeitstempel == Sind die cifs-UNIX-Erweiterungen aktiv, dann wird beim Kopieren oder Verschieben von Ordnern und Dateien der [wikipedia: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. == SMB3-POSIX-Erweiterungen am Client aktivieren bzw. unterbinden == Im Gegensatz zu den früheren cifs-UNIX-Erweiterungen sind die SMB3-POSIX-Erweiterungen standardmäßig aktiv, wenn der Server sie anbietet. Sie müssen nicht mit der Option `-o posix` eigens aktiviert werden, lassen sich aber mit der Option `-o noposix` für die entsprechende Freigabe ablehnen. {{{#!vorlage experten Beim Einbinden mittels SMB3 führt der Client mit dem Server ein "Handshake" durch, ob dieser POSIX-Erweiterungen anbietet. Wenn ja, dann werden alle Simulationen von Dateirechten automatisch abgeschaltet. Allerdings können unerwartete Probleme auftreten, falls der Client noch nicht mit allen Features der POSIX-Erweiterungen völlig klar kommt, was bei Samba-Versionen vor 4.23 der Fall sein kann. Hier ist Vorsicht geboten und ggf. die Option `noposix` sinnvoll.}}} {{{#!vorlage Hinweis Beim Einhängen mittels [:gio mount:GVfs] werden die cifs-UNIX-Extensions bisher (2025) noch 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 SMB-Freigaben eingehängt, so kann sich dieses dadurch um bis zu 120 Sekunden verzögern. Dies ist ein altes Problem (siehe Fehlerberichte [bug:211631:] und [bug:1577885:]) Die älteren Workarounds sind aber wegen der Umstellung auf [:systemd:] nun unwirksam. Auch ein [:NetworkManager/Dispatcher: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 SMB-Freigaben vor dem Shutdown manuell auszuhängen. {{{#!vorlage Experten Das Aushängen der gemounteten Freigaben vor dem Shutdown lässt sich durch ein "Systemd Service Unit" z.B. auf folgende Weise automatisieren: 1. Man verfasst ein kurzes Skript {{{ #! /bin/sh # SMB-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''' 1. 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''' 1. Nun aktiviert man das Service Unit mit folgendem Befehl{{{#!vorlage 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 [:fstab:/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 {{{#!vorlage Befehl sudo mount -a }}} von einem Terminal aus nachträglich einbinden. Wie man dies automatisieren kann, ist bereits im Abschnitt [#sleep sleep] beschrieben. Oder man verwendet einen [:fstab/#Automount-mit-systemd: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 }}} ##== Sonstige Probleme == ## ##=== 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. ## ##=== mount error(13): Permission denied === ##Die Fehlermeldung ##{{{ ##mount error(13): Permission denied ##}}} ##kann verschiedene Ursachen haben. Häufig tritt 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 [:Rechte:UNIX-Dateirechten] und ggf. noch von den [:ACL: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#Benutzerverwaltung:]). == Trotz aktiver SMB3-POSIX-Erweiterungen werden Dateirechte nicht übertragen == Hier handelt es sich meist um eine einfache Schutzmaaßnahme: Der eingeloggte Benutzer erlangt den Besitz seiner eigenen Ordner und Dateien innerhalb der Freigabe erst dann, wenn seine Identität durch uid=UID in der Mount-Befehlszeile oder im '''fstab'''-Eintrag bestätigt wird. Da er diesen Eintrag nicht ohne [:sudo:Root-Rechte] selbst vornehmen kann, wird dadurch wirksam verhindert, dass unbefugte Benutzer von einem Client aus Änderugen am Dateisystem des Servers vornehmen können. = Links = == Verwandte Seiten == * [:Samba:]: {Übersicht} Überblick über das Themengebiet * [:Samba Client GNOME:]: Über [:GNOME:]/[:Nautilus:] und verwandte GUIs auf Freigaben zugreifen * [:Samba Client KDE:]: Über [:KDE:] auf Freigaben zugreifen * [:Samba Client/Smb4K: Smb4K]: Ein Frontend für das Einbinden von Freigabe per CIFS vfs * [: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 [:Xenial:Ubuntu 16.04 LTS]) * [:gio mount:]: Einhängen lokaler und entfernter Orte im GVfs ## * [:Gigolo:]: Ein Frontend für das Einbinden von Freigabe per GVfs * [:Autofs:]: Freigaben beim Zugriff automatisch einbinden. == Extern == * [https://wiki.samba.org/index.php/LinuxCIFS_utils CIFS for Linux] {en} * [https://linux.die.net/man/8/mount.cifs man mount.cifs]: Linux-Manpage {en} * [https://wiki.samba.org/index.php/Mounting_samba_shares_from_a_unix_client Samba-Wiki] {en} #tag: Netzwerk, Server, Samba, Freigaben, Windows, SMB, cifs, mount.cifs