SMB vs NFS: ¿Qué método de compartición de archivos deberías usar en casa?

Si tu red doméstica incluye PCs Windows, Macs, teléfonos, tabletas y reproductores multimedia, SMB suele ser la mejor opción predeterminada. Se integra naturalmente con exploradores de archivos de escritorio, soporta inicios de sesión basados en usuario y está ampliamente disponible en aplicaciones de consumo.

NFS se vuelve más atractivo cuando los clientes son principalmente servidores Linux, hosts Proxmox u otros sistemas tipo Unix que montan almacenamiento como parte de un flujo de trabajo de infraestructura gestionada. Puede ser eficiente y predecible, pero solo cuando los valores UID/GID, reglas de exportación, comportamiento de montaje y propiedad de archivos están planificados correctamente.

Elige el protocolo según el cliente, no según el benchmark

SMB y NFS permiten que los dispositivos abran archivos almacenados en un NAS o servidor doméstico, pero fueron diseñados para ecosistemas diferentes. SMB es nativo de Windows y está ampliamente soportado por macOS, Linux, gestores de archivos móviles, televisores inteligentes y aplicaciones multimedia. NFS encaja más naturalmente en flujos de trabajo de montaje Linux y Unix.

Esa distinción importa más que una afirmación genérica de que un protocolo es más rápido. Un portátil Windows puede tener una experiencia más fluida y rápida con SMB porque su pila cliente está construida alrededor de SMB. Un servidor Linux que procesa miles de archivos puede ser más fácil de gestionar con NFS porque el directorio remoto se comporta como un montaje Unix normal.

Comienza listando los dispositivos que accederán al recurso compartido y qué harán con él. La exploración humana de archivos, el almacenamiento máquina a máquina, la transmisión de medios, las copias de seguridad, la virtualización y los datos de contenedores no siempre necesitan el mismo protocolo.

SMB suele ser la opción predeterminada más fácil para un hogar mixto

SMB suele ser la opción más sencilla cuando las personas abren carpetas manualmente desde el Explorador de archivos de Windows, Finder de macOS, un teléfono o una aplicación de reproductor multimedia. Los usuarios pueden conectarse con un nombre de usuario y contraseña NAS sin gestionar identidades numéricas de Linux en cada cliente.

Las versiones modernas de SMB también ofrecen funciones más allá de la transferencia básica de archivos, incluyendo ACLs de usuario y grupo, firma, cifrado, bloqueo de archivos, caché y capacidades multicanal. Estas funciones añaden complejidad, pero son útiles cuando varios miembros del hogar necesitan diferentes derechos de acceso.

Para redes mixtas Windows, macOS y Linux, el SMB 3.x moderno puede reducir gran parte de la brecha de rendimiento manteniendo una compatibilidad más amplia con clientes. Eso hace que SMB sea el punto de partida práctico para documentos, fotos familiares, descargas compartidas y navegación general en NAS.

NFS se adapta más naturalmente a flujos de trabajo Linux gestionados

NFS suele ser más fácil de integrar cuando el cliente es un servidor Linux en lugar de una persona navegando carpetas. La compartición puede montarse en un directorio fijo durante el arranque y usarse por software de respaldo, servicios multimedia, hosts de virtualización u otros procesos del sistema.

Esto funciona bien cuando un administrador controla tanto el NAS como los clientes. Puedes definir la subred permitida, alinear usuarios y grupos, elegir opciones de montaje y asegurarte de que los servicios se inicien solo después de que la compartición de red esté disponible.

NFS se vuelve menos conveniente cuando laptops Windows, aplicaciones móviles o múltiples usuarios del hogar necesitan acceso directo. Aunque existen clientes NFS multiplataforma, la configuración y el mapeo de identidad suelen ser menos sencillos que usar SMB en esos dispositivos.

SMB y NFS usan modelos de acceso diferentes

SMB generalmente presenta el acceso como una cuenta de servidor. Un usuario se conecta con credenciales, y el NAS evalúa permisos de compartición, grupos y ACL del sistema de archivos asociados con esa identidad.

