layout: ../../../layouts/BlogLayout.astro title: “NFS vs SMB: Performance, Sicherheit & wann du was nutzt” description: “Deep-Dive in NFS- und SMB-Protokolle. Performance-Benchmarks, Sicherheitsfeatures, Tuning-Tipps und Herausforderungen bei Cross-Protocol-Migration.” date: “2026-02-20” category: “Best Practices” readingTime: “12 min” slug: “nfs-vs-smb-comparison” locale: “de” tags: [“nfs”, “smb”, “cifs”, “protocols”, “performance”]

Die Wahl zwischen NFS und SMB ist längst keine reine Linux-vs-Windows-Entscheidung mehr. Moderne Netzwerke sind Mixed-Protocol-Umgebungen, in denen beide Protokolle koexistieren. Dieser Guide behandelt Protokoll-Interna, reale Performance, Sicherheits-Tradeoffs und was passiert, wenn du Daten zwischen ihnen migrieren musst.

Protokoll-Überblick

NFS (Network File System)

NFS wurde 1984 von Sun Microsystems entwickelt. Inzwischen bei Version 4.2 angekommen, ist es der Standard für Linux- und Unix-Dateifreigaben.

VersionJahrWichtige Features
NFSv31995Stateless, UDP/TCP, AUTH_SYS
NFSv42003Stateful, nur TCP, Kerberos, ACLs
NFSv4.12010pNFS (Parallel NFS), Sessions, Trunking
NFSv4.22016Server-side Copy, Sparse Files, Space Reservation

SMB (Server Message Block)

SMB wurde 1983 von IBM entwickelt und danach maßgeblich von Microsoft weiterentwickelt. Der Name CIFS (Common Internet File System) bezieht sich auf SMB 1.0 — moderne Versionen heißen einfach “SMB”.

VersionJahrWichtige Features
SMB 1.0 / CIFS1996Microsoft formalisierte IBMs SMB von 1983; Legacy, unsicher — unbedingt deaktivieren
SMB 2.02006Weniger Round-Trips, größere Reads/Writes
SMB 2.12010Leasing, Large MTU Support
SMB 3.02012Multichannel, Verschlüsselung, RDMA
SMB 3.1.12015Pre-Auth Integrity, AES-128-GCM

SMB 1.0 überall deaktivieren

SMB 1.0 (CIFS) hat kritische Sicherheitslücken — es war der Angriffsvektor für WannaCry und NotPetya. Wenn du irgendwo noch SMB 1.0 aktiviert hast, deaktiviere es heute noch. Alle modernen Clients unterstützen SMB 2.0+.

Performance-Vergleich

Sequentielle Übertragung großer Dateien

Bei großen Dateitransfers (100 MB+ Dateien) in einem 10-Gbps-Netzwerk liefern beide Protokolle ähnlichen Durchsatz, wenn sie richtig konfiguriert sind:

KonfigurationNFSv4.2SMB 3.0
Standardeinstellungen~700 MB/s~500 MB/s
Getuned (siehe unten)~1.000 MB/s~900 MB/s
Multichannel (2x 10G)~1.000 MB/s*~1.800 MB/s

*NFSv4.1+ unterstützt Trunking, aber die Verbreitung ist im Vergleich zu SMB Multichannel begrenzt.

Kleine Dateien (Metadata-lastig)

Hier unterscheiden sich die Protokolle deutlich. NFS-Operationen wie stat(), readdir() und open() werden fast 1:1 auf das Netzwerkprotokoll abgebildet. SMB braucht für die gleichen Operationen mehr Round-Trips.

OperationNFSv4SMB 3.0
10.000 leere Dateien erstellen~2 Sekunden~5 Sekunden
100.000 Dateien stat’en~4 Sekunden~8 Sekunden
readdir mit 50.000 Einträgen~1 Sekunde~3 Sekunden
Zufällige 4K-Reads (IOPS)~50.000~35.000

Diese Zahlen variieren stark

Die Performance hängt von Server-Hardware, Netzwerk-Latenz, Client-Caching und Workload-Mustern ab. Benchmarke immer mit deinem Workload auf deiner Infrastruktur, bevor du Architektur-Entscheidungen triffst.

Warum NFS oft schneller ist

  1. Weniger Round-Trips — NFS Compound Operations (v4) bündeln mehrere Requests
  2. Einfachere Metadaten — keine Windows Security Descriptors bei jeder Operation
  3. Aggressives Caching — Delegations in NFSv4 erlauben erweitertes Client-Caching
  4. Weniger Protocol Overhead — NFS-Header sind kleiner als SMB-Header

Warum SMB gewinnen kann

  1. Multichannel — SMB 3.0 bündelt mehrere NICs nativ (Killer-Feature für Durchsatz)
  2. Leasing/Oplocks — ausgefeiltes Client-Caching für leseintensive Workloads
  3. RDMA — SMB Direct umgeht die CPU beim Storage-Networking (Azure-Klasse)
  4. Besser auf Windows-Clients — Kernel-integriert, kein Userspace-Mount

