SMB vs NFS : Quelle méthode de partage de fichiers devriez-vous utiliser à la maison ?

Si votre réseau domestique comprend des PC Windows, des Mac, des téléphones, des tablettes et des lecteurs multimédia, SMB est généralement le meilleur choix par défaut. Il s'intègre naturellement aux navigateurs de fichiers de bureau, prend en charge les connexions basées sur l'utilisateur et est largement disponible dans les applications grand public.

NFS devient plus attractif lorsque les clients sont principalement des serveurs Linux, des hôtes Proxmox ou d'autres systèmes de type Unix qui montent le stockage dans le cadre d'un flux de travail d'infrastructure gérée. Il peut être efficace et prévisible, mais seulement lorsque les valeurs UID/GID, les règles d'exportation, le comportement de montage et la propriété des fichiers sont correctement planifiés.

Choisissez le protocole en fonction du client, pas du benchmark

SMB et NFS permettent tous deux aux appareils d'ouvrir des fichiers stockés sur un NAS ou un serveur domestique, mais ils ont été conçus pour des écosystèmes différents. SMB est natif de Windows et largement supporté par macOS, Linux, les gestionnaires de fichiers mobiles, les téléviseurs intelligents et les applications multimédia. NFS s'intègre plus naturellement aux flux de travail de montage Linux et Unix.

Cette distinction est plus importante qu'une affirmation générique selon laquelle un protocole est plus rapide. Un ordinateur portable Windows peut offrir une expérience plus fluide et rapide avec SMB car sa pile cliente est conçue autour de SMB. Un serveur Linux traitant des milliers de fichiers peut être plus facile à gérer avec NFS car le répertoire distant se comporte comme un montage Unix normal.

Commencez par lister les appareils qui accéderont au partage et ce qu'ils en feront. La navigation manuelle des fichiers, le stockage machine-à-machine, le streaming multimédia, les sauvegardes, la virtualisation et les données de conteneurs n'ont pas toujours besoin du même protocole.

SMB est généralement le choix par défaut le plus simple pour un environnement domestique mixte

SMB est généralement l'option la plus simple lorsque les utilisateurs ouvrent manuellement des dossiers depuis l'Explorateur de fichiers Windows, le Finder macOS, un téléphone ou une application de lecteur multimédia. Les utilisateurs peuvent se connecter avec un nom d'utilisateur et un mot de passe NAS sans gérer les identités numériques Linux sur chaque client.

Les versions modernes de SMB offrent également des fonctionnalités au-delà du simple transfert de fichiers, notamment les ACLs utilisateur et groupe, la signature, le chiffrement, le verrouillage de fichiers, la mise en cache et les capacités multicanaux. Ces fonctionnalités ajoutent de la complexité, mais elles sont utiles lorsque plusieurs membres du foyer ont besoin de droits d'accès différents.

Pour les réseaux mixtes Windows, macOS et Linux, le SMB 3.x moderne peut réduire une grande partie de l’écart de performance tout en conservant une compatibilité client plus large. Cela fait de SMB le point de départ pratique pour les documents, photos de famille, téléchargements partagés et navigation générale sur NAS.

NFS s’intègre plus naturellement aux flux de travail Linux gérés

NFS est souvent plus facile à intégrer lorsque le client est un serveur Linux plutôt qu’une personne naviguant dans des dossiers. Le partage peut être monté dans un répertoire fixe au démarrage et utilisé par des logiciels de sauvegarde, des services multimédias, des hôtes de virtualisation ou d’autres processus système.

Cela fonctionne bien lorsqu’un administrateur contrôle à la fois le NAS et les clients. Vous pouvez définir le sous-réseau autorisé, aligner les utilisateurs et groupes, choisir les options de montage et vous assurer que les services démarrent uniquement après que le partage réseau soit disponible.

NFS devient moins pratique lorsque des ordinateurs portables Windows, des applications mobiles ou plusieurs utilisateurs du foyer ont besoin d’un accès direct. Bien que des clients NFS multiplateformes existent, la configuration et le mappage des identités sont généralement moins simples que l’utilisation de SMB sur ces appareils.

SMB et NFS utilisent des modèles d’accès différents