Las configuraciones comunes de NFS en el hogar funcionan de manera diferente. La exportación suele estar restringida a hosts o subredes seleccionadas, mientras que el acceso a archivos depende de los valores numéricos Unix UID y GID enviados por el cliente. NFSv4 puede usar configuraciones de identidad y Kerberos más avanzadas, pero muchas configuraciones domésticas siguen confiando en redes de clientes confiables y propiedad numérica.

La distinción práctica es que SMB comúnmente usa ACLs de usuario y grupo, mientras que el acceso NFS está estrechamente ligado a reglas de host y propiedad Linux UID/GID. Ningún modelo es automáticamente mejor, pero cada uno genera diferentes problemas de solución.

La planificación de UID y GID es la principal curva de aprendizaje de NFS

Un nombre de usuario en Linux es solo una etiqueta legible. El sistema de archivos finalmente registra IDs numéricos de usuario y grupo. Dos máquinas pueden tener un usuario llamado media, pero son identidades diferentes si uno usa UID 1000 y el otro usa UID 1001.

Por eso un recurso NFS puede montarse con éxito mientras la creación de archivos aún falla. La ruta de red y la exportación funcionan, pero el usuario presentado por el cliente no coincide con el propietario, grupo o ACL en el NAS.

Antes de usar NFS para varios sistemas Linux, compara los resultados de id username en el cliente y el servidor. El tipo de alineación numérica de UID y GID requerida para recursos NFS con escritura suele ser el paso que falta cuando un usuario puede entrar a un directorio pero no puede crear archivos.

Root Squash no es un fallo aleatorio de permisos

Las exportaciones NFS comúnmente usan root squashing para evitar que un usuario root en una máquina cliente se convierta automáticamente en root en el NAS. Las solicitudes del UID remoto 0 se asignan a una identidad anónima con menos privilegios.

Esto puede sorprender a los usuarios que ejecutan scripts de respaldo, contenedores o comandos administrativos de copia como root. El recurso compartido se monta, pero las escrituras fallan o los archivos aparecen bajo un usuario anónimo.

No desactives root squashing simplemente porque bloquea un flujo de trabajo. Primero determina qué usuario o grupo no root debe poseer los datos, luego otorga a esa identidad el acceso requerido. Usar no_root_squash cede un límite de seguridad importante y no debe tratarse como un atajo normal para servidores domésticos.

NFS no es automáticamente más rápido que SMB

El rendimiento depende del sistema operativo del cliente, la versión del protocolo, el tamaño del archivo, la carga de trabajo de metadatos, el grupo de almacenamiento, la firma o cifrado, las opciones de montaje, el enlace de red y el comportamiento de la aplicación.

Un solo video grande principalmente prueba el rendimiento secuencial. Si ambos protocolos pueden saturar el disco o el enlace de red, sus resultados pueden parecer similares. Un directorio que contiene miles de miniaturas, subtítulos, archivos de metadatos y carpetas anidadas ejerce más presión sobre la búsqueda de archivos, el almacenamiento en caché de atributos y las operaciones pequeñas.

Por eso, un solo punto de referencia no puede decidir la elección para cada hogar. Prueba al menos cuatro cargas de trabajo: una lectura grande, una escritura grande, un directorio con muchos archivos pequeños y la navegación normal de carpetas desde el cliente que realmente usará el recurso compartido.

Los archivos multimedia grandes usualmente no necesitan el protocolo más rápido

Una transmisión típica de película consume mucho menos ancho de banda del que puede proporcionar una conexión Gigabit Ethernet saludable. Si un servidor multimedia no puede reproducir un video de forma fiable en una red local, el cuello de botella puede ser el Wi-Fi, la transcodificación, el rendimiento del disco o la compatibilidad del cliente, en lugar de SMB versus NFS.

La diferencia se vuelve más visible cuando Plex, Jellyfin, Sonarr u otra aplicación escanean una biblioteca grande. El servidor puede abrir miles de pósters, subtítulos, archivos NFO y referencias de base de datos aunque la reproducción real lea un solo archivo multimedia grande de forma secuencial.

