SMB vs NFS: Qual Método de Partilha de Ficheiros Deve Usar em Casa?

Se a sua rede doméstica inclui PCs Windows, Macs, telemóveis, tablets e media players, o SMB é geralmente a melhor opção por defeito. Integra-se naturalmente com navegadores de ficheiros de ambiente de trabalho, suporta logins baseados em utilizador e está amplamente disponível em aplicações de consumo.

O NFS torna-se mais atraente quando os clientes são principalmente servidores Linux, hosts Proxmox ou outros sistemas tipo Unix que montam armazenamento como parte de um fluxo de trabalho de infraestrutura gerida. Pode ser eficiente e previsível, mas apenas quando os valores UID/GID, regras de exportação, comportamento de montagem e propriedade dos ficheiros são planeados corretamente.

Escolha o protocolo com base no cliente, não no benchmark

Tanto o SMB como o NFS permitem que dispositivos abram ficheiros armazenados num NAS ou servidor doméstico, mas foram concebidos para ecossistemas diferentes. O SMB é nativo do Windows e amplamente suportado pelo macOS, Linux, gestores de ficheiros móveis, TVs inteligentes e aplicações de media. O NFS encaixa-se mais naturalmente nos fluxos de trabalho de montagem Linux e Unix.

Essa distinção é mais importante do que uma afirmação genérica de que um protocolo é mais rápido. Um portátil Windows pode ter uma experiência mais fluida e rápida com SMB porque a sua pilha cliente é construída em torno do SMB. Um servidor Linux a processar milhares de ficheiros pode ser mais fácil de gerir com NFS porque o diretório remoto comporta-se como uma montagem Unix normal.

Comece por listar os dispositivos que acederão à partilha e o que farão com ela. Navegação humana de ficheiros, armazenamento máquina a máquina, streaming de media, backups, virtualização e dados de contentores não precisam sempre do mesmo protocolo.

O SMB é geralmente a opção mais fácil por defeito para um ambiente doméstico misto

O SMB é normalmente a opção mais simples quando as pessoas abrem pastas manualmente a partir do Explorador de Ficheiros do Windows, Finder do macOS, de um telemóvel ou de uma aplicação de media player. Os utilizadores podem ligar-se com um nome de utilizador e palavra-passe do NAS sem gerir identidades numéricas Linux em cada cliente.

As versões modernas do SMB também oferecem funcionalidades além da transferência básica de ficheiros, incluindo ACLs de utilizador e grupo, assinatura, encriptação, bloqueio de ficheiros, cache e capacidades multicanal. Essas funcionalidades aumentam a complexidade, mas são úteis quando vários membros da família precisam de diferentes direitos de acesso.

Para redes mistas Windows, macOS e Linux, o SMB 3.x moderno pode reduzir grande parte da diferença de desempenho mantendo uma compatibilidade mais ampla com clientes. Isso torna o SMB o ponto de partida prático para documentos, fotos de família, downloads partilhados e navegação geral no NAS.

O NFS Encaixa-se Mais Naturalmente em Fluxos de Trabalho Linux Geridos

O NFS é frequentemente mais fácil de integrar quando o cliente é um servidor Linux em vez de uma pessoa a navegar por pastas. A partilha pode ser montada numa diretoria fixa durante a inicialização e usada por software de backup, serviços multimédia, hosts de virtualização ou outros processos do sistema.

Isto funciona bem quando um administrador controla tanto o NAS como os clientes. Pode definir a sub-rede permitida, alinhar utilizadores e grupos, escolher opções de montagem e garantir que os serviços só iniciam depois da partilha de rede estar disponível.

O NFS torna-se menos conveniente quando portáteis Windows, aplicações móveis ou múltiplos utilizadores domésticos precisam de acesso direto. Embora existam clientes NFS multiplataforma, a configuração e o mapeamento de identidade são geralmente menos simples do que usar SMB nesses dispositivos.

SMB e NFS Usam Modelos de Acesso Diferentes