SMB présente généralement l’accès comme un compte serveur. Un utilisateur se connecte avec des identifiants, et le NAS évalue les permissions de partage, les groupes et les ACL du système de fichiers associés à cette identité.

Les configurations NFS domestiques courantes fonctionnent différemment. L’export est souvent limité à des hôtes ou sous-réseaux sélectionnés, tandis que l’accès aux fichiers dépend des valeurs numériques UID et GID Unix envoyées par le client. NFSv4 peut utiliser des configurations d’identité et Kerberos plus avancées, mais de nombreuses installations domestiques continuent de s’appuyer sur des réseaux clients de confiance et la propriété numérique.

La distinction pratique est que SMB utilise couramment des ACL utilisateur et groupe, tandis que l’accès NFS est étroitement lié aux règles d’hôte et à la propriété Linux UID/GID. Aucun modèle n’est automatiquement meilleur, mais chacun crée des problèmes de dépannage différents.

La planification des UID et GID est la principale courbe d'apprentissage de NFS

Un nom d'utilisateur Linux n'est qu'une étiquette lisible. Le système de fichiers enregistre finalement des identifiants numériques d'utilisateur et de groupe. Deux machines peuvent avoir un utilisateur appelé média, mais ce sont des identités différentes si l'un utilise l'UID 1000 et l'autre l'UID 1001.

C'est pourquoi un partage NFS peut se monter avec succès alors que la création de fichiers échoue encore. Le chemin réseau et l'export fonctionnent, mais l'utilisateur présenté par le client ne correspond pas au propriétaire, au groupe ou à l'ACL sur le NAS.

Avant d'utiliser NFS pour plusieurs systèmes Linux, comparez les résultats de id username sur le client et le serveur. Le type d'alignement numérique UID et GID requis pour les partages NFS en écriture est souvent l'étape manquante quand un utilisateur peut entrer dans un répertoire mais ne peut pas créer de fichiers.

Le root squash n'est pas une erreur de permission aléatoire

Les exports NFS utilisent couramment le root squashing pour empêcher un utilisateur root sur une machine cliente de devenir automatiquement root sur le NAS. Les requêtes provenant de l'UID distant 0 sont mappées à une identité anonyme moins privilégiée.

Cela peut surprendre les utilisateurs exécutant des scripts de sauvegarde, des conteneurs ou des commandes de copie administratives en root. Le partage est monté, mais les écritures échouent ou les fichiers apparaissent sous un utilisateur anonyme.

Ne désactivez pas le root squashing simplement parce qu'il bloque un flux de travail. Déterminez d'abord quel utilisateur ou groupe non-root doit posséder les données, puis donnez à cette identité l'accès requis. Utiliser no_root_squash sacrifier une frontière de sécurité importante et ne doit pas être traité comme un raccourci normal pour un serveur domestique.

NFS n'est pas automatiquement plus rapide que SMB

Les performances dépendent du système d'exploitation client, de la version du protocole, de la taille des fichiers, de la charge de travail des métadonnées, du pool de stockage, de la signature ou du chiffrement, des options de montage, du lien réseau et du comportement de l'application.

Une seule grande vidéo teste principalement le débit séquentiel. Si les deux protocoles peuvent saturer le disque ou le lien réseau, leurs résultats peuvent sembler similaires. Un répertoire contenant des milliers de vignettes, sous-titres, fichiers de métadonnées et dossiers imbriqués exerce plus de pression sur la recherche de fichiers, la mise en cache des attributs et les petites opérations.

C'est pourquoi un seul benchmark ne peut pas trancher le choix pour chaque foyer. Testez au moins quatre charges de travail : une grande lecture, une grande écriture, un répertoire avec de nombreux petits fichiers, et une navigation normale dans un dossier depuis le client qui utilisera réellement le partage.

Les gros fichiers multimédias n'ont généralement pas besoin du protocole le plus rapide

Un flux vidéo typique consomme beaucoup moins de bande passante que ce qu'une connexion Gigabit Ethernet saine peut fournir. Si un serveur multimédia ne peut pas lire une vidéo de manière fiable sur un réseau local, le goulot d'étranglement peut être le Wi-Fi, la transcodification, les performances du disque ou la compatibilité du client plutôt que SMB contre NFS.