Por esta razón, el streaming de archivos grandes puede funcionar bien con cualquiera de los dos protocolos, mientras que los escaneos de bibliotecas de archivos pequeños revelan diferencias mayores. Los servidores multimedia basados en Linux pueden beneficiarse de NFS, pero los clientes Windows y macOS suelen ser más fáciles de soportar mediante SMB.

SMB suele ser mejor para acceso directo desde reproductores multimedia

Si un Apple TV, dispositivo Android TV, teléfono, tableta o portátil se conecta directamente al NAS, SMB suele ser la opción más sencilla. Muchas aplicaciones multimedia pueden explorar recursos SMB con una dirección de servidor, nombre de usuario y contraseña.

El soporte de NFS varía entre aplicaciones y dispositivos. Incluso cuando está disponible, su configuración de exportación y permisos puede ser menos obvia para usuarios domésticos que ingresar credenciales SMB ordinarias.

Esto es independiente de cómo el propio servidor multimedia monta el almacenamiento. Un servidor Linux Jellyfin podría leer su biblioteca a través de NFS, mientras que los dispositivos familiares se conectan solo a la interfaz web o de streaming de Jellyfin. Los dispositivos de usuario final no necesitan acceso directo al protocolo de archivos subyacente.

NFS suele ser una opción natural para el almacenamiento en Proxmox

Proxmox se ejecuta sobre una base Linux, por lo que NFS encaja naturalmente en los flujos de trabajo de respaldo, ISO, plantillas y almacenamiento compartido. Una exportación NAS puede montarse por el host y gestionarse como almacenamiento de infraestructura en lugar de como un recurso compartido de archivos de escritorio.

Esto no significa que cada disco de máquina virtual deba colocarse automáticamente en un servidor NFS doméstico. El almacenamiento de VM depende de la latencia, el comportamiento de escritura sincronizada, la disponibilidad de la red, el diseño de respaldo y cómo debe comportarse el sistema cuando el NAS se reinicia o desconecta.

Para contenedores, también puede ser más limpio montar NFS en el host Proxmox y pasar la ruta de almacenamiento a un contenedor sin privilegios, en lugar de dar a cada contenedor su propia configuración de montaje de red o hacerlo privilegiado solo para montar el recurso compartido.

El almacenamiento en Docker debe elegirse según el tipo de datos

Usar una ruta NAS dentro de Docker no significa automáticamente que NFS sea la opción correcta para cada contenedor. La carga de trabajo importa más que la plataforma del contenedor.

Bibliotecas multimedia, descargas, importaciones, exportaciones, copias de seguridad y otros archivos compartidos grandes pueden funcionar bien con SMB o NFS. Un host Docker Linux puede encontrar NFS más fácil porque la propiedad de archivos se expresa mediante valores UID/GID familiares.

Bases de datos, archivos SQLite, índices de búsqueda, estado de aplicaciones y cargas de trabajo con bloqueo frecuente o escrituras síncronas requieren más precaución. Mantenga esos archivos en almacenamiento local a menos que la aplicación soporte explícitamente el sistema de archivos en red seleccionado y haya probado el reinicio, bloqueo y comportamiento ante fallos.

Monte la carpeta en el host antes de pasarla a los contenedores

Para muchas implementaciones de servidores domésticos, el modelo más limpio es montar la carpeta NAS una vez en el host Docker y luego montar el camino local en los contenedores que lo necesiten.

Esto mantiene las credenciales, configuraciones de exportación NFS, comportamiento de reconexión y orden de inicio en un solo lugar. Los contenedores solo ven un directorio normal, mientras que el host gestiona el sistema de archivos en red.

El modelo funciona con NFS o SMB. Los detalles importantes son que el montaje en el host esté disponible antes de que inicie el contenedor, que el UID/GID del contenedor pueda acceder a los archivos montados y que el servicio no escriba silenciosamente en un directorio local vacío cuando el NAS esté desconectado.

No permita que ambos protocolos escriban los mismos datos sin un plan