O SMB geralmente apresenta o acesso como uma conta de servidor. Um utilizador conecta-se com credenciais, e o NAS avalia permissões de partilha, grupos e ACLs do sistema de ficheiros associadas a essa identidade.

As configurações comuns de NFS doméstico funcionam de forma diferente. A exportação é frequentemente restrita a hosts ou sub-redes selecionados, enquanto o acesso a ficheiros depende dos valores numéricos Unix UID e GID enviados pelo cliente. O NFSv4 pode usar configurações de identidade e Kerberos mais avançadas, mas muitas configurações domésticas continuam a confiar em redes de clientes confiáveis e propriedade numérica.

A distinção prática é que o SMB usa normalmente ACLs de utilizador e grupo, enquanto o acesso NFS está intimamente ligado a regras de host e à propriedade UID/GID do Linux. Nenhum modelo é automaticamente melhor, mas cada um cria problemas diferentes de resolução de problemas.

O Planeamento de UID e GID é a Principal Curva de Aprendizagem do NFS

Um nome de utilizador Linux é apenas um rótulo legível. O sistema de ficheiros regista em última análise IDs numéricos de utilizador e grupo. Duas máquinas podem ter ambas um utilizador chamado media, mas são identidades diferentes se um usar UID 1000 e o outro usar UID 1001.

É por isso que uma partilha NFS pode montar com sucesso enquanto a criação de ficheiros ainda falha. O caminho de rede e a exportação estão a funcionar, mas o utilizador apresentado pelo cliente não corresponde ao proprietário, grupo ou ACL no NAS.

Antes de usar NFS para vários sistemas Linux, compare os resultados de id username no cliente e no servidor. O tipo de alinhamento numérico de UID e GID necessário para partilhas NFS graváveis é muitas vezes o passo em falta quando um utilizador consegue entrar numa diretoria mas não consegue criar ficheiros.

Root Squash Não É Uma Falha Aleatória de Permissão

As exportações NFS usam normalmente root squashing para impedir que um utilizador root numa máquina cliente se torne automaticamente root no NAS. Pedidos do UID remoto 0 são mapeados para uma identidade anónima com menos privilégios.

Isto pode surpreender utilizadores que executam scripts de backup, contentores ou comandos administrativos de cópia como root. A partilha monta, mas as escritas falham ou os ficheiros aparecem sob um utilizador anónimo.

Não desative o root squashing simplesmente porque bloqueia um fluxo de trabalho. Primeiro determine qual utilizador ou grupo não-root deve possuir os dados, depois dê a essa identidade o acesso necessário. Usar no_root_squash cede uma importante barreira de segurança e não deve ser tratado como um atalho normal para servidores domésticos.

NFS Não É Automaticamente Mais Rápido Que SMB

O desempenho depende do sistema operativo do cliente, versão do protocolo, tamanho do ficheiro, carga de trabalho de metadados, pool de armazenamento, assinatura ou encriptação, opções de montagem, ligação de rede e comportamento da aplicação.

Um único vídeo grande testa principalmente a taxa de transferência sequencial. Se ambos os protocolos conseguirem saturar o disco ou a ligação de rede, os seus resultados podem parecer semelhantes. Um diretório contendo milhares de miniaturas, legendas, ficheiros de metadados e pastas aninhadas exerce mais pressão na procura de ficheiros, cache de atributos e operações pequenas.

É por isso que um único teste de desempenho não pode decidir a escolha para todas as casas. Teste pelo menos quatro cargas de trabalho: uma leitura grande, uma escrita grande, um diretório com muitos ficheiros pequenos e a navegação normal em pastas a partir do cliente que realmente vai usar a partilha.

Ficheiros de Media Grandes Normalmente Não Precisam do Protocolo Mais Rápido

Um fluxo típico de filme consome muito menos largura de banda do que uma ligação Gigabit Ethernet saudável pode fornecer. Se um servidor de media não consegue reproduzir um vídeo de forma fiável numa rede local, o gargalo pode ser o Wi-Fi, a transcodificação, o desempenho do disco ou a compatibilidade do cliente, em vez de SMB versus NFS.

