SMB vs NFS: Welche Dateifreigabemethode sollten Sie zu Hause verwenden?

Wenn Ihr Heimnetzwerk Windows-PCs, Macs, Telefone, Tablets und Media-Player umfasst, ist SMB normalerweise die bessere Standardwahl. Es integriert sich natürlich in Desktop-Dateibrowser, unterstützt benutzerbasierte Anmeldungen und ist in Verbraucheranwendungen weit verbreitet.

NFS wird attraktiver, wenn die Clients hauptsächlich Linux-Server, Proxmox-Hosts oder andere Unix-ähnliche Systeme sind, die Speicher als Teil eines verwalteten Infrastruktur-Workflows mounten. Es kann effizient und vorhersehbar sein, aber nur, wenn UID/GID-Werte, Exportregeln, Mount-Verhalten und Dateibesitz richtig geplant sind.

Wählen Sie das Protokoll basierend auf dem Client, nicht auf dem Benchmark

SMB und NFS ermöglichen es beiden, Dateien zu öffnen, die auf einem NAS oder Heimserver gespeichert sind, wurden aber für unterschiedliche Ökosysteme entwickelt. SMB ist nativ für Windows und wird von macOS, Linux, mobilen Dateimanagern, Smart-TVs und Medienanwendungen weitgehend unterstützt. NFS passt natürlicher in Linux- und Unix-Mount-Arbeitsabläufe.

Diese Unterscheidung ist wichtiger als die generische Behauptung, ein Protokoll sei schneller. Ein Windows-Laptop kann über SMB eine flüssigere und schnellere Erfahrung bieten, da sein Client-Stack um SMB herum aufgebaut ist. Ein Linux-Server, der Tausende von Dateien verarbeitet, ist über NFS leichter zu verwalten, da das entfernte Verzeichnis wie ein normaler Unix-Mount funktioniert.

Beginnen Sie damit, die Geräte aufzulisten, die auf die Freigabe zugreifen werden, und was sie damit tun werden. Menschliches Dateibrowsing, Maschine-zu-Maschine-Speicherung, Medien-Streaming, Backups, Virtualisierung und Container-Daten benötigen nicht immer dasselbe Protokoll.

SMB ist normalerweise die einfachere Standardlösung für ein gemischtes Zuhause

SMB ist normalerweise die einfachste Option, wenn Benutzer Ordner manuell über den Windows-Datei-Explorer, macOS Finder, ein Telefon oder eine Media-Player-Anwendung öffnen. Benutzer können sich mit einem NAS-Benutzernamen und Passwort verbinden, ohne auf jedem Client numerische Linux-Identitäten verwalten zu müssen.

Moderne SMB-Versionen bieten auch Funktionen über die einfache Dateiübertragung hinaus, einschließlich Benutzer- und Gruppen-ACLs, Signierung, Verschlüsselung, Dateisperrung, Caching und Multichannel-Fähigkeiten. Diese Funktionen erhöhen die Komplexität, sind aber nützlich, wenn mehrere Haushaltsmitglieder unterschiedliche Zugriffsrechte benötigen.

Für gemischte Windows-, macOS- und Linux-Netzwerke kann modernes SMB 3.x viele Leistungslücken schließen und gleichzeitig eine breitere Client-Kompatibilität bieten. Das macht SMB zum praktischen Ausgangspunkt für Dokumente, Familienfotos, gemeinsame Downloads und allgemeines NAS-Browsing.

NFS passt natürlicher zu verwalteten Linux-Workflows

NFS ist oft leichter zu integrieren, wenn der Client ein Linux-Server und keine Person ist, die Ordner durchsucht. Die Freigabe kann beim Start in ein festes Verzeichnis eingebunden und von Backup-Software, Mediadiensten, Virtualisierungshosts oder anderen Systemprozessen genutzt werden.

Das funktioniert gut, wenn ein Administrator sowohl das NAS als auch die Clients verwaltet. Man kann das erlaubte Subnetz definieren, Benutzer und Gruppen anpassen, Mount-Optionen wählen und sicherstellen, dass Dienste erst starten, wenn die Netzwerkfreigabe verfügbar ist.

