SMB versus NFS: Welke bestandsdeelmethode moet je thuis gebruiken?

Als je thuisnetwerk Windows-pc's, Macs, telefoons, tablets en mediaplayers bevat, is SMB meestal de betere standaard. Het integreert natuurlijk met desktop-bestandsverkenners, ondersteunt gebruikersgebaseerde aanmeldingen en is breed beschikbaar in consumentenapplicaties.

NFS wordt aantrekkelijker wanneer de clients voornamelijk Linux-servers, Proxmox-hosts of andere Unix-achtige systemen zijn die opslag mounten als onderdeel van een beheerde infrastructuurworkflow. Het kan efficiënt en voorspelbaar zijn, maar alleen wanneer UID/GID-waarden, exportregels, mount-gedrag en bestands-eigendom correct zijn gepland.

Kies het protocol op basis van de client, niet op basis van de benchmark

SMB en NFS laten beide apparaten bestanden openen die op een NAS of thuisserver zijn opgeslagen, maar ze zijn ontworpen voor verschillende ecosystemen. SMB is native voor Windows en wordt breed ondersteund door macOS, Linux, mobiele bestandsbeheerders, smart-tv's en media-applicaties. NFS past natuurlijker in Linux- en Unix-mount-workflows.

Dat onderscheid is belangrijker dan de algemene bewering dat het ene protocol sneller is. Een Windows-laptop kan een soepelere en snellere ervaring hebben via SMB omdat de clientstack rond SMB is gebouwd. Een Linux-server die duizenden bestanden verwerkt, is makkelijker te beheren via NFS omdat de externe directory zich gedraagt als een normale Unix-mount.

Begin met het opsommen van de apparaten die toegang krijgen tot de share en wat ze ermee gaan doen. Menselijke bestandsverkenning, machine-naar-machine opslag, mediastreaming, back-ups, virtualisatie en containerdata hebben niet altijd hetzelfde protocol nodig.

SMB is meestal de gemakkelijkere standaard voor een gemengd thuisnetwerk

SMB is normaal gesproken de eenvoudigste optie wanneer mensen handmatig mappen openen vanuit Windows Verkenner, macOS Finder, een telefoon of een mediaplayer-applicatie. Gebruikers kunnen verbinding maken met een NAS-gebruikersnaam en wachtwoord zonder dat ze numerieke Linux-identiteiten op elke client hoeven te beheren.

Moderne SMB-versies bieden ook functies die verder gaan dan alleen basisbestandoverdracht, zoals gebruikers- en groeps-ACL's, ondertekening, encryptie, bestandsvergrendeling, caching en multichannel-mogelijkheden. Deze functies voegen complexiteit toe, maar zijn nuttig wanneer meerdere gezinsleden verschillende toegangsrechten nodig hebben.

Voor gemengde Windows-, macOS- en Linux-netwerken kan moderne SMB 3.x veel van het prestatieverschil verkleinen terwijl het bredere clientcompatibiliteit behoudt. Dat maakt SMB het praktische startpunt voor documenten, familiefoto's, gedeelde downloads en algemeen NAS-bladeren.

NFS past natuurlijker in beheerde Linux-workflows

NFS is vaak makkelijker te integreren wanneer de client een Linux-server is in plaats van een persoon die door mappen bladert. De share kan tijdens het opstarten in een vaste map worden gemount en gebruikt worden door back-upsoftware, mediaservices, virtualisatiehosts of andere systeemprocessen.

Dit werkt goed wanneer één beheerder zowel de NAS als de clients beheert. Je kunt het toegestane subnet definiëren, gebruikers en groepen afstemmen, mountopties kiezen en ervoor zorgen dat services pas starten nadat het netwerkshare beschikbaar is.

NFS wordt minder handig wanneer Windows-laptops, mobiele applicaties of meerdere huishoudelijke gebruikers directe toegang nodig hebben. Hoewel er cross-platform NFS-clients bestaan, zijn installatie en identiteitsmapping meestal minder eenvoudig dan het gebruik van SMB op die apparaten.

SMB en NFS gebruiken verschillende toegangsmodellen

SMB presenteert toegang meestal als een serveraccount. Een gebruiker maakt verbinding met referenties, en de NAS evalueert share-permissies, groepen en bestandssysteem-ACL's die aan die identiteit zijn gekoppeld.