La différence devient plus visible lorsque Plex, Jellyfin, Sonarr ou une autre application scanne une grande bibliothèque. Le serveur peut ouvrir des milliers d’affiches, sous-titres, fichiers NFO et références de base de données même si la lecture réelle lit un seul gros fichier média de manière séquentielle.

Pour cette raison, le streaming de gros fichiers peut bien fonctionner avec l’un ou l’autre protocole tandis que les scans de petites bibliothèques révèlent des différences plus importantes. Les serveurs multimédias basés sur Linux peuvent bénéficier de NFS, mais les clients Windows et macOS restent généralement plus faciles à supporter via SMB.

SMB est généralement préférable pour un accès direct aux lecteurs multimédias

Si un Apple TV, un appareil Android TV, un téléphone, une tablette ou un ordinateur portable se connecte directement au NAS, SMB est normalement le choix le plus simple. De nombreuses applications multimédias peuvent parcourir les partages SMB avec une adresse serveur, un nom d’utilisateur et un mot de passe.

Le support NFS varie selon les applications et les appareils. Même lorsqu’il est disponible, sa configuration d’exportation et de permissions peut être moins évidente pour les utilisateurs domestiques que la saisie des identifiants SMB ordinaires.

Cela est distinct de la manière dont le serveur multimédia lui-même monte le stockage. Un serveur Linux Jellyfin peut lire sa bibliothèque via NFS, tandis que les appareils familiaux se connectent uniquement à l’interface web ou de streaming de Jellyfin. Les appareils des utilisateurs finaux n’ont pas besoin d’un accès direct au protocole de fichiers sous-jacent.

NFS est souvent un choix naturel pour le stockage Proxmox

Proxmox fonctionne sur une base Linux, donc NFS s’intègre naturellement dans les flux de travail de sauvegarde, ISO, modèles et stockage partagé. Une exportation NAS peut être montée par l’hôte et gérée comme un stockage d’infrastructure plutôt que comme un partage de fichiers de bureau.

Cela ne signifie pas que chaque disque de machine virtuelle doit automatiquement être placé sur un serveur NFS domestique. Le stockage VM dépend de la latence, du comportement d’écriture synchronisée, de la disponibilité du réseau, de la conception des sauvegardes et de la manière dont le système doit se comporter lorsque le NAS redémarre ou se déconnecte.

Pour les conteneurs, il peut aussi être plus propre de monter NFS sur l'hôte Proxmox et passer le chemin de stockage dans un conteneur non privilégié, plutôt que de donner à chaque conteneur sa propre configuration de montage réseau ou de le rendre privilégié uniquement pour monter le partage.

Le stockage Docker doit être choisi en fonction du type de données

Utiliser un chemin NAS dans Docker ne fait pas automatiquement de NFS le choix idéal pour chaque conteneur. La charge de travail compte plus que la plateforme de conteneur.

Les bibliothèques médias, téléchargements, importations, exportations, sauvegardes et autres fichiers partagés volumineux peuvent bien fonctionner via SMB ou NFS. Un hôte Docker Linux peut trouver NFS plus simple car la propriété des fichiers s'exprime via des valeurs UID/GID familières.

Les bases de données, fichiers SQLite, index de recherche, état d'application et charges de travail avec verrouillage fréquent ou écritures synchrones nécessitent plus de précautions. Gardez ces fichiers sur un stockage local sauf si l'application supporte explicitement le système de fichiers réseau choisi et que vous avez testé le redémarrage, le verrouillage et le comportement en cas de panne.

Montez le partage sur l'hôte avant de le passer aux conteneurs

Pour de nombreux déploiements de serveurs domestiques, le modèle le plus propre est de monter le partage NAS une fois sur l'hôte Docker, puis de monter en liaison le chemin local dans les conteneurs qui en ont besoin.

Cela maintient les identifiants, les paramètres d'export NFS, le comportement de reconnexion et l'ordre de démarrage en un seul endroit. Les conteneurs ne voient qu'un répertoire normal, tandis que l'hôte gère le système de fichiers réseau.

Le modèle fonctionne avec NFS ou SMB. Les détails importants sont que le montage hôte soit disponible avant le démarrage du conteneur, que le UID/GID du conteneur puisse accéder aux fichiers montés, et que le service n'écrive pas silencieusement dans un répertoire local vide lorsque le NAS est hors ligne.