Performance-Tuning

NFS-Tuning

# Mount-Optionen für Performance
mount -t nfs4 server:/export /mnt -o \
  rsize=1048576,wsize=1048576,\    # Max Read/Write-Größe (1MB)
  nconnect=8,\                      # Mehrere TCP-Verbindungen (Linux 5.3+)
  hard,\                             # Hard Mount (unbegrenzte Wiederholungen)
  noatime                           # Keine Access-Time-Updates
# Server-seitig: NFS-Threads erhöhen
echo 64 > /proc/fs/nfsd/threads     # Standard ist oft 8

Wichtige NFS-Tuning-Stellschrauben:

Für die komplette NFS-Server-Einrichtung siehe unseren NFS Exports Configuration Guide.

SMB-Tuning

# SMB Multichannel aktivieren (normalerweise standardmäßig an)
Set-SmbServerConfiguration -EnableMultiChannel $true

# Große MTU konfigurieren
Set-SmbServerConfiguration -MaxChannelPerSession 32

# Linux cifs Mount-Optionen
mount -t cifs //server/share /mnt -o \
  vers=3.0,\
  multichannel,max_channels=8,\
  rsize=4194304,wsize=4194304,\
  cache=strict

Wichtige SMB-Tuning-Stellschrauben:

Sicherheitsvergleich

FeatureNFSv3NFSv4SMB 3.0+
AuthentifizierungAUTH_SYS (UID/GID)Kerberos (RPCSEC_GSS)NTLM / Kerberos
VerschlüsselungKeinekrb5p (Kerberos Privacy)AES-128-GCM, AES-256-GCM
IntegritätsprüfungKeinekrb5i (Kerberos Integrity)Signing (AES-CMAC)
ZugriffskontrollePOSIX Mode Bits + IP-basiertNFSv4 ACLsNTFS ACLs / DACLs
TransportsicherheitKeineRPCSEC_GSSTLS 1.3 (SMB 3.1.1)

NFS-Sicherheitsaspekte

SMB-Sicherheitsaspekte

Sicherheitsempfehlung

Für sensible Daten: nutze NFSv4 mit Kerberos (krb5p) oder SMB 3.0+ mit Verschlüsselung. Verwende niemals NFSv3 über nicht vertrauenswürdige Netzwerke. Lasse niemals SMB 1.0 aktiviert.

Herausforderungen bei Cross-Protocol-Migration

Wenn du zwischen NFS und SMB migrierst (z. B. von Synology NFS zu einem Windows-Dateiserver), treten mehrere Metadaten-Übersetzungsprobleme auf:

1. Unterschiedliche Berechtigungsmodelle

AspektNFS/POSIXSMB/NTFS
IdentitätUID/GID (numerisch)SID (Security Identifier)
Berechtigungenrwx (9-Bit) + ACLsDACL-Einträge (Allow/Deny)
VererbungSetgid auf VerzeichnisseExplizite Vererbungsflags
Standard-DenyNicht unterstütztACE Deny-Einträge

Was kaputtgeht: POSIX chmod 750 lässt sich nicht sauber auf eine NTFS-ACL abbilden. Gruppenmitgliedschaft hängt vom Identitätssystem ab. Du musst ein UID-zu-SID-Mapping planen oder nach der Migration neu berechtigen.

2. Dateinamen-Encoding

3. Timestamp-Genauigkeit

syncopio handhabt Cross-Protocol-Migrationen

syncopio spricht sowohl NFS als auch SMB nativ. Es übernimmt die Metadaten-Übersetzung, Timestamp-Normalisierung und Dateinamen-Validierung — und meldet Probleme, bevor sie zu Transfer-Fehlern führen. Mehr über Multi-Protocol-Support erfahren.

Wann du welches Protokoll nutzen solltest

NFS verwenden, wenn:

SMB verwenden, wenn:

Beide verwenden, wenn:

Migration zwischen NFS und SMB

Wenn du Daten zwischen Protokollen migrierst:

  1. Berechtigungen zuerst inventarisieren — verstehe, welches ACL-Modell jede Seite nutzt
  2. Identitäts-Mapping planen — wie werden UIDs in SIDs übersetzt (oder umgekehrt)?
  3. Dateinamen prüfen — vor dem Transfer nach illegalen Zeichen scannen
  4. Timestamps normalisieren — auf die gröbere Genauigkeit kürzen für den Vergleich
  5. Nach der Migration verifizieren — Checksummen lügen nicht, Metadaten-Vergleiche schon

Für eine vollständige Migrationsmethodik siehe unseren Data Migration Complete Guide.

Weiterführende Lektüre