Veelvoorkomende thuis-NFS-configuraties werken anders. De export is vaak beperkt tot geselecteerde hosts of subnets, terwijl bestands toegang afhankelijk is van numerieke Unix UID- en GID-waarden die door de client worden verzonden. NFSv4 kan geavanceerdere identiteits- en Kerberos-configuraties gebruiken, maar veel thuisopstellingen blijven vertrouwen op vertrouwde clientnetwerken en numeriek eigendom.

Het praktische verschil is dat SMB meestal gebruikers- en groeps-ACL's gebruikt, terwijl NFS-toegang nauw verbonden is met hostregels en Linux UID/GID-eigendom. Geen van beide modellen is automatisch beter, maar elk veroorzaakt verschillende problemen bij het oplossen van problemen.

UID- en GID-planning is de belangrijkste leercurve van NFS

Een Linux-gebruikersnaam is slechts een leesbaar label. Het bestandssysteem registreert uiteindelijk numerieke gebruikers- en groeps-ID's. Twee machines kunnen allebei een gebruiker met de naam media, maar het zijn verschillende identiteiten als de ene UID 1000 gebruikt en de andere UID 1001.

Dit is waarom een NFS-share succesvol kan worden gemount terwijl het aanmaken van bestanden nog steeds mislukt. Het netwerkpad en de export werken, maar de gebruiker die door de client wordt gepresenteerd, komt niet overeen met de eigenaar, groep of ACL op de NAS.

Vergelijk voordat je NFS gebruikt voor meerdere Linux-systemen de resultaten van id gebruikersnaam op de client en server. Het soort numerieke UID- en GID-afstemming dat nodig is voor schrijfbare NFS-shares is vaak de ontbrekende stap wanneer een gebruiker een map kan betreden maar geen bestanden kan aanmaken.

Root Squash is geen willekeurige permissiefout

NFS-exports gebruiken vaak root squashing om te voorkomen dat een root-gebruiker op een clientmachine automatisch root wordt op de NAS. Verzoeken van remote UID 0 worden gemapt naar een minder bevoegde anonieme identiteit.

Dit kan gebruikers verrassen die back-up scripts, containers of administratieve kopieeropdrachten als root uitvoeren. De share wordt gemount, maar schrijven mislukt of bestanden verschijnen onder een anonieme gebruiker.

Schakel root squashing niet uit alleen omdat het één workflow blokkeert. Bepaal eerst welke niet-root gebruiker of groep de data moet bezitten en geef die identiteit de vereiste toegang. Gebruik no_root_squash geeft een belangrijke beveiligingsgrens op en mag niet worden behandeld als een normale snelkoppeling voor thuisservers.

NFS is niet automatisch sneller dan SMB

De prestaties hangen af van het client-besturingssysteem, protocolversie, bestandsgrootte, metadata workload, opslagpool, ondertekening of encryptie, mountopties, netwerkverbinding en applicatiegedrag.

Een enkele grote video test voornamelijk de sequentiële doorvoer. Als beide protocollen de schijf of netwerkverbinding kunnen verzadigen, kunnen hun resultaten vergelijkbaar lijken. Een map met duizenden miniaturen, ondertitels, metadata-bestanden en geneste mappen legt meer druk op bestandsopzoeking, attribuutcaching en kleine bewerkingen.

Daarom kan één benchmark niet voor elk huishouden de keuze bepalen. Test minstens vier workloads: één grote leesbewerking, één grote schrijfbewerking, een map met veel kleine bestanden en normaal map bladeren vanaf de client die de share daadwerkelijk zal gebruiken.

Grote mediabestanden hebben meestal niet het snelste protocol nodig

Een typische filmstream verbruikt veel minder bandbreedte dan een gezonde Gigabit Ethernet-verbinding kan leveren. Als een mediaserver een video niet betrouwbaar kan afspelen via een lokaal netwerk, kan de bottleneck Wi-Fi, transcoding, schijfprestaties of clientcompatibiliteit zijn in plaats van SMB versus NFS.

