SMB vs NFS: Quale metodo di condivisione file dovresti usare a casa?

Se la tua rete domestica include PC Windows, Mac, telefoni, tablet e media player, SMB è solitamente la scelta predefinita migliore. Si integra naturalmente con i browser di file desktop, supporta login basati su utente ed è ampiamente disponibile nelle applicazioni consumer.

NFS diventa più interessante quando i client sono principalmente server Linux, host Proxmox o altri sistemi Unix-like che montano lo storage come parte di un flusso di lavoro infrastrutturale gestito. Può essere efficiente e prevedibile, ma solo se i valori UID/GID, le regole di esportazione, il comportamento di montaggio e la proprietà dei file sono pianificati correttamente.

Scegli il protocollo in base al client, non al benchmark

SMB e NFS permettono entrambi ai dispositivi di aprire file memorizzati su un NAS o server domestico, ma sono stati progettati per ecosistemi diversi. SMB è nativo di Windows ed è ampiamente supportato da macOS, Linux, gestori di file mobili, smart TV e applicazioni multimediali. NFS si integra più naturalmente nei flussi di lavoro di montaggio Linux e Unix.

Questa distinzione è più importante di un'affermazione generica che un protocollo sia più veloce. Un laptop Windows può avere un'esperienza più fluida e veloce con SMB perché il suo stack client è costruito attorno a SMB. Un server Linux che elabora migliaia di file può essere più facile da gestire con NFS perché la directory remota si comporta come un normale montaggio Unix.

Inizia elencando i dispositivi che accederanno alla condivisione e cosa faranno con essa. La navigazione manuale dei file, l'archiviazione macchina a macchina, lo streaming multimediale, i backup, la virtualizzazione e i dati dei container non richiedono sempre lo stesso protocollo.

SMB è solitamente l'opzione predefinita più semplice per un ambiente domestico misto

SMB è normalmente l'opzione più semplice quando le persone aprono manualmente le cartelle da Windows File Explorer, macOS Finder, un telefono o un'applicazione per media player. Gli utenti possono connettersi con un nome utente e una password NAS senza dover gestire identità numeriche Linux su ogni client.

Le versioni moderne di SMB offrono anche funzionalità oltre al semplice trasferimento di file, inclusi ACL per utenti e gruppi, firma, crittografia, blocco file, caching e capacità multicanale. Queste funzionalità aggiungono complessità, ma sono utili quando diversi membri della famiglia necessitano di diritti di accesso differenti.

Per reti miste Windows, macOS e Linux, SMB 3.x moderno può ridurre gran parte del divario di prestazioni mantenendo una compatibilità client più ampia. Questo rende SMB il punto di partenza pratico per documenti, foto di famiglia, download condivisi e navigazione generale del NAS.

NFS si adatta più naturalmente ai flussi di lavoro Linux gestiti

NFS è spesso più facile da integrare quando il client è un server Linux piuttosto che una persona che naviga tra le cartelle. La condivisione può essere montata in una directory fissa all’avvio e usata da software di backup, servizi multimediali, host di virtualizzazione o altri processi di sistema.

Questo funziona bene quando un amministratore controlla sia il NAS che i client. Puoi definire la subnet consentita, allineare utenti e gruppi, scegliere opzioni di mount e assicurarti che i servizi si avviino solo dopo che la condivisione di rete è disponibile.

NFS diventa meno comodo quando laptop Windows, app mobili o più utenti domestici necessitano di accesso diretto. Sebbene esistano client NFS multipiattaforma, la configurazione e la mappatura delle identità sono generalmente meno semplici rispetto all’uso di SMB su quei dispositivi.

SMB e NFS usano modelli di accesso diversi

SMB solitamente presenta l’accesso come un account server. Un utente si connette con credenziali e il NAS valuta permessi di condivisione, gruppi e ACL del filesystem associati a quell’identità.