A diferença torna-se mais visível quando Plex, Jellyfin, Sonarr ou outra aplicação varre uma biblioteca grande. O servidor pode abrir milhares de posters, legendas, ficheiros NFO e referências de base de dados mesmo que a reprodução real leia um ficheiro de media grande sequencialmente.

Por esta razão, o streaming de ficheiros grandes pode funcionar bem em qualquer dos protocolos enquanto as varreduras de bibliotecas de ficheiros pequenos revelam diferenças maiores. Servidores de media baseados em Linux podem beneficiar do NFS, mas clientes Windows e macOS tendem a ser mais fáceis de suportar através do SMB.

O SMB É Geralmente Melhor para Acesso Direto a Media Players

Se uma Apple TV, dispositivo Android TV, telemóvel, tablet ou portátil se ligar diretamente ao NAS, o SMB é normalmente a escolha mais fácil. Muitas aplicações de media conseguem navegar em partilhas SMB com um endereço de servidor, nome de utilizador e palavra-passe.

O suporte a NFS varia entre aplicações e dispositivos. Mesmo quando está disponível, a configuração da exportação e permissões pode ser menos óbvia para utilizadores domésticos do que inserir credenciais SMB comuns.

Isto é separado de como o próprio servidor de media monta o armazenamento. Um servidor Linux Jellyfin pode ler a sua biblioteca através do NFS, enquanto os dispositivos familiares ligam-se apenas à interface web ou de streaming do Jellyfin. Os dispositivos do utilizador final não precisam de acesso direto ao protocolo de ficheiros subjacente.

O NFS É Frequentemente uma Escolha Natural para Armazenamento Proxmox

O Proxmox corre sobre uma base Linux, por isso o NFS encaixa naturalmente nos fluxos de trabalho de backup, ISO, templates e armazenamento partilhado. Uma exportação NAS pode ser montada pelo host e gerida como armazenamento de infraestrutura em vez de como um compartilhamento de ficheiros de ambiente de trabalho.

Isto não significa que cada disco de máquina virtual deva ser automaticamente colocado num servidor NFS doméstico. O armazenamento da VM depende da latência, comportamento de escrita síncrona, disponibilidade da rede, design de backup e de como o sistema deve comportar-se quando o NAS reiniciar ou se desconectar.

Para contentores, pode também ser mais limpo montar NFS no host Proxmox e passar o caminho de armazenamento para um contentor não privilegiado, em vez de dar a cada contentor a sua própria configuração de montagem de rede ou torná-lo privilegiado apenas para montar o compartilhamento.

O Armazenamento Docker Deve Ser Escolhido pelo Tipo de Dados

Usar um caminho NAS dentro do Docker não torna automaticamente o NFS a escolha certa para todos os contentores. A carga de trabalho importa mais do que a plataforma do contentor.

Bibliotecas de media, downloads, importações, exportações, backups e outros ficheiros partilhados grandes podem funcionar bem via SMB ou NFS. Um host Docker Linux pode achar o NFS mais fácil porque a propriedade dos ficheiros é expressa através dos valores UID/GID familiares.

Bases de dados, ficheiros SQLite, índices de pesquisa, estado da aplicação e cargas de trabalho com bloqueios frequentes ou escritas síncronas precisam de mais cuidado. Mantenha esses ficheiros no armazenamento local a menos que a aplicação suporte explicitamente o sistema de ficheiros de rede selecionado e tenha testado o reinício, bloqueio e comportamento em falhas.

Monte a partilha no host antes de a passar para os contentores

Para muitas implementações de servidores domésticos, o modelo mais limpo é montar a partilha NAS uma vez no host Docker e depois montar o caminho local nos contentores que dele precisam.

Isto mantém as credenciais, definições de exportação NFS, comportamento de reconexão e ordem de arranque num só lugar. Os contentores só veem um diretório normal, enquanto o host gere o sistema de ficheiros de rede.

O modelo funciona com NFS ou SMB. Os detalhes importantes são que a montagem do host está disponível antes do início do contentor, o UID/GID do contentor pode aceder aos ficheiros montados, e o serviço não escreve silenciosamente numa diretoria local vazia quando o NAS está offline.