La mayoría de las plataformas NAS pueden exponer el mismo conjunto de datos a través de SMB y NFS. Técnicamente, esto permite que usuarios de Windows y aplicaciones Linux trabajen con los mismos archivos.

El problema es que las dos rutas pueden crear archivos bajo identidades y modelos ACL diferentes. Una carga SMB podría pertenecer a una cuenta NAS con un ACL detallado, mientras que una aplicación NFS escribe como UID 1000 con bits de modo POSIX y una umask diferente.

Si ambos protocolos necesitan acceso, defina un escritor principal. El otro protocolo puede ser solo lectura, o ambos pueden usar un grupo compartido cuidadosamente alineado y un modelo de herencia. Sin ese plan, la deriva de permisos tiende a aparecer gradualmente en lugar de inmediato.

Usar ambos protocolos es razonable cuando sus roles permanecen separados

Un laboratorio doméstico mixto no necesita elegir un solo protocolo para todo. Usar ambos puede ser más limpio que forzar a todos los dispositivos a usar el mismo modelo de acceso.

Una división práctica es:

• SMB para carpetas familiares en Windows y Mac
• SMB para acceso directo desde teléfono, tableta y TV
• NFS para copias de seguridad de Proxmox y hosts Linux
• NFS para montaje de biblioteca de solo lectura en un servidor multimedia Linux
• Almacenamiento local para bases de datos de aplicaciones y estado sensible en tiempo de ejecución

Los protocolos deben dividirse por responsabilidad, no habilitarse en todas partes por defecto. Separar conjuntos de datos o establecer límites claros de lectura/escritura reduce conflictos de permisos y facilita la resolución de problemas.

Ninguno de los protocolos debe exponerse directamente a internet

SMB y NFS están destinados a redes locales confiables o rutas de red privadas. No reenvíes el puerto TCP 445 para SMB ni los puertos del servicio NFS desde un router doméstico a internet pública.

Para acceso remoto a archivos, conéctate primero a la red doméstica mediante una VPN u otra capa de acceso privado autenticada. Una vez que el dispositivo remoto esté dentro de esa ruta confiable, puede usar el mismo servicio SMB o NFS disponible en la LAN.

Cambiar de SMB a NFS no hace que la exposición pública sea más segura. La seguridad depende de limitar los clientes accesibles, mantener el software actualizado, usar autenticación adecuada y evitar servicios públicos innecesarios.

Evalúa más que la velocidad de transferencia

Una prueba justa en casa debe usar el mismo conjunto de datos NAS, cliente, enlace de red y archivos para ambos protocolos. De lo contrario, el resultado puede estar midiendo diferentes rutas de almacenamiento o dispositivos cliente en lugar de SMB y NFS.

Registra más que megabytes por segundo. Prueba si el montaje se reconecta después de dormir o reiniciar, si los nombres de archivo y metadatos se comportan correctamente, si las aplicaciones pueden crear y eliminar archivos y si los permisos permanecen consistentes.

Un protocolo que es un cinco por ciento más rápido pero falla regularmente después de un reinicio puede ser la peor opción. La fiabilidad, compatibilidad del cliente y el tiempo requerido para mantener permisos son parte del rendimiento en el mundo real.

Usa este orden de decisión

Comienza con los clientes en lugar de una preferencia de protocolo. Enumera cada computadora, dispositivo móvil, reproductor multimedia, servidor, hipervisor y aplicación que necesite los datos.

Luego separa la navegación humana del acceso máquina a máquina. Los usuarios domésticos generalmente se benefician de cuentas SMB y exploradores de archivos familiares. Los servicios Linux gestionados pueden beneficiarse de montajes NFS y control numérico de identidad.

Antes de habilitar el recurso final, responde estas preguntas:

1. ¿Los usuarios de Windows o macOS navegan por los archivos?
2. ¿Necesitan los teléfonos o aplicaciones de televisión acceso directo?
3. ¿La mayoría de los clientes son sistemas Linux gestionados?
4. ¿Pueden los valores de UID y GID mantenerse consistentes?
5. ¿Incluye la carga de trabajo bases de datos o archivos sensibles a bloqueos?
6. ¿Escribirá SMB y NFS en el mismo conjunto de datos?
7. ¿Cómo debería comportarse el montaje cuando el NAS no esté disponible?
8. ¿Se puede mantener el protocolo seleccionado completamente fuera de internet pública?