Het verschil wordt duidelijker wanneer Plex, Jellyfin, Sonarr of een andere applicatie een grote bibliotheek scant. De server kan duizenden posters, ondertitels, NFO-bestanden en databaseverwijzingen openen, ook al leest de daadwerkelijke weergave één groot mediabestand achter elkaar.

Om deze reden kan streaming van grote bestanden goed werken via beide protocollen, terwijl scans van kleine bestanden grotere verschillen laten zien. Linux-gebaseerde mediaservers kunnen profiteren van NFS, maar Windows- en macOS-clients zijn doorgaans gemakkelijker te ondersteunen via SMB.

SMB is meestal beter voor directe toegang tot mediaplayers

Als een Apple TV, Android TV-apparaat, telefoon, tablet of laptop rechtstreeks verbinding maakt met de NAS, is SMB meestal de gemakkelijkere keuze. Veel media-applicaties kunnen SMB-shares doorzoeken met een serveradres, gebruikersnaam en wachtwoord.

NFS-ondersteuning varieert tussen applicaties en apparaten. Zelfs wanneer het beschikbaar is, kan de export- en machtigingsinstelling minder duidelijk zijn voor huishoudelijke gebruikers dan het invoeren van gewone SMB-inloggegevens.

Dit staat los van hoe de mediaserver zelf opslag mount. Een Linux Jellyfin-server kan zijn bibliotheek via NFS lezen, terwijl gezinsapparaten alleen verbinding maken met de web- of streaminginterface van Jellyfin. De eindgebruikersapparaten hoeven geen directe toegang te hebben tot het onderliggende bestandsprotocol.

NFS is vaak een natuurlijke keuze voor Proxmox-opslag

Proxmox draait op een Linux-basis, dus NFS past natuurlijk in back-up-, ISO-, template- en gedeelde opslagworkflows. Een NAS-export kan door de host worden gemount en beheerd als infrastructuuropslag in plaats van als een desktop-bestandsshare.

Dit betekent niet dat elke virtuele machine-schijf automatisch op een thuis-NFS-server moet worden geplaatst. VM-opslag hangt af van latentie, sync-write gedrag, netwerkbeschikbaarheid, back-up ontwerp en hoe het systeem zich moet gedragen wanneer de NAS opnieuw opstart of de verbinding verliest.

Voor containers kan het ook netter zijn om NFS op de Proxmox-host te mounten en het opslagpad door te geven aan een niet-bevoorrechte container, in plaats van elke container zijn eigen netwerk-mountconfiguratie te geven of deze alleen bevoorrecht te maken om de share te mounten.

Docker-opslag moet worden gekozen op basis van het type gegevens

Het gebruik van een NAS-pad binnen Docker maakt NFS niet automatisch de juiste keuze voor elke container. De werklast is belangrijker dan het containerplatform.

Medialibraries, downloads, imports, exports, back-ups en andere grote gedeelde bestanden werken goed via SMB of NFS. Een Linux Docker-host vindt NFS mogelijk makkelijker omdat bestandseigendom wordt uitgedrukt via bekende UID/GID-waarden.

Databases, SQLite-bestanden, zoekindexen, applicatiestatus en workloads met frequente vergrendeling of synchrone schrijfacties vereisen meer voorzichtigheid. Bewaar die bestanden op lokale opslag tenzij de applicatie expliciet het geselecteerde netwerkbestandssysteem ondersteunt en je herstart-, vergrendelings- en foutgedrag hebt getest.

Mount de share op de host voordat je deze aan containers doorgeeft

Voor veel thuisserver-implementaties is het schoonste model om de NAS-share één keer op de Docker-host te mounten en vervolgens het lokale pad te binden aan de containers die het nodig hebben.

Dit houdt inloggegevens, NFS-exportinstellingen, reconnectgedrag en opstartvolgorde op één plek. Containers zien alleen een normale map, terwijl de host het netwerkbestandssysteem beheert.

Het model werkt met zowel NFS als SMB. Belangrijk is dat de host-mount beschikbaar is voordat de container start, de container UID/GID toegang heeft tot de gemounte bestanden, en de service niet stilletjes schrijft in een lege lokale map als de NAS offline is.

Laat beide protocollen niet zonder plan dezelfde data schrijven

