SMB-Shares unter Linux und Windows: Die Fallstricke die niemand erwähnt

SMB-Dateifreigaben zwischen Linux und Windows klingen simpel: Samba installieren, eine Freigabe konfigurieren, fertig. In der Praxis scheitert es an überraschenden Stellen — deutschen Windows-Locale, unsichtbaren Berechtigungsproblemen oder einem Credential-Cache, der veraltete Zugangsdaten hartnäckig festhält.

Samba verstehen: Was es ist und was nicht

Samba ist eine freie Implementierung des SMB/CIFS-Protokolls für Unix-Systeme. Es ermöglicht Linux-Servern, als Windows-Dateiserver zu agieren — inklusive Active-Directory-Integration, Druckerfreigaben und Netlogon-Diensten. Für die meisten Heimanwender und kleine Büros reicht die einfache Standalone-Konfiguration ohne AD.

SMB existiert in mehreren Versionen. SMB1 ist tot — es war die Grundlage für WannaCry und sollte auf keinem Produktivsystem mehr laufen. SMB2 (Windows Vista+) und SMB3 (Windows 8+) sind die aktuellen Standards. Samba unterstützt alle, aber SMB1 sollte explizit deaktiviert werden:

[global]
min protocol = SMB2

Die smb.conf Grundstruktur

Eine funktionale, sichere Basis-Konfiguration:

[global]
   workgroup = WORKGROUP
   server string = Samba Server
   netbios name = FILESERVER
   security = user
   map to guest = bad user
   dns proxy = no
   min protocol = SMB2
   server min protocol = SMB2
   # Logging
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file

[daten]
   comment = Gemeinsame Daten
   path = /srv/samba/daten
   browseable = yes
   read only = no
   guest ok = no
   valid users = @smb-users
   create mask = 0664
   directory mask = 0775
   force group = smb-users

Das deutschen-Locale-Problem: Jeder statt Everyone

Wer auf einem deutschen Windows-System SMB-Freigaben einrichtet oder Berechtigungen über die GUI vergibt, stößt auf eine versteckte Falle: Die Windows-interne Gruppe "Everyone" heißt in der deutschen Locale "Jeder". Das ist keine Anzeige — der interne Name der Gruppe ist tatsächlich lokalisiert.

Das bedeutet: Wenn man in der deutschen Windows-GUI Berechtigungen für "Jeder" setzt und diese dann auf einem Samba-Server überprüft oder via Kommandozeile konfiguriert, muss man den deutschen Begriff verwenden. Ein häufiger Fehler beim Einrichten von Freigaben via net use oder beim Debuggen via smbclient:

# Auf deutschem Windows: Freigabe verbinden
net use Z: \server\daten /persistent:yes

# Berechtigungen prüfen (deutsche Locale)
icacls "\server\daten"
# Ausgabe zeigt: JEDER:(OI)(CI)(RX)

In Samba-Konfigurationen selbst spielt das keine Rolle — dort arbeitet man mit Unix-Benutzern und -Gruppen. Aber bei der Fehlersuche ist es wichtig zu wissen, warum "Everyone" in der Fehlermeldung nicht auftaucht, sondern "Jeder".

Berechtigungsmodell: Unix vs. Windows ACLs

Hier liegt eine der fundamentalsten Quellen für Verwirrung. Linux hat ein einfaches Berechtigungsmodell (Owner, Group, Others × Read/Write/Execute). Windows hat ACLs (Access Control Lists) mit feingranularen Berechtigungen pro Benutzer/Gruppe.

Samba kann beides — aber in der Standardkonfiguration werden Windows-ACLs auf Unix-Berechtigungen gemappt, was zu Verlusten führt. Wer volle Windows-ACL-Unterstützung braucht, muss Extended Attributes aktivieren:

[global]
   vfs objects = acl_xattr
   map acl inherit = yes
   store dos attributes = yes

[freigabe]
   path = /srv/samba/freigabe
   acl_xattr:ignore system acls = yes

Das Dateisystem muss dann mit ACL-Unterstützung gemountet sein:

# /etc/fstab Eintrag
/dev/sdb1  /srv/samba  ext4  defaults,acl,user_xattr  0  2

Samba-Benutzer vs. Unix-Benutzer

Samba hat eine eigene Passwort-Datenbank, getrennt vom Unix-Shadow-System. Ein Unix-Benutzer muss explizit als Samba-Benutzer angelegt werden:

# Unix-Benutzer anlegen (ohne Shell, kein Login)
sudo useradd -M -s /usr/sbin/nologin -G smb-users sambauser

# Samba-Passwort setzen (separat vom Unix-Passwort!)
sudo smbpasswd -a sambauser