Ne laissez pas les deux protocoles écrire les mêmes données sans plan

La plupart des plateformes NAS peuvent exposer le même ensemble de données via SMB et NFS. Techniquement, cela permet aux utilisateurs Windows et aux applications Linux de travailler avec les mêmes fichiers.

Le problème est que les deux chemins peuvent créer des fichiers sous des identités et des modèles ACL différents. Un téléchargement SMB peut appartenir à un compte NAS avec une ACL détaillée, tandis qu'une application NFS écrit en tant que UID 1000 avec des bits de mode POSIX et un umask différent.

Si les deux protocoles doivent avoir accès, définissez un seul écrivain principal. L'autre protocole peut être en lecture seule, ou les deux peuvent utiliser un groupe partagé et un modèle d'héritage soigneusement alignés. Sans ce plan, la dérive des permissions tend à apparaître progressivement plutôt qu'immédiatement.

Utiliser les deux protocoles est raisonnable lorsque leurs rôles restent séparés

Un laboratoire domestique mixte n'a pas besoin de choisir un seul protocole pour tout. Utiliser les deux peut être plus propre que de forcer chaque appareil à passer par le même modèle d'accès.

Une division pratique est :

• SMB pour les dossiers familiaux Windows et Mac
• SMB pour un accès direct depuis téléphone, tablette et TV
• NFS pour les sauvegardes Proxmox et les hôtes Linux
• NFS pour le montage en lecture seule de la bibliothèque d'un serveur média Linux
• Stockage local pour les bases de données d'applications et l'état d'exécution sensible

Les protocoles doivent être divisés par responsabilité, et non activés partout par défaut. Séparer les ensembles de données ou établir des limites claires de lecture/écriture réduit les conflits de permissions et facilite le dépannage.

Aucun des deux protocoles ne doit être exposé directement à Internet

SMB et NFS sont destinés aux réseaux locaux de confiance ou aux chemins de réseau privés. Ne redirigez pas le port TCP 445 pour SMB ni les ports de service NFS d’un routeur domestique vers l’internet public.

Pour l’accès distant aux fichiers, connectez-vous d’abord au réseau domestique via un VPN ou une autre couche d’accès privé authentifiée. Une fois l’appareil distant dans ce chemin de confiance, il peut utiliser le même service SMB ou NFS disponible sur le LAN.

Passer de SMB à NFS ne rend pas l’exposition publique plus sûre. La sécurité dépend de la limitation des clients accessibles, de la mise à jour des logiciels, de l’utilisation d’une authentification appropriée et de l’évitement des services publics inutiles.

Évaluez plus que la vitesse de transfert

Un test domestique équitable doit utiliser le même ensemble de données NAS, client, lien réseau et fichiers pour les deux protocoles. Sinon, le résultat peut mesurer différents chemins de stockage ou appareils clients plutôt que SMB et NFS.

Enregistrez plus que des mégaoctets par seconde. Testez si le montage se reconnecte après une mise en veille ou un redémarrage, si les noms de fichiers et les métadonnées se comportent correctement, si les applications peuvent créer et supprimer des fichiers, et si les permissions restent cohérentes.

Un protocole 5 % plus rapide mais qui échoue régulièrement après un redémarrage peut être le pire choix. La fiabilité, la compatibilité client et le temps nécessaire pour maintenir les permissions font partie des performances réelles.

Utilisez cet ordre de décision

Commencez par les clients plutôt que par une préférence de protocole. Listez chaque ordinateur, appareil mobile, lecteur multimédia, serveur, hyperviseur et application qui a besoin des données.

Puis séparez la navigation humaine de l’accès machine-à-machine. Les utilisateurs domestiques bénéficient généralement de comptes SMB et de navigateurs de fichiers familiers. Les services Linux gérés peuvent bénéficier de montages NFS et d’un contrôle d’identité numérique.

Avant d’activer le partage final, répondez à ces questions :

1. Les utilisateurs Windows ou macOS consultent-ils les fichiers ?
2. Les téléphones ou applications télévisuelles ont-ils besoin d’un accès direct ?
3. La plupart des clients sont-ils des systèmes Linux gérés ?
4. Les valeurs UID et GID peuvent-elles rester cohérentes ?
5. La charge de travail inclut-elle des bases de données ou des fichiers sensibles au verrouillage ?
6. SMB et NFS écriront-ils tous deux sur le même ensemble de données ?
7. Comment le montage doit-il se comporter lorsque le NAS est indisponible ?
8. Le protocole sélectionné peut-il être complètement coupé de l’internet public ?