NFS wird weniger praktisch, wenn Windows-Laptops, mobile Anwendungen oder mehrere Haushaltsnutzer direkten Zugriff benötigen. Obwohl plattformübergreifende NFS-Clients existieren, sind Einrichtung und Identitätszuordnung meist weniger unkompliziert als die Nutzung von SMB auf diesen Geräten.

SMB und NFS verwenden unterschiedliche Zugriffsmodelle

SMB präsentiert den Zugriff normalerweise als Serverkonto. Ein Benutzer verbindet sich mit Anmeldeinformationen, und das NAS bewertet Freigabeberechtigungen, Gruppen und Dateisystem-ACLs, die mit dieser Identität verknüpft sind.

Gängige Heim-NFS-Konfigurationen funktionieren anders. Der Export ist oft auf ausgewählte Hosts oder Subnetze beschränkt, während der Dateizugriff von numerischen Unix-UID- und GID-Werten abhängt, die vom Client gesendet werden. NFSv4 kann fortschrittlichere Identitäts- und Kerberos-Konfigurationen nutzen, aber viele Heimnetzwerke verlassen sich weiterhin auf vertrauenswürdige Client-Netzwerke und numerisches Eigentum.

Der praktische Unterschied besteht darin, dass SMB üblicherweise Benutzer- und Gruppen-ACLs verwendet, während der NFS-Zugriff eng an Host-Regeln und Linux UID/GID-Eigentum gebunden ist. Kein Modell ist automatisch besser, aber jedes erzeugt unterschiedliche Probleme bei der Fehlerbehebung.

UID- und GID-Planung ist die Hauptlernkurve bei NFS

Ein Linux-Benutzername ist nur ein lesbares Label. Das Dateisystem speichert letztlich numerische Benutzer- und Gruppen-IDs. Zwei Maschinen können beide einen Benutzer namens haben, Medien, aber es sind unterschiedliche Identitäten, wenn der eine UID 1000 und der andere UID 1001 verwendet.

Deshalb kann eine NFS-Freigabe erfolgreich gemountet werden, während das Erstellen von Dateien dennoch fehlschlägt. Der Netzwerkpfad und der Export funktionieren, aber der vom Client präsentierte Benutzer stimmt nicht mit dem Besitzer, der Gruppe oder der ACL auf dem NAS überein.

Vergleichen Sie vor der Verwendung von NFS für mehrere Linux-Systeme die Ergebnisse von id username auf Client und Server. Die Art der numerischen UID- und GID-Angleichung, die für beschreibbare NFS-Freigaben erforderlich ist, ist oft der fehlende Schritt, wenn ein Benutzer ein Verzeichnis betreten, aber keine Dateien erstellen kann.

Root Squash ist kein zufälliger Berechtigungsfehler

NFS-Exporte verwenden üblicherweise Root Squashing, um zu verhindern, dass ein Root-Benutzer auf einem Client automatisch Root auf dem NAS wird. Anfragen von der entfernten UID 0 werden auf eine weniger privilegierte anonyme Identität abgebildet.

Dies kann Benutzer überraschen, die Backup-Skripte, Container oder administrative Kopierbefehle als Root ausführen. Die Freigabe wird gemountet, aber Schreibvorgänge schlagen fehl oder Dateien erscheinen unter einem anonymen Benutzer.

Deaktivieren Sie Root Squashing nicht einfach, weil es einen Workflow blockiert. Bestimmen Sie zuerst, welcher Nicht-Root-Benutzer oder welche Gruppe die Daten besitzen soll, und geben Sie dieser Identität dann die erforderlichen Zugriffsrechte. Die Verwendung von no_root_squash verzichtet auf eine wichtige Sicherheitsgrenze und sollte nicht als normaler Shortcut für Heimserver behandelt werden.

NFS ist nicht automatisch schneller als SMB