# Benutzer aktivieren
sudo smbpasswd -e sambauser

# Benutzer auflisten
sudo pdbedit -L

Viele Admins vergessen, dass das Ändern des Unix-Passworts das Samba-Passwort nicht ändert und umgekehrt — sie sind vollständig getrennt.

Der Credential-Cache unter Windows

Windows cached SMB-Credentials aggressiv. Wenn man das Passwort eines Samba-Benutzers ändert, merkt Windows das oft nicht — und versucht weiter mit dem alten Passwort zu verbinden, was zu kryptischen Zugriffsfehlern führt.

# Windows: Alle gecachten Credentials löschen
# Über Systemsteuerung → Anmeldeinformationsverwaltung
# oder via Kommandozeile:
cmdkey /list                     # Alle gespeicherten Credentials anzeigen
cmdkey /delete:SERVERNAME        # Spezifische löschen

# Netzlaufwerk trennen und neu verbinden
net use Z: /delete
net use Z: \serverreigabe /user:sambauser

Debugging: Die wichtigsten Tools

# Konfiguration testen
testparm

# Verbindung vom Linux-Client aus testen
smbclient -L //server -U sambauser
smbclient //server/freigabe -U sambauser

# Namensauflösung testen
nmblookup SERVERNAME

# Logs in Echtzeit
tail -f /var/log/samba/log.smbd

# Verbundene Sessions anzeigen
smbstatus

Performance-Tuning

Samba ist in der Standardkonfiguration nicht auf Performance optimiert. Für schnelle Netzwerke (Gigabit/10-Gigabit) helfen folgende Einstellungen:

[global]
   # Socket-Optionen für besseren Durchsatz
   socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072
   read raw = yes
   write raw = yes
   # Async IO
   aio read size = 1
   aio write size = 1
   # SMB3 Multichannel (mehrere Netzwerkpfade nutzen)
   server multi channel support = yes

Fazit

Samba-Konfiguration hat viele versteckte Tücken: das Berechtigungsmodell-Mismatch zwischen Unix und Windows, die getrennte Credential-Datenbank, aggressive Windows-Credential-Caches und sprachspezifische Gruppennamen. Wer diese Fallstricke kennt, löst die meisten SMB-Probleme in Minuten statt Stunden. Die wichtigste Regel: SMB1 deaktivieren, testparm nach jeder Änderung, und bei Berechtigungsproblemen immer zuerst den Windows-Credential-Cache leeren.

Samba als Active Directory Domain Controller

Für größere Umgebungen kann Samba nicht nur als einfacher Fileserver, sondern als vollständiger Active Directory Domain Controller betrieben werden. Das ist für kleine Unternehmen oder Heimlabs interessant, die Windows-Domänen-Authentifizierung ohne Microsoft-Server wollen.

# Samba AD DC provisionieren
samba-tool domain provision   --use-rfc2307   --realm=EXAMPLE.LOCAL   --domain=EXAMPLE   --adminpass='Sicheres!Passwort1'

# DNS-Backend (Samba intern oder BIND9)
--dns-backend=SAMBA_INTERNAL

# Nach Provisioning
systemctl start samba-ad-dc
systemctl enable samba-ad-dc

# Domain prüfen
samba-tool domain level show

Als AD DC übernimmt Samba: LDAP für Verzeichnisdienste, Kerberos für Authentifizierung, DNS für die Domänenauflösung und SMB/CIFS für Dateifreigaben. Windows-Clients können sich dann zur Domäne joinen wie bei einem echten Windows-Server.

MacOS und SMB: Die Apple-Besonderheiten

MacOS unterstützt SMB nativ, hat aber einige Eigenheiten die zu Problemen führen können:

# smb.conf Optimierungen für MacOS-Clients
[global]
   # MacOS bevorzugt diese Settings
   vfs objects = catia fruit streams_xattr
   fruit:metadata = stream
   fruit:model = MacSamba
   fruit:posix_rename = yes
   fruit:veto_appledouble = no
   fruit:wipe_intentionally_left_blank_rfork = yes
   fruit:delete_empty_adfiles = yes

[freigabe]
   path = /srv/samba/daten
   fruit:time machine = yes    # Für Time-Machine-Backups

Das fruit VFS-Modul implementiert das AFP-Protokoll über SMB — für MacOS-Clients transparent, ermöglicht aber korrekte Handhabung von MacOS-spezifischen Metadaten und Time-Machine-Backups.

Recycle Bin: Gelöschte Dateien wiederherstellen

Ein häufiger Wunsch in Büroumgebungen: Einen "Papierkorb" für SMB-Shares. Samba unterstützt das über das recycle-VFS-Modul:

[dokumente]
   path = /srv/samba/dokumente
   vfs objects = recycle
   recycle:repository = .recycle
   recycle:keeptree = yes
   recycle:versions = yes
   recycle:touch = yes
   recycle:directory_mode = 0777
   recycle:exclude = *.tmp *.temp ~$*
   recycle:exclude_dir = .git .svn tmp

Gelöschte Dateien landen im versteckten Ordner .recycle innerhalb der Freigabe statt sofort gelöscht zu werden. Ein Cron-Job räumt den Papierkorb regelmäßig auf:

# Cron: Dateien älter als 30 Tage aus Papierkorb löschen
0 2 * * * find /srv/samba/dokumente/.recycle -mtime +30 -delete

Performance-Analyse mit smbstatus und iotop

# Aktive Verbindungen und offene Dateien anzeigen
smbstatus --shares
smbstatus --processes
smbstatus --locks

# Durchsatz messen (vom Windows-Client)
# Via PowerShell:
$bytes = (Get-Item \server\share	estfile.bin).Length
$time = Measure-Command { Copy-Item \server\share	estfile.bin C:	emp	est.bin }
$throughput = $bytes / $time.TotalSeconds / 1MB
Write-Host "$throughput MB/s"

Sicherheitshärtung: Signing und Encryption

SMB-Signing verhindert Man-in-the-Middle-Angriffe auf SMB-Verbindungen. SMB-Encryption (ab SMB3) verschlüsselt den Datentransfer end-to-end.

[global]
   # SMB-Signing erzwingen
   server signing = mandatory
   client signing = mandatory

   # SMB3-Encryption für sensible Shares
   smb encrypt = required

   # Nur moderne SMB-Versionen
   min protocol = SMB2
   max protocol = SMB3

Wichtig: server signing = mandatory kann die Performance um 10–20% reduzieren, da jedes Paket signiert werden muss. Für Büroumgebungen mit nicht-sensiblen Daten ist auto (Signing wenn der Client es unterstützt) oft der bessere Kompromiss.

Winbind: Windows-Domain-Benutzer auf Linux

Für Umgebungen die sowohl Windows-Domain-Benutzer als auch lokale Linux-Benutzer auf Samba-Shares zulassen wollen, ist Winbind die Lösung. Winbind übersetzt Windows-Domain-Identitäten in Unix-UIDs/GIDs:

# /etc/samba/smb.conf — Winbind-Konfiguration
[global]
   security = ADS
   realm = EXAMPLE.LOCAL
   workgroup = EXAMPLE
   winbind use default domain = yes
   winbind enum users = yes
   winbind enum groups = yes
   template homedir = /home/%U
   template shell = /bin/bash

# Domain beitreten
net ads join -U Administrator

# Winbind starten
systemctl enable --now winbind

# Domain-Benutzer testen
wbinfo -u    # Alle Domain-Benutzer
id "EXAMPLE\john"  # UID/GID eines Domain-Benutzers

Samba mit systemd-Hardening

Samba-Dienste lassen sich unter systemd mit Sandboxing-Optionen absichern. Obwohl Samba keine direkte systemd-Override-Unterstützung für alle Optionen hat, lässt sich die Service-Unit anpassen:

# /etc/systemd/system/smbd.service.d/override.conf
[Service]
# Kein schreibender Zugriff auf /etc und andere kritische Verzeichnisse
ReadOnlyPaths=/etc
# Private temporäre Verzeichnisse
PrivateTmp=yes
# Kein Zugriff auf /proc anderer Prozesse
ProtectProc=invisible
# System-Calls einschränken
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

Automatisches Einhängen auf Windows-Clients via GPO

In Unternehmensumgebungen mit Active Directory können SMB-Shares automatisch per Group Policy für alle Domain-Computer eingebunden werden — ohne manuelle Konfiguration auf jedem Client:

# Gruppenrichtlinie: User Configuration
# → Preferences → Windows Settings → Drive Maps
# → New → Mapped Drive
# Location: \serverreigabe
# Drive Letter: Z
# Action: Create (oder Update für bestehende)
# Reconnect: Ja

# Für Samba-Shares: Kerberos-Authentifizierung über AD nutzen
# Keine Passwort-Prompts, nahtlose Integration

Nextcloud vs. SMB: Wann welches?

Eine häufige Frage im Selbsthoster-Kontext: Soll ich SMB/Samba oder Nextcloud für die Dateiablage nutzen? Die Antwort hängt vom Anwendungsfall ab. SMB ist ein Protokoll für lokales Netzwerk-Dateifreigaben — es glänzt bei großen Dateien, direktem Dateisystem-Zugriff und Integration in Windows-Explorer. Nextcloud ist eine Webanwendung mit eigenem Protokoll, die zusätzlich Kalender, Kontakte, Kollaboration und Zugriff von außen (ohne VPN) bietet.