Pour la plupart des foyers avec des appareils mixtes, commencez par SMB. Ajoutez NFS uniquement pour une charge de travail spécifique Linux, Proxmox, de sauvegarde ou de conteneur qui en bénéficie et que vous pouvez gérer de manière cohérente.

Conclusion finale

SMB est généralement le meilleur choix par défaut pour Windows, macOS, téléphones, tablettes, téléviseurs intelligents et dossiers familiaux partagés. Il offre une large compatibilité et un modèle d'accès basé sur les comptes, plus facile à expliquer aux utilisateurs du foyer.

NFS est souvent mieux adapté aux serveurs Linux, au stockage Proxmox, aux sauvegardes automatisées et autres flux de travail machine-à-machine. Ses avantages dépendent d'une gestion correcte des valeurs UID/GID, des exports, des options de montage et de la propriété.

Vous pouvez utiliser les deux protocoles à la maison, mais leurs responsabilités doivent être claires. Utilisez SMB pour les personnes et les appareils clients mixtes, utilisez NFS pour l'infrastructure Linux gérée, et évitez de donner aux deux protocoles un accès en écriture non contrôlé au même ensemble de données.

FAQ

NFS est-il toujours plus rapide que SMB ?

Non. NFS peut offrir de meilleures performances dans certains cas Linux-à-Linux et pour les petits fichiers, tandis que SMB moderne peut très bien fonctionner sur Windows et les réseaux à clients mixtes. Testez les fichiers, clients, stockage et réseau que vous prévoyez d'utiliser.

Dois-je utiliser SMB ou NFS pour Plex et Jellyfin ?

Les deux peuvent fonctionner. Un serveur multimédia Linux peut bénéficier de NFS lors de grandes analyses de bibliothèque, tandis que SMB peut être plus simple lorsque Windows, macOS ou des applications de lecteur multimédia accèdent directement au NAS. Le streaming vidéo important fonctionne généralement bien avec les deux.

NFS est-il meilleur pour Proxmox ?

NFS est un choix courant et naturel pour les sauvegardes Proxmox, le stockage ISO, les modèles et le stockage partagé. Les disques VM et les charges d'écriture intensives nécessitent encore des tests pour la latence, le comportement de synchronisation et la disponibilité du NAS.

Les conteneurs Docker peuvent-ils utiliser des partages SMB ?

Oui. Montez le partage SMB sur l'hôte Docker et liez ce chemin dans le conteneur. Assurez-vous que l'utilisateur du conteneur a la permission d'accéder aux fichiers montés et que le montage sur l'hôte est disponible avant le démarrage du conteneur.

Pourquoi NFS affiche-t-il un refus d'autorisation alors que le partage est monté ?

L'exportation et le chemin réseau peuvent être corrects alors que l'UID/GID du client ne correspond pas au propriétaire ou au groupe autorisé sur le NAS. Le root squashing ou le mappage d'exportation peut aussi modifier l'utilisateur effectif.

Puis-je activer SMB et NFS sur le même dossier ?

Vous pouvez, mais un accès en écriture simultané peut créer des conflits de propriété, d'ACL et d'attributs étendus. Préférez des ensembles de données séparés, rendez un protocole en lecture seule, ou créez un modèle de permissions partagé soigneusement aligné.

Quel protocole est le plus sûr à la maison ?

Les deux peuvent être sécurisés sur un réseau local de confiance. SMB offre une authentification utilisateur simple ainsi qu'une signature ou un chiffrement moderne. NFS doit être limité aux clients de confiance, avec des règles d'exportation correctes et un root squashing. Aucun des deux ne doit être exposé directement à Internet.

Quel protocole un débutant devrait-il choisir ?

Choisissez SMB lorsque le domicile comprend Windows, macOS, des téléphones ou des applications TV. Choisissez NFS lorsque les clients sont principalement des systèmes Linux et que vous êtes à l'aise pour gérer les montages, les valeurs UID/GID et les permissions d'exportation.