Die Leistung hängt vom Betriebssystem des Clients, der Protokollversion, der Dateigröße, der Metadaten-Arbeitslast, dem Speicherpool, Signierung oder Verschlüsselung, den Mount-Optionen, der Netzwerkverbindung und dem Anwendungsverhalten ab.

Ein einzelnes großes Video testet hauptsächlich den sequentiellen Durchsatz. Wenn beide Protokolle die Festplatte oder die Netzwerkverbindung auslasten können, sehen ihre Ergebnisse möglicherweise ähnlich aus. Ein Verzeichnis mit Tausenden von Miniaturansichten, Untertiteln, Metadatendateien und verschachtelten Ordnern belastet die Dateisuche, das Attribut-Caching und kleine Operationen stärker.

Deshalb kann ein einzelner Benchmark die Wahl für jedes Zuhause nicht entscheiden. Testen Sie mindestens vier Arbeitslasten: einen großen Lesevorgang, einen großen Schreibvorgang, ein Verzeichnis mit vielen kleinen Dateien und das normale Durchsuchen von Ordnern vom Client aus, der die Freigabe tatsächlich nutzt.

Große Mediendateien benötigen normalerweise nicht das schnellste Protokoll

Ein typischer Filmstream verbraucht weit weniger Bandbreite, als eine gesunde Gigabit-Ethernet-Verbindung bereitstellen kann. Wenn ein Mediaserver ein Video im lokalen Netzwerk nicht zuverlässig abspielen kann, liegt der Engpass möglicherweise bei WLAN, Transkodierung, Festplattenleistung oder der Kompatibilität des Clients und nicht an SMB versus NFS.

Der Unterschied wird deutlicher, wenn Plex, Jellyfin, Sonarr oder eine andere Anwendung eine große Bibliothek scannt. Der Server öffnet möglicherweise Tausende von Postern, Untertiteln, NFO-Dateien und Datenbankreferenzen, obwohl die Wiedergabe tatsächlich nur eine große Mediendatei sequenziell liest.

Aus diesem Grund funktioniert das Streaming großer Dateien über beide Protokolle gut, während sich bei kleinen Datei-Bibliotheksscans größere Unterschiede zeigen. Linux-basierte Mediaserver profitieren möglicherweise von NFS, aber Windows- und macOS-Clients sind über SMB meist leichter zu unterstützen.

SMB ist in der Regel besser für den direkten Zugriff von Media-Playern geeignet

Wenn ein Apple TV, Android-TV-Gerät, Telefon, Tablet oder Laptop direkt mit dem NAS verbunden wird, ist SMB normalerweise die einfachere Wahl. Viele Medienanwendungen können SMB-Shares mit Serveradresse, Benutzername und Passwort durchsuchen.

Die NFS-Unterstützung variiert zwischen Anwendungen und Geräten. Selbst wenn sie verfügbar ist, kann die Einrichtung von Export und Berechtigungen für Haushaltsnutzer weniger offensichtlich sein als die Eingabe gewöhnlicher SMB-Zugangsdaten.

Dies ist getrennt davon, wie der Mediaserver selbst Speicher einbindet. Ein Linux-Jellyfin-Server könnte seine Bibliothek über NFS lesen, während Familiengeräte nur über die Web- oder Streaming-Oberfläche von Jellyfin verbunden sind. Die Endgeräte benötigen keinen direkten Zugriff auf das zugrundeliegende Dateiprotokoll.

NFS ist oft eine natürliche Wahl für Proxmox-Speicher

Proxmox basiert auf Linux, daher passt NFS natürlich in Backup-, ISO-, Template- und Shared-Storage-Workflows. Ein NAS-Export kann vom Host eingebunden und als Infrastruktur-Speicher verwaltet werden, statt als Desktop-Dateifreigabe.

Das bedeutet nicht, dass jede virtuelle Maschinenfestplatte automatisch auf einem Heim-NFS-Server abgelegt werden sollte. VM-Speicher hängt von Latenz, synchronem Schreibverhalten, Netzwerkverfügbarkeit, Backup-Design und dem Verhalten des Systems bei NAS-Neustart oder -Trennung ab.