Le configurazioni NFS domestiche comuni funzionano diversamente. L’export è spesso limitato a host o subnet selezionati, mentre l’accesso ai file dipende dai valori numerici Unix UID e GID inviati dal client. NFSv4 può usare configurazioni di identità e Kerberos più avanzate, ma molte configurazioni domestiche continuano a basarsi su reti di client affidabili e proprietà numerica.

La distinzione pratica è che SMB usa comunemente ACL per utenti e gruppi, mentre l’accesso NFS è strettamente legato a regole host e proprietà Linux UID/GID. Nessun modello è automaticamente migliore, ma ciascuno crea problemi di risoluzione diversi.

La pianificazione di UID e GID è la principale curva di apprendimento di NFS

Un nome utente Linux è solo un'etichetta leggibile. Il filesystem registra in definitiva gli ID numerici utente e gruppo. Due macchine possono avere entrambe un utente chiamato media, ma sono identità diverse se uno usa UID 1000 e l'altro usa UID 1001.

Ecco perché una condivisione NFS può montarsi con successo mentre la creazione di file fallisce ancora. Il percorso di rete e l'export funzionano, ma l'utente presentato dal client non corrisponde al proprietario, al gruppo o all'ACL sul NAS.

Prima di usare NFS per diversi sistemi Linux, confronta i risultati di id username sul client e sul server. Il tipo di allineamento numerico UID e GID richiesto per le condivisioni NFS scrivibili è spesso il passaggio mancante quando un utente può entrare in una directory ma non può creare file.

Il Root Squash non è un errore casuale di permessi

Le esportazioni NFS usano comunemente il root squashing per impedire a un utente root su una macchina client di diventare automaticamente root sul NAS. Le richieste da UID remoto 0 sono mappate a un'identità anonima meno privilegiata.

Questo può sorprendere gli utenti che eseguono script di backup, container o comandi di copia amministrativi come root. La condivisione si monta, ma le scritture falliscono o i file appaiono sotto un utente anonimo.

Non disabilitare il root squashing semplicemente perché blocca un flusso di lavoro. Prima determina quale utente o gruppo non root dovrebbe possedere i dati, quindi concedi a quell'identità l'accesso richiesto. Usando no_root_squash cede un importante confine di sicurezza e non dovrebbe essere trattato come una scorciatoia normale per un server domestico.

NFS non è automaticamente più veloce di SMB

Le prestazioni dipendono dal sistema operativo del client, dalla versione del protocollo, dalla dimensione del file, dal carico di lavoro dei metadati, dal pool di archiviazione, dalla firma o crittografia, dalle opzioni di montaggio, dal collegamento di rete e dal comportamento dell'applicazione.

Un singolo video grande testa principalmente la velocità sequenziale. Se entrambi i protocolli possono saturare il disco o il collegamento di rete, i loro risultati possono sembrare simili. Una directory contenente migliaia di miniature, sottotitoli, file di metadati e cartelle annidate esercita maggiore pressione sulla ricerca dei file, la memorizzazione nella cache degli attributi e le operazioni di piccole dimensioni.

Ecco perché un singolo benchmark non può decidere la scelta per ogni casa. Testa almeno quattro carichi di lavoro: una grande lettura, una grande scrittura, una directory con molti file piccoli e la normale navigazione delle cartelle dal client che effettivamente utilizzerà la condivisione.

I grandi file multimediali di solito non necessitano del protocollo più veloce

Un tipico streaming di un film consuma molta meno larghezza di banda di quella che una connessione Gigabit Ethernet sana può fornire. Se un media server non riesce a riprodurre un video in modo affidabile su una rete locale, il collo di bottiglia potrebbe essere il Wi-Fi, la transcodifica, le prestazioni del disco o la compatibilità del client, piuttosto che SMB contro NFS.