Não deixe que ambos os protocolos escrevam os mesmos dados sem um plano

A maioria das plataformas NAS pode expor o mesmo conjunto de dados através de SMB e NFS. Tecnicamente, isto torna possível que utilizadores Windows e aplicações Linux trabalhem com os mesmos ficheiros.

O problema é que os dois caminhos podem criar ficheiros sob identidades e modelos ACL diferentes. Um upload SMB pode pertencer a uma conta NAS com um ACL detalhado, enquanto uma aplicação NFS escreve como UID 1000 com bits de modo POSIX e um umask diferente.

Se ambos os protocolos precisarem de acesso, defina um escritor principal. O outro protocolo pode ser só de leitura, ou ambos podem usar um grupo partilhado cuidadosamente alinhado e um modelo de herança. Sem esse plano, a deriva de permissões tende a aparecer gradualmente em vez de imediatamente.

Usar ambos os protocolos é razoável quando as suas funções permanecem separadas

Um laboratório doméstico misto não precisa de escolher um protocolo para tudo. Executar ambos pode ser mais limpo do que forçar todos os dispositivos a usar o mesmo modelo de acesso.

Uma divisão prática é:

• SMB para pastas familiares Windows e Mac
• SMB para acesso direto por telemóvel, tablet e TV
• NFS para backups Proxmox e hosts Linux
• NFS para montagem de biblioteca só de leitura num servidor de media Linux
• Armazenamento local para bases de dados de aplicações e estado sensível em tempo de execução

Os protocolos devem ser divididos por responsabilidade, não ativados em todo o lado por defeito. Conjuntos de dados separados ou limites claros de leitura/escrita reduzem conflitos de permissões e facilitam a resolução de problemas.

Nenhum dos protocolos deve ser exposto diretamente à internet

SMB e NFS destinam-se a redes locais confiáveis ou caminhos de rede privados. Não faça encaminhamento de porta TCP 445 para SMB nem das portas de serviço NFS de um router doméstico para a internet pública.

Para acesso remoto a ficheiros, ligue-se primeiro à rede doméstica através de uma VPN ou outra camada de acesso privado autenticada. Uma vez que o dispositivo remoto esteja dentro desse caminho confiável, pode usar o mesmo serviço SMB ou NFS disponível na LAN.

Mudar de SMB para NFS não torna a exposição pública mais segura. A segurança depende de limitar os clientes acessíveis, manter o software atualizado, usar autenticação adequada e evitar serviços públicos desnecessários.

Avalie mais do que a velocidade de transferência

Um teste doméstico justo deve usar o mesmo conjunto de dados NAS, cliente, ligação de rede e ficheiros para ambos os protocolos. Caso contrário, o resultado pode estar a medir caminhos de armazenamento ou dispositivos clientes diferentes em vez de SMB e NFS.

Registe mais do que megabytes por segundo. Teste se a montagem se reconecta após suspensão ou reinício, se os nomes de ficheiros e metadados se comportam corretamente, se as aplicações podem criar e eliminar ficheiros e se as permissões permanecem consistentes.

Um protocolo que é cinco por cento mais rápido mas falha regularmente após um reinício pode ser a pior escolha. Fiabilidade, compatibilidade do cliente e o tempo necessário para manter permissões fazem parte do desempenho no mundo real.

Use esta ordem de decisão

Comece pelos clientes em vez de uma preferência de protocolo. Liste todos os computadores, dispositivos móveis, leitores multimédia, servidores, hipervisores e aplicações que precisam dos dados.

Depois, separe a navegação humana do acesso máquina a máquina. Os utilizadores domésticos beneficiam geralmente de contas SMB e exploradores de ficheiros familiares. Serviços Linux geridos podem beneficiar de montagens NFS e controlo de identidade numérica.

Antes de ativar a partilha final, responda a estas perguntas:

1. Utilizadores Windows ou macOS estão a navegar pelos ficheiros?
2. Telemóveis ou aplicações de televisão precisam de acesso direto?
3. A maioria dos clientes são sistemas Linux geridos?
4. Os valores de UID e GID podem permanecer consistentes?
5. A carga de trabalho inclui bases de dados ou ficheiros sensíveis a bloqueios?
6. SMB e NFS vão escrever no mesmo conjunto de dados?
7. Como deve comportar-se a montagem quando o NAS estiver indisponível?
8. O protocolo selecionado pode ser mantido totalmente fora da internet pública?

Para a maioria das casas com dispositivos mistos, comece com SMB. Adicione NFS apenas para uma carga de trabalho específica de Linux, Proxmox, backup ou container que beneficie disso e que possa gerir de forma consistente.

Conclusão Final

O SMB é geralmente a melhor opção padrão para Windows, macOS, telemóveis, tablets, smart TVs e pastas familiares partilhadas. Oferece ampla compatibilidade e um modelo de acesso baseado em conta que é mais fácil de explicar aos utilizadores domésticos.

O NFS é frequentemente a melhor opção para servidores Linux, armazenamento Proxmox, backups automáticos e outros fluxos de trabalho máquina a máquina. As suas vantagens dependem da gestão correta dos valores UID/GID, exportações, opções de montagem e propriedade.

Pode executar ambos os protocolos em casa, mas as suas responsabilidades devem estar claras. Use SMB para pessoas e dispositivos clientes mistos, use NFS para infraestrutura Linux gerida e evite dar a ambos os protocolos acesso de escrita descontrolado ao mesmo conjunto de dados.

Perguntas Frequentes

O NFS é sempre mais rápido que o SMB?

Não. O NFS pode ter melhor desempenho em algumas cargas de trabalho Linux para Linux e com ficheiros pequenos, enquanto o SMB moderno pode ter um desempenho muito bom em Windows e redes com clientes mistos. Teste os ficheiros, clientes, armazenamento e rede que planeia usar.

Devo usar SMB ou NFS para Plex e Jellyfin?

Ambos podem funcionar. Um servidor de media Linux pode beneficiar do NFS durante grandes varreduras de bibliotecas, enquanto o SMB pode ser mais fácil quando aplicações Windows, macOS ou de media player acedem diretamente ao NAS. Streaming de vídeo em grande escala geralmente funciona bem em ambos.

O NFS é melhor para Proxmox?

O NFS é uma escolha comum e natural para backups Proxmox, armazenamento de ISOs, modelos e armazenamento partilhado. Discos de VM e cargas de trabalho com muita escrita ainda requerem testes para latência, comportamento de sincronização e disponibilidade do NAS.

Os contentores Docker podem usar partilhas SMB?

Sim. Monte a partilha SMB no host Docker e faça um bind-mount do caminho resultante para dentro do contentor. Certifique-se de que o utilizador do contentor tem permissão para aceder aos ficheiros montados e que a montagem do host está disponível antes do contentor iniciar.

Por que motivo o NFS mostra permissão negada mesmo que a partilha monte?

A exportação e o caminho de rede podem estar corretos enquanto o UID/GID do cliente não corresponde ao proprietário ou grupo permitido no NAS. Root squashing ou mapeamento de exportação também podem alterar o utilizador efetivo.

Posso ativar SMB e NFS na mesma pasta?

Pode, mas o acesso de escrita simultâneo pode criar conflitos de propriedade, ACL e atributos estendidos. Prefira conjuntos de dados separados, torne um protocolo só de leitura ou crie um modelo de permissões partilhadas cuidadosamente alinhado.

Qual protocolo é mais seguro em casa?

Ambos podem ser seguros numa LAN confiável. O SMB oferece autenticação de utilizador simples e assinatura ou encriptação moderna. O NFS deve ser restrito a clientes confiáveis, com regras de exportação corretas e root squashing. Nenhum dos dois deve ser exposto diretamente à internet.

Qual protocolo deve um principiante escolher?

Escolha SMB quando a casa incluir Windows, macOS, telemóveis ou aplicações de TV. Escolha NFS quando os clientes forem principalmente sistemas Linux e estiver confortável a gerir montagens, valores UID/GID e permissões de exportação.