Para la mayoría de los hogares con dispositivos mixtos, comienza con SMB. Añade NFS solo para una carga de trabajo específica de Linux, Proxmox, respaldo o contenedor que se beneficie de él y que puedas gestionar de manera consistente.

Conclusión final

SMB suele ser la mejor opción predeterminada para Windows, macOS, teléfonos, tabletas, smart TVs y carpetas familiares compartidas. Ofrece amplia compatibilidad y un modelo de acceso basado en cuentas que es más fácil de explicar a los usuarios del hogar.

NFS suele ser la mejor opción para servidores Linux, almacenamiento Proxmox, copias de seguridad automatizadas y otros flujos de trabajo máquina a máquina. Sus ventajas dependen de valores UID/GID, exportaciones, opciones de montaje y propiedad correctamente gestionados.

Puede ejecutar ambos protocolos en casa, pero sus responsabilidades deben estar claras. Use SMB para personas y dispositivos clientes mixtos, use NFS para infraestructura Linux gestionada y evite dar acceso de escritura sin control a ambos protocolos en el mismo conjunto de datos.

Preguntas frecuentes

¿NFS es siempre más rápido que SMB?

No. NFS puede rendir mejor en algunas cargas de trabajo Linux a Linux y con archivos pequeños, mientras que SMB moderno puede rendir muy bien en Windows y redes con clientes mixtos. Pruebe los archivos, clientes, almacenamiento y red que planea usar.

¿Debería usar SMB o NFS para Plex y Jellyfin?

Cualquiera puede funcionar. Un servidor multimedia Linux puede beneficiarse de NFS durante escaneos grandes de bibliotecas, mientras que SMB puede ser más fácil cuando Windows, macOS o aplicaciones de reproductores multimedia acceden directamente al NAS. La transmisión de video grande suele funcionar bien con ambos.

¿Es NFS mejor para Proxmox?

NFS es una opción común y natural para copias de seguridad de Proxmox, almacenamiento de ISO, plantillas y almacenamiento compartido. Los discos de VM y cargas de trabajo con muchas escrituras aún requieren pruebas de latencia, comportamiento de sincronización y disponibilidad del NAS.

¿Pueden los contenedores Docker usar recursos SMB?

Sí. Monte el recurso SMB en el host Docker y vincule la ruta resultante dentro del contenedor. Asegúrese de que el usuario del contenedor tenga permiso para acceder a los archivos montados y que el montaje del host esté disponible antes de que el contenedor inicie.

¿Por qué NFS muestra permiso denegado aunque el recurso compartido se monte?

La ruta de exportación y red puede ser correcta mientras que el UID/GID del cliente no coincide con el propietario o grupo permitido en el NAS. Root squashing o el mapeo de exportación también pueden cambiar el usuario efectivo.

¿Puedo habilitar SMB y NFS en la misma carpeta?

Puede hacerlo, pero el acceso simultáneo de escritura puede crear conflictos de propiedad, ACL y atributos extendidos. Prefiera conjuntos de datos separados, haga que un protocolo sea de solo lectura o cree un modelo de permisos compartidos cuidadosamente alineado.

¿Qué protocolo es más seguro en casa?

Ambos pueden asegurarse en una LAN confiable. SMB ofrece autenticación de usuario sencilla y firma o cifrado modernos. NFS debe restringirse a clientes confiables, con reglas de exportación correctas y root squashing. Ninguno debe exponerse directamente a internet.

¿Qué protocolo debería elegir un principiante?

Elija SMB cuando el hogar incluya Windows, macOS, teléfonos o aplicaciones de TV. Elija NFS cuando los clientes sean principalmente sistemas Linux y se sienta cómodo gestionando montajes, valores UID/GID y permisos de exportación.