La differenza diventa più evidente quando Plex, Jellyfin, Sonarr o un'altra applicazione scansiona una grande libreria. Il server può aprire migliaia di poster, sottotitoli, file NFO e riferimenti al database anche se la riproduzione effettiva legge un unico grande file multimediale in modo sequenziale.

Per questo motivo, lo streaming di file di grandi dimensioni può funzionare bene con entrambi i protocolli mentre le scansioni di librerie di piccoli file mostrano differenze maggiori. I server media basati su Linux possono beneficiare di NFS, ma i client Windows e macOS tendono ancora a essere più facili da supportare tramite SMB.

SMB è solitamente migliore per l'accesso diretto da media player

Se un Apple TV, dispositivo Android TV, telefono, tablet o laptop si connette direttamente al NAS, SMB è normalmente la scelta più semplice. Molte applicazioni media possono sfogliare le condivisioni SMB con indirizzo server, nome utente e password.

Il supporto NFS varia tra applicazioni e dispositivi. Anche quando è disponibile, la configurazione di export e permessi può essere meno ovvia per gli utenti domestici rispetto all'inserimento delle normali credenziali SMB.

Questo è separato da come il media server stesso monta lo storage. Un server Linux Jellyfin potrebbe leggere la sua libreria tramite NFS, mentre i dispositivi di famiglia si connettono solo all'interfaccia web o di streaming di Jellyfin. I dispositivi degli utenti finali non necessitano di accesso diretto al protocollo file sottostante.

NFS è spesso una scelta naturale per lo storage Proxmox

Proxmox si basa su Linux, quindi NFS si integra naturalmente nei flussi di lavoro di backup, ISO, template e storage condiviso. Un export NAS può essere montato dall'host e gestito come storage infrastrutturale piuttosto che come condivisione file desktop.

Questo non significa che ogni disco di macchina virtuale debba essere automaticamente posizionato su un server NFS domestico. Lo storage VM dipende da latenza, comportamento di scrittura sincronizzata, disponibilità di rete, progettazione del backup e da come il sistema dovrebbe comportarsi quando il NAS si riavvia o si disconnette.

Per i container, può essere anche più pulito montare NFS sull'host Proxmox e passare il percorso di storage a un container non privilegiato, invece di dare a ogni container la propria configurazione di montaggio di rete o renderlo privilegiato solo per montare la condivisione.

Lo storage Docker dovrebbe essere scelto in base al tipo di dati

Usare un percorso NAS all'interno di Docker non rende automaticamente NFS la scelta giusta per ogni container. Il carico di lavoro conta più della piattaforma del container.

Librerie multimediali, download, importazioni, esportazioni, backup e altri file condivisi di grandi dimensioni possono funzionare bene su SMB o NFS. Un host Docker Linux può trovare NFS più semplice perché la proprietà dei file è espressa tramite valori UID/GID familiari.

Database, file SQLite, indici di ricerca, stato applicativo e carichi di lavoro con frequenti blocchi o scritture sincrone richiedono più cautela. Conserva quei file su archiviazione locale a meno che l’applicazione non supporti esplicitamente il filesystem di rete selezionato e tu abbia testato riavvio, blocchi e comportamento in caso di errore.

Monta la condivisione sull’host prima di passarla ai container

Per molte installazioni di server domestici, il modello più pulito è montare la condivisione NAS una volta sull’host Docker e poi bind-montare il percorso locale nei container che ne hanno bisogno.

Questo mantiene credenziali, impostazioni di esportazione NFS, comportamento di riconnessione e ordine di avvio in un unico posto. I container vedono solo una directory normale, mentre l’host gestisce il filesystem di rete.

Il modello funziona con NFS o SMB. I dettagli importanti sono che il montaggio host sia disponibile prima dell’avvio del container, che UID/GID del container possa accedere ai file montati e che il servizio non scriva silenziosamente in una directory locale vuota quando il NAS è offline.

Non lasciare che entrambi i protocolli scrivano gli stessi dati senza un piano