Sinnvolle Kombination: SMB für interne Dateiablage (Videos, Backups, Arbeitsordner), Nextcloud für den selektiven Außenzugriff und Synchronisation mit Smartphones. Nextcloud kann SMB-Shares als externen Speicher einbinden — so hat man einen Browser-/App-Zugang zu SMB-Daten ohne die SMB-Ports ins Internet zu öffnen.

# Nextcloud: SMB-Share als externen Speicher einbinden
# In der Nextcloud Admin-UI:
# Settings → External Storage → Add Storage
# Backend: SMB / CIFS
# Server: 192.168.1.10
# Share: /dokumente
# Username/Password: Samba-Credentials

Samba Audit-Logging

In regulierten Umgebungen (oder wenn man schlicht wissen will wer welche Dateien zugreift) bietet Samba detailliertes Audit-Logging über das full_audit-VFS-Modul:

[dokumente]
   path = /srv/samba/dokumente
   vfs objects = full_audit
   full_audit:prefix = %u|%I|%m
   full_audit:success = open read write mkdir rename unlink rmdir
   full_audit:failure = open
   full_audit:facility = local5
   full_audit:priority = NOTICE

Die Logs gehen an syslog (Facility local5) und können von dort in Graylog oder Elasticsearch aggregiert werden. Das gibt einen vollständigen Audit-Trail: Wer hat wann welche Datei geöffnet, geändert oder gelöscht.

Docker mit Samba: NAS-ähnliche Konfiguration

Wer Samba containerisiert betreiben will (z.B. auf einem Proxmox-LXC-Container mit Docker), sollte auf die Netzwerkkonfiguration achten. Samba nutzt NetBIOS für die Namensauflösung im LAN — das funktioniert in Docker-Bridge-Netzwerken nicht ohne Anpassungen:

# docker-compose.yml für Samba
services:
  samba:
    image: dperson/samba
    network_mode: host  # host-Netzwerk für NetBIOS-Broadcasts
    environment:
      - USERID=1000
      - GROUPID=1000
    volumes:
      - /srv/daten:/daten
    command: >
      -u "sambauser;passwort"
      -s "daten;/daten;yes;no;no;sambauser"
      -S  # Keine Drucker

network_mode: host ist bei Samba wichtig: Ohne Host-Netzwerk sind NetBIOS-Name-Broadcasts nicht möglich, was dazu führt, dass der Server im Windows-Explorer unter "Netzwerk" nicht sichtbar ist. Direkte IP-Verbindungen funktionieren aber auch ohne Host-Netzwerk.

Abschließende Empfehlungen

SMB und Samba sind trotz der beschriebenen Fallstricke ausgereifte, zuverlässige Technologien die ihren Job gut machen. Die meisten Probleme entstehen nicht aus fundamentalen Schwächen des Protokolls, sondern aus unvollständiger Konfiguration oder mangelndem Verständnis der Unterschiede zwischen Unix- und Windows-Sicherheitsmodellen.

Eine regelmäßige Überprüfung der Samba-Konfiguration mit testparm -v (das auch alle Default-Werte anzeigt) und das Lesen der Samba-Release-Notes bei Major-Updates schützt vor überraschenden Verhaltensänderungen. Das Samba-Team ist aktiv und gut dokumentiert — die offizielle Dokumentation unter samba.org ist ausführlicher als die meisten Drittanbieter-Guides.

Wer SMB-Shares in einem Heimnetz oder kleinen Büro betreibt, sollte zumindest SMB1 deaktivieren, SMB-Signing aktivieren und die Samba-Instanz regelmäßig aktualisieren. Das sind die drei Maßnahmen mit dem besten Verhältnis aus Aufwand und Sicherheitsgewinn.

SMB ist nach jahrzehntelanger Entwicklung ein stabiles, gut verstandenes Protokoll. Die Fallstricke die in diesem Artikel beschrieben wurden sind bekannt und lösbar — sie setzen nur voraus, dass man sie kennt. Wer Samba korrekt konfiguriert (SMB1 aus, Signing an, korrektes Berechtigungsmodell, Credential-Cache im Griff) betreibt einen zuverlässigen Dateiserver der Windows und Linux gleichermaßen gut bedient.

Samba-Konfiguration ist einer jener Bereiche der IT, wo Dokumentation lesen und Logs analysieren mehr bringt als Trial-and-Error. Die offizielle Samba-Dokumentation unter samba.org ist umfassend, und testparm -v zeigt jeden aktiven Parameter — ein unverzichtbares Debugging-Werkzeug.