Für Container kann es auch sauberer sein, NFS auf dem Proxmox-Host einzubinden und den Speicherpfad in einen unprivilegierten Container weiterzugeben, anstatt jedem Container eine eigene Netzwerk-Mount-Konfiguration zu geben oder ihn nur zum Mounten des Shares zu privilegieren.

Docker-Speicher sollte nach Datentyp ausgewählt werden

Die Verwendung eines NAS-Pfads innerhalb von Docker macht NFS nicht automatisch zur richtigen Wahl für jeden Container. Die Arbeitslast ist wichtiger als die Container-Plattform.

Medienbibliotheken, Downloads, Importe, Exporte, Backups und andere große gemeinsame Dateien funktionieren gut über SMB oder NFS. Ein Linux-Docker-Host findet NFS oft einfacher, da Dateibesitz über vertraute UID/GID-Werte ausgedrückt wird.

Datenbanken, SQLite-Dateien, Suchindizes, Anwendungszustände und Workloads mit häufigem Sperren oder synchronen Schreibvorgängen erfordern mehr Vorsicht. Bewahren Sie diese Dateien auf lokalem Speicher auf, es sei denn, die Anwendung unterstützt explizit das ausgewählte Netzwerkdateisystem und Sie haben Neustart-, Sperr- und Fehlerverhalten getestet.

Mounten Sie die Freigabe auf dem Host, bevor Sie sie an Container weitergeben

Für viele Home-Server-Installationen ist das sauberste Modell, die NAS-Freigabe einmal auf dem Docker-Host zu mounten und dann den lokalen Pfad in die benötigten Container zu binden.

So bleiben Anmeldedaten, NFS-Export-Einstellungen, Wiederverbindungsverhalten und Startreihenfolge an einem Ort. Container sehen nur ein normales Verzeichnis, während der Host das Netzwerkdateisystem verwaltet.

Das Modell funktioniert mit NFS oder SMB. Wichtig ist, dass das Host-Mount vor dem Start des Containers verfügbar ist, der Container-UID/GID Zugriff auf die gemounteten Dateien hat und der Dienst nicht stillschweigend in ein leeres lokales Verzeichnis schreibt, wenn das NAS offline ist.

Lass nicht beide Protokolle dieselben Daten ohne Plan schreiben

Die meisten NAS-Plattformen können denselben Datensatz über SMB und NFS bereitstellen. Technisch ermöglicht das Windows-Nutzern und Linux-Anwendungen, mit denselben Dateien zu arbeiten.

Das Problem ist, dass die beiden Pfade Dateien unter unterschiedlichen Identitäten und ACL-Modellen erstellen können. Ein SMB-Upload könnte einem NAS-Konto mit detaillierter ACL gehören, während eine NFS-Anwendung als UID 1000 mit POSIX-Modusbits und anderem Umask schreibt.

Wenn beide Protokolle Zugriff benötigen, definiere einen primären Schreiber. Das andere Protokoll kann schreibgeschützt sein oder beide nutzen ein sorgfältig abgestimmtes gemeinsames Gruppen- und Vererbungsmodell. Ohne diesen Plan treten Berechtigungsabweichungen meist schrittweise auf.

Die gleichzeitige Nutzung beider Protokolle ist sinnvoll, wenn ihre Rollen getrennt bleiben

Ein gemischtes Home-Lab muss nicht ein Protokoll für alles wählen. Beide zu betreiben kann sauberer sein, als jedes Gerät durch dasselbe Zugriffsmodell zu zwingen.

Eine praktische Aufteilung ist:

• SMB für Windows- und Mac-Familienordner
• SMB für direkten Zugriff von Telefon, Tablet und TV
• NFS für Proxmox-Backups und Linux-Hosts
• NFS für das schreibgeschützte Bibliotheks-Mount eines Linux-Medienservers
• Lokaler Speicher für Anwendungsdatenbanken und sensible Laufzeitzustände