La maggior parte delle piattaforme NAS può esporre lo stesso dataset tramite SMB e NFS. Tecnicamente, questo permette a utenti Windows e applicazioni Linux di lavorare sugli stessi file.

Il problema è che i due percorsi possono creare file con identità e modelli ACL differenti. Un upload SMB potrebbe appartenere a un account NAS con ACL dettagliata, mentre un’applicazione NFS scrive come UID 1000 con bit di modalità POSIX e umask diversa.

Se entrambi i protocolli necessitano accesso, definire uno scrittore primario. L’altro protocollo può essere in sola lettura, oppure entrambi possono usare un gruppo condiviso e un modello di ereditarietà attentamente allineati. Senza questo piano, la deriva dei permessi tende a manifestarsi gradualmente anziché immediatamente.

Usare entrambi i protocolli è ragionevole quando i loro ruoli rimangono separati

Un laboratorio domestico misto non deve scegliere un solo protocollo per tutto. Usare entrambi può essere più pulito che forzare ogni dispositivo a passare dallo stesso modello di accesso.

Una divisione pratica è:

• SMB per cartelle familiari Windows e Mac
• SMB per accesso diretto da telefono, tablet e TV
• NFS per backup Proxmox e host Linux
• NFS per il montaggio in sola lettura della libreria di un media server Linux
• Archiviazione locale per database applicativi e stato runtime sensibile

I protocolli dovrebbero essere divisi per responsabilità, non abilitati ovunque per impostazione predefinita. Dataset separati o confini chiari di lettura/scrittura riducono i conflitti di permessi e facilitano la risoluzione dei problemi.

Nessuno dei due protocolli dovrebbe essere esposto direttamente a internet

SMB e NFS sono pensati per reti locali fidate o percorsi di rete privati. Non fare port-forwarding della porta TCP 445 per SMB o delle porte di servizio NFS da un router domestico a internet pubblico.

Per l’accesso remoto ai file, connettiti prima alla rete domestica tramite VPN o un altro livello di accesso privato autenticato. Una volta che il dispositivo remoto è all’interno di quel percorso fidato, può usare lo stesso servizio SMB o NFS disponibile sulla LAN.

Passare da SMB a NFS non rende l’esposizione pubblica più sicura. La sicurezza dipende dal limitare i client raggiungibili, mantenere il software aggiornato, usare l’autenticazione appropriata ed evitare servizi pubblici non necessari.

Valuta più della velocità di trasferimento

Un test domestico equo dovrebbe usare lo stesso dataset NAS, client, collegamento di rete e file per entrambi i protocolli. Altrimenti, il risultato potrebbe misurare percorsi di archiviazione o dispositivi client diversi anziché SMB e NFS.

Registra più dei megabyte al secondo. Verifica se il mount si ricollega dopo sospensione o riavvio, se i nomi dei file e i metadati si comportano correttamente, se le applicazioni possono creare e cancellare file e se i permessi rimangono coerenti.

Un protocollo che è il cinque percento più veloce ma che fallisce regolarmente dopo un riavvio può essere la scelta peggiore. Affidabilità, compatibilità client e tempo necessario per mantenere i permessi fanno parte delle prestazioni nel mondo reale.

Usa questo ordine decisionale

Inizia dai client piuttosto che da una preferenza di protocollo. Elenca ogni computer, dispositivo mobile, lettore multimediale, server, hypervisor e applicazione che necessita dei dati.

Poi separa la navigazione umana dall’accesso macchina a macchina. Gli utenti domestici generalmente beneficiano di account SMB e browser di file familiari. I servizi Linux gestiti possono beneficiare di mount NFS e controllo dell’identità numerica.

Prima di abilitare la condivisione finale, rispondi a queste domande:

1. Gli utenti Windows o macOS stanno navigando i file?
2. I telefoni o le applicazioni televisive necessitano di accesso diretto?
3. La maggior parte dei client sono sistemi Linux gestiti?
4. I valori UID e GID possono rimanere coerenti?
5. Il carico di lavoro include database o file sensibili al locking?
6. SMB e NFS scriveranno entrambi sullo stesso dataset?
7. Come dovrebbe comportarsi il mount quando il NAS non è disponibile?
8. Il protocollo selezionato può essere mantenuto completamente fuori da internet pubblico?

Per la maggior parte delle case con dispositivi misti, inizia con SMB. Aggiungi NFS solo per carichi di lavoro specifici su Linux, Proxmox, backup o container che ne traggono beneficio e che puoi gestire in modo coerente.

Conclusione finale

SMB è solitamente la scelta predefinita migliore per Windows, macOS, telefoni, tablet, smart TV e cartelle condivise in famiglia. Offre ampia compatibilità e un modello di accesso basato su account più facile da spiegare agli utenti domestici.

NFS è spesso la scelta migliore per server Linux, storage Proxmox, backup automatizzati e altri flussi di lavoro macchina-macchina. I suoi vantaggi dipendono da valori UID/GID, esportazioni, opzioni di mount e proprietà gestiti correttamente.

Puoi usare entrambi i protocolli a casa, ma le loro responsabilità devono essere chiare. Usa SMB per persone e dispositivi client misti, usa NFS per infrastrutture Linux gestite ed evita di dare a entrambi i protocolli accesso in scrittura incontrollato allo stesso dataset.

FAQ

NFS è sempre più veloce di SMB?

No. NFS può avere prestazioni migliori in alcuni carichi Linux-to-Linux e con file di piccole dimensioni, mentre SMB moderno può funzionare molto bene su Windows e reti con client misti. Testa i file, i client, lo storage e la rete che intendi usare.

Devo usare SMB o NFS per Plex e Jellyfin?

Entrambi possono funzionare. Un media server Linux può beneficiare di NFS durante scansioni di grandi librerie, mentre SMB può essere più semplice quando Windows, macOS o applicazioni media-player accedono direttamente al NAS. Lo streaming video di grandi dimensioni funziona solitamente bene con entrambi.

NFS è migliore per Proxmox?

NFS è una scelta comune e naturale per backup Proxmox, archiviazione ISO, template e storage condiviso. I dischi VM e i carichi di lavoro ad alta scrittura richiedono ancora test per latenza, comportamento di sincronizzazione e disponibilità del NAS.

I container Docker possono usare condivisioni SMB?

Sì. Monta la condivisione SMB sull'host Docker e fai un bind-mount del percorso risultante nel container. Assicurati che l'utente del container abbia il permesso di accedere ai file montati e che il mount dell'host sia disponibile prima dell'avvio del container.

Perché NFS mostra permesso negato anche se la condivisione è montata?

L'esportazione e il percorso di rete possono essere corretti mentre l'UID/GID del client non corrisponde al proprietario o al gruppo autorizzato sul NAS. Root squashing o mappatura dell'esportazione possono anche modificare l'utente effettivo.

Posso abilitare SMB e NFS sulla stessa cartella?

Puoi farlo, ma l'accesso in scrittura simultaneo può creare conflitti di proprietà, ACL e attributi estesi. Preferisci dataset separati, rendi un protocollo di sola lettura o crea un modello di permessi condivisi attentamente allineato.

Quale protocollo è più sicuro a casa?

Entrambi possono essere protetti su una LAN affidabile. SMB offre un'autenticazione utente semplice e una firma o crittografia moderna. NFS dovrebbe essere limitato a client affidabili, con regole di esportazione corrette e root squashing. Nessuno dei due dovrebbe essere esposto direttamente a Internet.

Quale protocollo dovrebbe scegliere un principiante?

Scegli SMB quando la casa include Windows, macOS, telefoni o applicazioni TV. Scegli NFS quando i client sono principalmente sistemi Linux e sei a tuo agio nella gestione di mount, valori UID/GID e permessi di esportazione.