De meeste NAS-platforms kunnen dezelfde dataset via SMB en NFS beschikbaar stellen. Technisch maakt dit het mogelijk dat Windows-gebruikers en Linux-applicaties met dezelfde bestanden werken.

Het probleem is dat de twee paden bestanden kunnen aanmaken onder verschillende identiteiten en ACL-modellen. Een SMB-upload kan toebehoren aan een NAS-account met een gedetailleerde ACL, terwijl een NFS-applicatie schrijft als UID 1000 met POSIX-modusbits en een andere umask.

Als beide protocollen toegang nodig hebben, definieer dan één primaire schrijver. Het andere protocol kan alleen-lezen zijn, of beide kunnen een zorgvuldig afgestemd gedeeld groeps- en overervingsmodel gebruiken. Zonder dat plan ontstaat permissie-afwijking meestal geleidelijk.

Het is redelijk om beide protocollen te gebruiken zolang hun rollen gescheiden blijven

Een gemengd homelab hoeft niet één protocol voor alles te kiezen. Beide draaien kan schoner zijn dan elk apparaat via hetzelfde toegangsmodel te dwingen.

Een praktische verdeling is:

• SMB voor Windows- en Mac-familie-mappen
• SMB voor directe toegang via telefoon, tablet en tv
• NFS voor Proxmox-back-ups en Linux-hosts
• NFS voor een Linux mediaserver met een alleen-lezen bibliotheekmount
• Lokale opslag voor applicatiedatabases en gevoelige runtime-status

De protocollen moeten worden verdeeld op basis van verantwoordelijkheid, niet standaard overal ingeschakeld. Gescheiden datasets of duidelijke lees-/schrijfrichtlijnen verminderen permissieconflicten en maken probleemoplossing eenvoudiger.

Geen van beide protocollen mag direct aan het internet worden blootgesteld

SMB en NFS zijn bedoeld voor vertrouwde lokale netwerken of privé-netwerkpaden. Stuur TCP 445 voor SMB of de NFS-servicepoorten niet door van een thuisrouter naar het openbare internet.

Voor externe bestands toegang, maak eerst verbinding met het thuisnetwerk via een VPN of een andere geauthenticeerde privé-toegangslaag. Zodra het externe apparaat binnen dat vertrouwde pad is, kan het dezelfde SMB- of NFS-service gebruiken die op het LAN beschikbaar is.

Overschakelen van SMB naar NFS maakt publieke blootstelling niet veiliger. Beveiliging hangt af van het beperken van bereikbare clients, het up-to-date houden van software, het gebruik van passende authenticatie en het vermijden van onnodige publieke diensten.

Benchmark meer dan overdrachtssnelheid

Een eerlijke thuistest gebruikt dezelfde NAS-dataset, client, netwerkverbinding en bestanden voor beide protocollen. Anders meet het resultaat mogelijk verschillende opslagpaden of clientapparaten in plaats van SMB en NFS.

Registreer meer dan megabytes per seconde. Test of de mount opnieuw verbinding maakt na slaapstand of herstart, of bestandsnamen en metadata correct werken, of applicaties bestanden kunnen aanmaken en verwijderen, en of permissies consistent blijven.

Een protocol dat vijf procent sneller is maar regelmatig faalt na een herstart kan de slechtere keuze zijn. Betrouwbaarheid, clientcompatibiliteit en de tijd die nodig is om permissies te onderhouden maken deel uit van de prestaties in de praktijk.

Gebruik deze beslisvolgorde

Begin met de clients in plaats van een protocolvoorkeur. Maak een lijst van elke computer, mobiel apparaat, mediaplayer, server, hypervisor en applicatie die de data nodig heeft.

Schei daarna menselijk bladeren en machine-naar-machine toegang. Huishoudelijke gebruikers profiteren meestal van SMB-accounts en vertrouwde bestandsbrowsers. Beheerde Linux-diensten kunnen baat hebben bij NFS-mounts en numerieke identiteitscontrole.

Beantwoord deze vragen voordat je de definitieve share inschakelt:

1. Bladeren Windows- of macOS-gebruikers door de bestanden?
2. Hebben telefoons of televisie-applicaties directe toegang nodig?
3. Zijn de meeste clients beheerde Linux-systemen?
4. Kunnen UID- en GID-waarden consistent blijven?
5. Bevat de werklast databases of bestanden die gevoelig zijn voor vergrendeling?
6. Zullen SMB en NFS beide naar dezelfde dataset schrijven?
7. Hoe moet de mount zich gedragen wanneer de NAS niet beschikbaar is?
8. Kan het geselecteerde protocol volledig buiten het openbare internet worden gehouden?

Voor de meeste huizen met gemengde apparaten, begin met SMB. Voeg NFS alleen toe voor een specifieke Linux-, Proxmox-, back-up- of containerbelasting die er baat bij heeft en die je consistent kunt beheren.

Laatste conclusie

SMB is meestal de betere standaard voor Windows, macOS, telefoons, tablets, smart-tv’s en gedeelde gezinsmappen. Het biedt brede compatibiliteit en een accountgebaseerd toegangsmodel dat makkelijker uit te leggen is aan gebruikers in huis.

NFS is vaak beter geschikt voor Linux-servers, Proxmox-opslag, geautomatiseerde backups en andere machine-naar-machine workflows. De voordelen hangen af van correct beheerde UID/GID-waarden, exports, mountopties en eigendom.

Je kunt beide protocollen thuis gebruiken, maar hun verantwoordelijkheden moeten duidelijk zijn. Gebruik SMB voor mensen en gemengde clientapparaten, gebruik NFS voor beheerde Linux-infrastructuur, en vermijd dat beide protocollen onbeperkte schrijfrechten op dezelfde dataset krijgen.

FAQ

Is NFS altijd sneller dan SMB?

Nee. NFS kan beter presteren bij sommige Linux-naar-Linux en kleine-bestand workloads, terwijl modern SMB zeer goed kan presteren op Windows en netwerken met gemengde clients. Test de daadwerkelijke bestanden, clients, opslag en het netwerk dat je wilt gebruiken.

Moet ik SMB of NFS gebruiken voor Plex en Jellyfin?

Beide kunnen werken. Een Linux-mediaserver kan profiteren van NFS bij grote bibliotheekscans, terwijl SMB makkelijker kan zijn wanneer Windows, macOS of mediaplayer-applicaties direct toegang tot de NAS nodig hebben. Grote videostreams werken meestal goed via beide.

Is NFS beter voor Proxmox?

NFS is een veelgebruikte en natuurlijke keuze voor Proxmox-backups, ISO-opslag, templates en gedeelde opslag. VM-schijven en workloads met veel schrijfbewerkingen vereisen nog wel testen op latency, synchronisatiegedrag en NAS-beschikbaarheid.

Kunnen Docker-containers SMB-shares gebruiken?

Ja. Mount de SMB-share op de Docker-host en bind-mount het resulterende pad in de container. Zorg dat de containergebruiker toestemming heeft om de gemounte bestanden te benaderen en dat de host-mount beschikbaar is voordat de container start.

Waarom geeft NFS 'toegang geweigerd' terwijl de share wel gemount is?

De export- en netwerkpad kunnen correct zijn terwijl de client UID/GID niet overeenkomt met de eigenaar of toegestane groep op de NAS. Root squashing of export mapping kan ook de effectieve gebruiker wijzigen.

Kan ik SMB en NFS inschakelen op dezelfde map?

Dat kan, maar gelijktijdige schrijfbewerkingen kunnen conflicten veroorzaken met eigendom, ACL en uitgebreide attributen. Geef de voorkeur aan aparte datasets, maak één protocol alleen-lezen, of creëer een zorgvuldig afgestemd gedeeld permissiemodel.

Welk protocol is veiliger thuis?

Beide kunnen beveiligd worden op een vertrouwd LAN. SMB biedt eenvoudige gebruikersauthenticatie en moderne ondertekening of encryptie. NFS moet beperkt worden tot vertrouwde clients, met correcte exportregels en root squashing. Geen van beide mag direct aan het internet worden blootgesteld.

Welk protocol moet een beginner kiezen?

Kies SMB wanneer het thuisnetwerk Windows, macOS, telefoons of tv-applicaties bevat. Kies NFS wanneer de clients voornamelijk Linux-systemen zijn en je comfortabel bent met het beheren van mounts, UID/GID-waarden en exportrechten.