Die Protokolle sollten nach Verantwortlichkeit getrennt werden, nicht überall standardmäßig aktiviert sein. Separate Datensätze oder klare Lese-/Schreibgrenzen reduzieren Berechtigungskonflikte und erleichtern die Fehlerbehebung.

Keines der Protokolle sollte direkt dem Internet ausgesetzt werden

SMB und NFS sind für vertrauenswürdige lokale Netzwerke oder private Netzwerkpfade gedacht. Leiten Sie TCP 445 für SMB oder die NFS-Dienstports nicht vom Heimrouter ins öffentliche Internet weiter.

Für den Fernzugriff auf Dateien verbinden Sie sich zuerst über ein VPN oder eine andere authentifizierte private Zugriffsschicht mit dem Heimnetzwerk. Sobald das entfernte Gerät diesen vertrauenswürdigen Pfad nutzt, kann es denselben SMB- oder NFS-Dienst verwenden, der im LAN verfügbar ist.

Der Wechsel von SMB zu NFS macht die öffentliche Exposition nicht sicherer. Sicherheit hängt davon ab, erreichbare Clients zu begrenzen, Software aktuell zu halten, geeignete Authentifizierung zu verwenden und unnötige öffentliche Dienste zu vermeiden.

Benchmarken Sie mehr als nur die Übertragungsgeschwindigkeit

Ein fairer Heimtest sollte dasselbe NAS-Dataset, denselben Client, dieselbe Netzwerkverbindung und dieselben Dateien für beide Protokolle verwenden. Andernfalls könnte das Ergebnis unterschiedliche Speicherpfade oder Client-Geräte messen statt SMB und NFS.

Messen Sie mehr als Megabyte pro Sekunde. Testen Sie, ob das Mount nach dem Schlafmodus oder Neustart wieder verbunden wird, ob Dateinamen und Metadaten korrekt funktionieren, ob Anwendungen Dateien erstellen und löschen können und ob Berechtigungen konsistent bleiben.

Ein Protokoll, das fünf Prozent schneller ist, aber nach einem Neustart regelmäßig ausfällt, ist möglicherweise die schlechtere Wahl. Zuverlässigkeit, Client-Kompatibilität und der Zeitaufwand für die Verwaltung von Berechtigungen sind Teil der realen Leistung.

Verwenden Sie diese Entscheidungsreihenfolge

Beginnen Sie mit den Clients statt mit einer Protokollpräferenz. Listen Sie jeden Computer, jedes mobile Gerät, jeden Mediaplayer, Server, Hypervisor und jede Anwendung auf, die die Daten benötigt.

Trennen Sie dann die menschliche Nutzung vom Maschinen-zu-Maschinen-Zugriff. Haushaltsnutzer profitieren in der Regel von SMB-Konten und vertrauten Dateibrowsern. Verwaltete Linux-Dienste können von NFS-Mounts und numerischer Identitätskontrolle profitieren.

Beantworten Sie vor der Aktivierung des finalen Shares diese Fragen:

1. Durchsuchen Windows- oder macOS-Benutzer die Dateien?
2. Benötigen Telefone oder Fernseh-Apps direkten Zugriff?
3. Sind die meisten Clients verwaltete Linux-Systeme?
4. Können UID- und GID-Werte konsistent bleiben?
5. Enthält die Workload Datenbanken oder dateisperrungssensible Dateien?
6. Werden SMB und NFS beide auf dasselbe Dataset schreiben?
7. Wie soll sich das Mount verhalten, wenn das NAS nicht verfügbar ist?
8. Kann das ausgewählte Protokoll vollständig vom öffentlichen Internet ferngehalten werden?

Für die meisten Haushalte mit gemischten Geräten beginnen Sie mit SMB. Fügen Sie NFS nur für spezifische Linux-, Proxmox-, Backup- oder Container-Workloads hinzu, die davon profitieren und die Sie konsistent verwalten können.

Fazit

SMB ist normalerweise die bessere Standardwahl für Windows, macOS, Telefone, Tablets, Smart-TVs und gemeinsame Familienordner. Es bietet breite Kompatibilität und ein kontobasiertes Zugriffsmodell, das Haushaltsbenutzern leichter zu erklären ist.

NFS ist oft die bessere Wahl für Linux-Server, Proxmox-Speicher, automatisierte Backups und andere Maschine-zu-Maschine-Workflows. Seine Vorteile hängen von korrekt verwalteten UID/GID-Werten, Exporten, Mount-Optionen und Besitzrechten ab.

Sie können beide Protokolle zu Hause verwenden, aber deren Aufgaben sollten klar sein. Verwenden Sie SMB für Personen und gemischte Client-Geräte, NFS für verwaltete Linux-Infrastrukturen und vermeiden Sie, beiden Protokollen uneingeschränkten Schreibzugriff auf denselben Datensatz zu geben.

FAQ

Ist NFS immer schneller als SMB?

Nein. NFS kann bei einigen Linux-zu-Linux- und kleinen Datei-Workloads besser abschneiden, während modernes SMB unter Windows und in Netzwerken mit gemischten Clients sehr gut performen kann. Testen Sie die tatsächlichen Dateien, Clients, Speicher und Netzwerke, die Sie verwenden möchten.

Sollte ich SMB oder NFS für Plex und Jellyfin verwenden?

Beides kann funktionieren. Ein Linux-Medienserver profitiert möglicherweise von NFS bei großen Bibliotheksscans, während SMB einfacher sein kann, wenn Windows-, macOS- oder Media-Player-Anwendungen direkt auf das NAS zugreifen. Großes Video-Streaming funktioniert in der Regel mit beiden gut.

Ist NFS besser für Proxmox?

NFS ist eine gängige und natürliche Wahl für Proxmox-Backups, ISO-Speicher, Templates und gemeinsamen Speicher. VM-Festplatten und Arbeitslasten mit hoher Schreibintensität erfordern jedoch noch Tests hinsichtlich Latenz, Synchronisationsverhalten und NAS-Verfügbarkeit.

Können Docker-Container SMB-Shares verwenden?

Ja. Mounten Sie das SMB-Share auf dem Docker-Host und binden Sie den resultierenden Pfad in den Container ein. Stellen Sie sicher, dass der Containerbenutzer die Berechtigung hat, auf die gemounteten Dateien zuzugreifen, und dass das Host-Mount verfügbar ist, bevor der Container startet.

Warum zeigt NFS „Zugriff verweigert“ an, obwohl das Share gemountet ist?

Der Export- und Netzwerkpfad kann korrekt sein, während die Client-UID/GID nicht mit dem Besitzer oder der erlaubten Gruppe auf dem NAS übereinstimmt. Root-Squashing oder Export-Mapping können ebenfalls den effektiven Benutzer ändern.

Kann ich SMB und NFS im selben Ordner aktivieren?

Das ist möglich, aber gleichzeitiger Schreibzugriff kann Konflikte bei Besitzrechten, ACLs und erweiterten Attributen verursachen. Bevorzugen Sie separate Datensätze, machen Sie ein Protokoll schreibgeschützt oder erstellen Sie ein sorgfältig abgestimmtes gemeinsames Berechtigungsmodell.

Welches Protokoll ist zu Hause sicherer?

Beide können in einem vertrauenswürdigen LAN gesichert werden. SMB bietet eine einfache Benutzer-Authentifizierung sowie moderne Signierung oder Verschlüsselung. NFS sollte auf vertrauenswürdige Clients beschränkt werden, mit korrekten Exportregeln und Root-Squashing. Keines der beiden sollte direkt dem Internet ausgesetzt werden.

Welches Protokoll sollte ein Anfänger wählen?

Wählen Sie SMB, wenn das Zuhause Windows, macOS, Telefone oder TV-Anwendungen umfasst. Wählen Sie NFS, wenn die Clients hauptsächlich Linux-Systeme sind und Sie sich mit der Verwaltung von Mounts, UID/GID-Werten und Exportberechtigungen auskennen.