Compartir SMB de Windows a Linux: La lista de verificación de compatibilidad

febrero 6, 2026 • febrero 6, 2026 • Lectura: 30 min • Views: 0

¿Te fue útil?

Algunos cortes no parecen cortes. Parecen una aplicación de Linux que “se bloquea” al leer un archivo desde un recurso compartido de Windows, o un trabajo nocturno que de repente tarda tres horas porque una opción de montaje cambió sin querer.

SMB funciona hasta que deja de funcionar. Entonces te quedas traduciendo entre ACLs de Windows, expectativas de UID/GID en Linux, negociación de dialectos SMB y políticas de seguridad escritas para otra década. Esta lista de verificación es cómo dejas de adivinar y comienzas a demostrar.

El modelo de compatibilidad: qué puede fallar (y por qué siempre son tres cosas)

Cuando un recurso SMB de Windows es consumido por Linux, la compatibilidad no es un interruptor único. Es una pila:

Transporte y negociación: ¿Pueden el cliente y el servidor ponerse de acuerdo en un dialecto SMB (SMB2/SMB3), y pueden autenticarse (NTLM/Kerberos) sobre la ruta de red que realmente tienes?
Autorización e identidad: Una vez autenticado, ¿estás autorizado a hacer lo que intentas? Aquí es donde chocan los permisos de compartido de Windows, las ACLs NTFS y las expectativas de UID/GID en Linux.
Semántica y rendimiento: SMB no es POSIX. El bloqueo de archivos, el caché, la semántica de renombrado, la sensibilidad a mayúsculas/minúsculas y el comportamiento de metadatos son diferentes. Tu aplicación puede estar “correcta” y aun así sorprenderse.

Si te obligas a clasificar cada problema como (1) negociación/auth, (2) autorización, o (3) semántica/rendimiento, dejarás de nadar en la nada. La mayoría de los incidentes son una combinación de cosas.

Una verdad operacional: los problemas de SMB rara vez aparecen durante la prueba en un día soleado donde listaste un directorio y creaste un archivo. Aparecen bajo concurrencia, bajo aplicación de políticas (firmado/cifrado) o durante una rotación de credenciales.

Broma #1: SMB es como una llamada de conferencia: todos dicen que está bien hasta que alguien intenta compartir su pantalla.

Lo que “compatible” realmente significa

Tu dialecto SMB está explícitamente elegido o al menos observado y aceptado (SMB3 es preferible; SMB1 debería estar muerto y enterrado).
Tu método de autenticación está seleccionado intencionalmente (Kerberos para entornos de dominio, NTLM solo cuando sea necesario, nunca “lo que funcionó la última vez”).
Tus opciones de montaje coinciden con tu carga de trabajo: mayormente lectura vs intensa escritura, mucha metadata vs streaming, cliente único vs múltiples escritores.
Tu modelo de permisos está documentado: ¿mapeas las ACLs de Windows o usas una máscara tosca con una cuenta de servicio dedicada?
Tu modo de fallo es conocido: si el servidor se reinicia, ¿el cliente se cuelga? ¿Quieres montajes “hard” o comportamiento “soft”? ¿Cuál es tu presupuesto de tiempo de espera?

Hechos e historia que realmente explican las rarezas actuales

No necesitas trivia para operar sistemas. Pero algunos puntos históricos concretos explican por qué el SMB moderno parece diseñado por un comité en una sala sin ventanas (porque, en cierto modo, lo fue).

SMB no es “originalmente cosa de Windows”. SMB procede de la herencia IBM/Microsoft y se volvió omnipresente mediante el networking de Windows; más tarde, Samba lo convirtió en un estándar multiplataforma en la práctica.
SMB1 (CIFS) es antiguo e inseguro por defecto. Es conversador, ineficiente y su ecosistema está lleno de suposiciones que no resisten los modelos de amenaza modernos.
SMB2 fue una gran rediseñada. Redujo drásticamente el problema de “una operación de archivo = muchas rondas de red” que hacía que SMB1 se sintiera lento en enlaces con latencia alta.
SMB3 añadió funciones empresariales serias. Cifrado, mejor firmado, multichannel y comportamiento de conmutación por error mejorado lo empujaron al territorio de “protocolo de centro de datos”.
Los permisos de Windows son ACL-primero. Windows se construyó alrededor de ACLs ricas; Linux creció con bits de modo POSIX. Puente entre ambos siempre es una traducción, nunca una coincidencia perfecta.
Los opportunistic locks (oplocks) evolucionaron hacia leases. El caché del cliente cambió con el tiempo, y la interacción entre caché y escrituras por múltiples clientes sigue siendo donde los errores de consistencia proliferan.
Los espacios de nombres DFS complican “¿con qué servidor estoy hablando?” Una ruta puede ser una referencia, no un servidor. Los clientes Linux pueden seguir referencias DFS, pero el comportamiento varía según el cliente y la configuración.
La sensibilidad a mayúsculas/minúsculas es un argumento filosófico con consecuencias. Windows es tradicionalmente insensible a mayúsculas; Linux es sensible. SMB debe emular una sobre la otra, y aparecen casos límite en sistemas de compilación y almacenes de artefactos.
El firmado SMB se volvió más común debido a baselines de seguridad. Muchas organizaciones ahora requieren firmado; mejora la integridad pero puede costar rendimiento y CPU en servidores antiguos o clientes pequeños.

Estos no son hechos de museo. Se mapean directamente a “¿por qué este montaje es lento?”, “¿por qué falla el renombrado?” y “¿por qué un cambio de política dejó inutilizada a media flota?”.

Guía de diagnóstico rápido (encuentra el cuello de botella en minutos)

Este es el orden que funciona en producción: comienza con las señales menos ambiguas y luego profundiza. No empieces cambiando opciones de montaje. Observa primero.

Primero: establece a qué estás realmente conectado

Confirma el servidor objetivo y la ruta del recurso compartido (cuidado con DFS).
Confirma el dialecto SMB negociado y el modo de seguridad (firmado/cifrado).
Confirma si Kerberos está en juego o si silenciosamente caíste a NTLM.

Segundo: divide el problema en red vs servidor vs cliente

Red: latencia, pérdida de paquetes, desajuste de MTU, enrutamiento asimétrico.
Servidor: CPU (crypto/firmado), cuellos de botella en disco, escaneo antivirus, snapshots VSS, límites del servidor SMB.
Cliente: opciones de montaje (cache/actimeo), expiración de credenciales, DNS, comportamiento del módulo kernel cifs.

Tercero: reproduce con una carga mínima

Listado de directorio grande (pesado en metadata).
Lectura/escritura secuencial grande única (rendimiento).
Miles de creaciones de archivos pequeños (metadata + bloqueo).

Cuarto: decide qué vas a cambiar

Si la negociación/auth está mal: arregla DNS/SPN/Kerberos, o forza un dialecto.
Si la autorización está mal: arregla permisos de compartido/ACLs NTFS o usa un modelo de cuenta de servicio.
Si la semántica/rendimiento está mal: ajusta opciones de caché/leases, revisa expectativas de la app o migra la carga fuera de SMB.

Idea parafraseada de Werner Vogels (fiabilidad): Diseña para el fracaso; asume que las cosas se romperán y construye sistemas que sigan funcionando.

Listas de verificación / plan paso a paso (constrúyelo bien, mantenlo bien)

Lista A: Requisitos del lado servidor (Windows)

SMB1 deshabilitado salvo que soportes dispositivos legacy que hayas puesto en cuarentena.
SMB2/SMB3 habilitados (por defecto en Windows Server moderno, pero verifica las políticas).
Permisos de compartido establecidos intencionalmente (no dejes “Everyone: Full Control” y pretendas que solo las ACLs NTFS te salvarán).
ACLs NTFS alineadas con el modelo de identidad de servicio que elegiste.
Políticas de firmado/cifrado conocidas: requerido/opcional, y de dónde vendrá la CPU.
Exclusiones de antivirus consideradas para directorios de alta rotación build/temp (con aceptación de riesgo).
Sincronización de tiempo correcta (a Kerberos no le gusta viajar en el tiempo).

Lista B: Requisitos del lado cliente (Linux)

cifs-utils instalado y el kernel soporta las características SMB3 requeridas.
DNS funciona y la resolución inversa no está rota si se usa Kerberos.
Reloj sincronizado (chrony/systemd-timesyncd) para evitar fallos de Kerberos.
Manejo de credenciales decidido: keytab, archivo de credenciales o integración con gestor de secretos.
Opciones de montaje documentadas y desplegadas de forma consistente (unidades systemd o fstab gestionadas por CM).
Ganchos de observabilidad: sabe dónde van los logs del kernel; ten un conjunto estándar de comandos para “bundle de debug SMB”.

Lista C: Compatibilidad de la carga de trabajo

¿Tu app asume POSIX? Si depende de rename atómico entre directorios, enlaces duros o semánticas estrictas de bloqueo, pruébalo. No teorices.
Modelo de concurrencia entendido: escritor único/lectores múltiples vs multi-writer.
Escala de directorio: SMB puede manejar directorios grandes, pero operaciones pesadas en metadata pueden ser brutales cuando el caché es conservador o el firmado es obligatorio.
Reglas de nombres de archivo: Windows prohíbe ciertos caracteres; Linux no le importa. Tu pipeline puede verse afectado más adelante.

Plan de despliegue paso a paso (con opinión)

Elige el modelo de autenticación: Kerberos con AD para producción, o una cuenta local/del recurso compartido dedicada solo para casos aislados.
Elige el dialecto: SMB3 salvo que tengas una razón contundente para no hacerlo.
Elige la estrategia de permisos:
- Estrategia 1 (cuenta de servicio): la más sencilla; usa una cuenta AD dedicada, permisos toscos y trata el recurso como una dependencia de la app.
- Estrategia 2 (por usuario): más compleja; requiere mapeo de identidad, Kerberos y ACLs sensatas.
Elige el comportamiento de montaje: prefiere hard para datos críticos; usa timeouts con intención.
Prueba de carga con la forma real de la carga: recorridos de directorios, tormentas de archivos pequeños, compilaciones paralelas, lo que haga tu app.
Instrumenta y documenta: cómo se ve “bien” (dialecto, firmado, rendimiento típico, latencia típica).
Congela las opciones de montaje y despliega vía automatización. La deriva es el asesino silencioso.

Tareas prácticas con comandos: pruebas, salidas y decisiones

Abajo hay tareas prácticas que puedes ejecutar en un cliente Linux. Cada una incluye: comando, salida de ejemplo, lo que significa y la decisión que tomas.

Task 1: Confirmar conectividad básica de red (y evitar depurar SMB sobre una ruta muerta)

cr0x@server:~$ ping -c 3 fs01.corp.example
PING fs01.corp.example (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=127 time=1.12 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=127 time=1.08 ms
64 bytes from 10.20.30.40: icmp_seq=3 ttl=127 time=1.05 ms

--- fs01.corp.example ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 1.05/1.08/1.12/0.03 ms

Significado: Baja latencia, sin pérdida. Suficiente para continuar.

Decisión: Si la latencia es alta o hay pérdida, detente aquí y arregla la red antes de tocar las configuraciones SMB.

Task 2: Verificar conectividad TCP hacia SMB (445)

cr0x@server:~$ nc -vz fs01.corp.example 445
Connection to fs01.corp.example 445 port [tcp/microsoft-ds] succeeded!

Significado: Puedes alcanzar el servicio SMB.

Decisión: Si falla, revisa reglas de firewall, Windows Defender Firewall, grupos de seguridad o un balanceador mal enroutado.

Task 3: Comprobar resolución de nombres (Kerberos y SMB odian el DNS ambiguo)

cr0x@server:~$ getent hosts fs01.corp.example
10.20.30.40     fs01.corp.example fs01

Significado: El nombre resuelve a una sola IP. Predecible.

Decisión: Si devuelve múltiples IPs inesperadamente, podrías estar alcanzando el servidor equivocado (especialmente con DFS o roles clusterizados). Fija el nombre correcto o arregla DNS.

Task 4: Descubrir los recursos compartidos disponibles (y si la enumeración está bloqueada)

cr0x@server:~$ smbclient -L //fs01.corp.example -U 'CORP\buildsvc%REDACTED'
	Sharename       Type      Comment
	---------       ----      -------
	builds          Disk      Build artifacts
	IPC$            IPC       Remote IPC
SMB1 disabled -- no workgroup available

Significado: El recurso existe; SMB1 está deshabilitado (bien). Las credenciales funcionan.

Decisión: Si aparece NT_STATUS_LOGON_FAILURE, es autenticación. Si los recursos no se muestran pero crees que existen, son permisos o políticas del servidor bloqueando la enumeración.

Task 5: Confirmar la negociación de dialecto SMB desde el lado cliente (después de montar)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/builds /mnt/builds -o username=buildsvc,domain=CORP,vers=3.1.1
cr0x@server:~$ cat /proc/fs/cifs/DebugData | sed -n '1,40p'
=== CIFS DebugData ===
Number of CIFS mounts: 1
...
SMB3.11 dialect
Security Mode: Signing enabled
...

Significado: Estás en SMB 3.1.1 y el firmado está habilitado.

Decisión: Si se negocia SMB2.0 o más antiguo inesperadamente, investiga política del servidor, kernel del cliente o middleboxes. Si firmado/cifrado es requerido, calcula CPU.

Task 6: Comprobar estado del ticket Kerberos (si usas AD)

cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: buildsvc@CORP.EXAMPLE

Valid starting       Expires              Service principal
02/05/2026 08:10:02  02/05/2026 18:10:02  krbtgt/CORP.EXAMPLE@CORP.EXAMPLE

Significado: Tienes un TGT válido; Kerberos debería funcionar si SPNs y DNS son sensatos.

Decisión: Si no hay ticket, no asumas que SMB “simplemente usará NTLM”. Decide si la caída es aceptable. En entornos regulados, a menudo no lo es.

Task 7: Montar con Kerberos explícito (reduce sorpresas por caídas silenciosas)

cr0x@server:~$ sudo umount /mnt/builds
cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/builds /mnt/builds -o sec=krb5,vers=3.1.1,cruid=$(id -u)
cr0x@server:~$ mount | grep /mnt/builds
//fs01.corp.example/builds on /mnt/builds type cifs (rw,relatime,vers=3.1.1,sec=krb5,cache=strict,username=buildsvc,domain=CORP,uid=0,noforceuid,gid=0,noforcegid,addr=10.20.30.40)

Significado: El montaje está usando Kerberos (sec=krb5).

Decisión: Si el montaje falla con Permission denied, sospecha problemas con SPN, desajuste de tiempo o que el servidor no acepta Kerberos para ese recurso.

Task 8: Validar lectura/escritura y observar latencia en operaciones pesadas en metadata

cr0x@server:~$ time sh -c 'for i in $(seq 1 2000); do : > /mnt/builds/.meta_test_$i; done'
real	0m6.412s
user	0m0.102s
sys	0m0.580s
cr0x@server:~$ rm -f /mnt/builds/.meta_test_*

Significado: Esto mide la latencia de creación bajo tus actuales ajustes de montaje/seguridad.

Decisión: Si esto es lento, no persigas el throughput bruto. Tu cuello de botella son las rondas de metadata, la sobrecarga de firmado/cifrado o el escaneo del lado servidor.

Task 9: Medir throughput secuencial (lectura)

cr0x@server:~$ dd if=/mnt/builds/large.iso of=/dev/null bs=16M status=progress
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3 s, 357 MB/s
cr0x@server:~$ echo $?
0

Significado: El throughput de lectura grande es saludable.

Decisión: Si el throughput es bajo pero la metadata está bien, revisa CPU por firmado/cifrado y offloads de NIC, además del rendimiento del almacenamiento del servidor.

Task 10: Revisar errores CIFS del lado cliente en logs del kernel

cr0x@server:~$ dmesg -T | tail -n 12
[Wed Feb  5 08:31:22 2026] CIFS: VFS: \\fs01.corp.example Send error in SessSetup = -13
[Wed Feb  5 08:31:22 2026] CIFS: VFS: cifs_mount failed w/return code = -13
[Wed Feb  5 08:31:22 2026] CIFS: VFS: \\fs01.corp.example error -13 on ioctl to get interface list

Significado: -13 es permiso denegado. Eso es auth o autorización, no “Linux raro”.

Decisión: Pasa a comprobaciones de identidad/auth: ticket Kerberos, nombre de usuario/dominio, permisos de compartido del servidor, ACLs NTFS.

Task 11: Inspeccionar sesiones CIFS actuales y estadísticas por recurso

cr0x@server:~$ cat /proc/fs/cifs/Stats
Resources in use
CIFS Session: 1
Share (unique mount targets): 1
SMB Request/Response Buffer: 2 Pool size: 2097152
SMB Small Req Buffer: 0 Pool size: 262144
Total vfs operations: 18243
Total oplock breaks: 3

Significado: Confirma actividad; los oplock breaks indican eventos de coordinación de caché.

Decisión: Si los oplock breaks se disparan durante cargas multi-writer y el rendimiento cae, revisa expectativas de caché/leases y el comportamiento de la aplicación.

Task 12: Confirmar requisito del servidor para firmado/cifrado (desde la experiencia del cliente)

cr0x@server:~$ sudo umount /mnt/builds
cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/builds /mnt/builds -o username=buildsvc,domain=CORP,vers=3.1.1,seal
cr0x@server:~$ cat /proc/fs/cifs/DebugData | grep -E 'Security Mode|SMB3'
SMB3.11 dialect
Security Mode: Signing enabled

Significado: seal solicita cifrado. Algunas configuraciones muestran el estado de cifrado de forma diferente, pero que falle el montaje cuando se requiere cifrado es una pista.

Decisión: Si el montaje falla sin seal pero funciona con él (o viceversa), tienes un desajuste de políticas: el servidor requiere cifrado o lo rechaza para ese recurso.

Task 13: Detectar si estás alcanzando referrals DFS (trampa común de “servidor equivocado”)

cr0x@server:~$ smbclient -k -c 'ls' //corp.example/dfsroot
  .                                   D        0  Wed Feb  5 08:40:01 2026
  ..                                  D        0  Wed Feb  5 08:40:01 2026
  builds                              D        0  Wed Feb  5 08:40:01 2026

cr0x@server:~$ smbclient -k -c 'cd builds; ls' //corp.example/dfsroot
cd \builds\
Domain=[CORP] OS=[Windows Server 2022 Standard] Server=[Windows Server 2022 Standard]
  .                                   D        0  Wed Feb  5 08:40:05 2026
  ..                                  D        0  Wed Feb  5 08:40:05 2026

Significado: Estás usando un namespace DFS y se te refiere a un servidor backend.

Decisión: Si el rendimiento difiere entre clientes, confirma que todos resuelven las referrals igual. Fija a un objetivo específico para pruebas.

Task 14: Validar sincronización de tiempo rápidamente (fallos Kerberos aman el desajuste de 5 minutos)

cr0x@server:~$ timedatectl
               Local time: Wed 2026-02-05 08:42:10 UTC
           Universal time: Wed 2026-02-05 08:42:10 UTC
                 RTC time: Wed 2026-02-05 08:42:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: El reloj está sincronizado. Bien.

Decisión: Si no está sincronizado, arregla el tiempo antes de culpar a Samba, CIFS o AD. Kerberos es implacable por diseño.

Task 15: Confirmar comportamiento de bloqueo de archivos (prueba rápida de sanidad para apps multi-writer)

cr0x@server:~$ python3 - << 'PY'
import fcntl, time
f=open("/mnt/builds/locktest.txt","w")
fcntl.flock(f, fcntl.LOCK_EX|fcntl.LOCK_NB)
print("locked")
time.sleep(2)
print("done")
PY
locked
done

Significado: Esto prueba la vista de bloqueos del cliente; no es una prueba completa de bloqueo distribuido, pero detecta comportamientos obvios.

Decisión: Si tu app requiere bloqueos por asesoría estrictos entre múltiples clientes, ejecuta una prueba real multi-host; las semánticas SMB pueden diferir de las del FS local.

Permisos y mapeo de identidad: donde empiezan la mayoría de los “funcionaba ayer”

Linux quiere un UID, un GID y bits de modo. Windows quiere una ACL con herencia, ACEs de denegación y anidamiento de grupos que puede leerse como un documento legal. SMB está en el medio traduciendo, y esa traducción es donde los humanos introducen mitos.

Elige una estrategia de permisos y apégate a ella

Estrategia 1: Cuenta de servicio + mapeo toscamente (recomendada para apps)

Usa una cuenta AD dedicada (o gMSA donde corresponda) para el consumidor Linux.
Concede esa identidad derechos NTFS explícitos en la carpeta de respaldo y permisos de compartido mínimos.
Monta con esa identidad; mapea todo a un UID/GID fijo en Linux mediante opciones de montaje si la app espera propiedad.
Acepta que los usuarios de Linux no son “usuarios reales” de ese recurso; la app lo es.

Estrategia 2: Acceso por usuario vía Kerberos + mapeo de identidad (recomendada para flujos interactivos multiusuario)

Autenticación Kerberos por usuario y potencialmente montajes multiuser.
Requiere nombre de principal consistente, caches de credenciales y gestión cuidadosa del ciclo de vida.
Requiere que entiendas qué significa “chmod” sobre una ACL de Windows (a menudo: no lo que esperas).

Permisos de compartido vs ACLs NTFS: deja de discutir, usa ambos

La postura operativa correcta es:

Permisos de compartido como una puerta tosca (quién puede entrar).
ACLs NTFS como la autorización real (qué se puede hacer dentro).

Permisos de compartido demasiado permisivos no son una catástrofe si las ACLs NTFS son correctas, pero aumentan el radio de explosión y complican la respuesta a incidentes. Permisos de compartido demasiado restrictivos crean confusos “funciona en Explorer, falla en Linux” porque diferentes rutas de acceso y membresías de grupo se evalúan distinto.

Propiedad presentada en Linux: decide si quieres verdad o conveniencia

Cuando montas con CIFS, Linux mostrará propiedad y permisos basados en opciones de montaje y metadatos proporcionados por el servidor. Muchos equipos eligen conveniencia:

uid= y gid= para fijar la propiedad para el usuario de la app
file_mode= y dir_mode= para evitar “permiso denegado” dentro del contenedor/ runtime

Esto puede estar bien. También puede enmascarar problemas reales de autorización hasta que la app intenta una operación que la ACL de Windows niega. Si fijas todo a 0777 no resolviste permisos; los ocultaste tras una cortina.

Sensibilidad a mayúsculas y reglas de nombres: el corte lento

Windows normalmente trata Foo.txt y foo.txt como iguales. Linux no. Los sistemas de compilación, almacenes de artefactos y toolchains a menudo asumen semánticas de Linux. Si los pones en SMB respaldado por Windows puedes obtener:

Entradas que parecen duplicadas y colisionan durante checkout/extracción
Compilaciones no reproducibles dependiendo del orden de operaciones del cliente
Herramientas que “corrigen” capitalización y rompen consumidores

Para CI y almacenamiento de artefactos, prefiere convenciones de nombres que sean estables respecto a mayúsculas y evita caracteres prohibidos por Windows. Suena aburrido. Lo es. También evita arqueología en Slack a las 2 a.m.

Seguridad: firmado, cifrado, Kerberos y lo que las políticas hacen a la latencia

Las configuraciones de seguridad son configuraciones de compatibilidad. También pueden ser configuraciones de rendimiento. Trátalas como insumos de planificación de capacidad para producción, no como casillas a marcar.

Firmado: integridad con un coste

El firmado SMB protege contra la manipulación. Muchos baselines de Windows lo requieren. Los trade-offs:

Coste en CPU en ambos extremos; cuanto más pequeño es el equipo, más doloroso es el impuesto.
Sensibilidad a la latencia: cargas pesadas en metadata pueden amplificar la sobrecarga.
Sorpresa al depurar: los clientes pueden negociar firmado habilitado incluso cuando no es requerido; políticas “requeridas” pueden romper clientes antiguos.

Consejo operativo: si el firmado es requerido, mide la CPU en el servidor de archivos Windows durante el pico. Si los picos de CPU se correlacionan con la caída del throughput SMB, encontraste tu cuello de botella.

Cifrado (“seal”): confidencialidad con aristas

El cifrado SMB3 es excelente cuando lo necesitas. Pero no es gratis, y cambia los modos de fallo:

Limitaciones de CPU y a veces de offload de NIC pueden limitar el throughput.
Políticas mal configuradas causan “funciona en un servidor, falla en otro” según requisitos de cifrado a nivel de recurso.
El troubleshooting se vuelve más ruidoso porque las capturas de paquetes son menos informativas.

Kerberos: genial cuando funciona, implacable cuando no

Kerberos es la respuesta correcta en entornos de dominio. Te da autenticación fuerte, confianza mutua y menos pecados del manejo de contraseñas. También tiene tres desencadenantes clásicos de fallo:

Desajuste de tiempo (arregla NTP primero, siempre)
Desajuste DNS/SPN (el nombre que montas debe coincidir con el principal del servicio)
Ciclo de vida de credenciales (tickets expiran; keytabs se desincronizan; servicios reinician en el peor momento)

NTLM: el “lo limpiaremos después” que se vuelve arquitectura permanente

NTLM puede ser aceptable en entornos aislados y de bajo riesgo. En producción de dominio, es una trampa si no la controlas:

Más difícil de aplicar expectativas modernas de seguridad.
A menudo depende de archivos de contraseñas en disco.
Más frágil frente a cambios de política (algunas organizaciones reducen o bloquean el uso de NTLM).

Toma una decisión: o eres Kerberos-primero, o te apuntas a deuda operacional por NTLM. Ambas son elecciones. Solo una escala con educación.

Rendimiento y fiabilidad: caché, oplocks/leases, multichannel y lo aburrido

Los problemas de rendimiento de SMB generalmente no son “ancho de banda”. Son un desajuste entre la forma de la carga de trabajo y el comportamiento del protocolo, empeorado por la sobrecarga de seguridad y la latencia en metadata.

La metadata es el impuesto oculto

Listar directorios, stat de archivos, comprobar timestamps y crear archivos pequeños son operaciones pesadas en metadata. SMB puede manejarlas, pero cada operación puede requerir rondas de red y evaluación de ACLs del servidor.

Si tu carga es un sistema de compilación que crea decenas de miles de archivos pequeños, SMB te cobrará en latencia a menos que diseñes alrededor: workspace local + publicación de artefactos, o al menos opciones de caché que sean seguras.

Modos de caché: “cache=none” no es valentía, es una decisión de carga

Los montajes CIFS en Linux soportan estrategias de caché. La elección correcta depende de cuántos clientes escriben concurrentemente y cuánto valoras la coherencia estricta.

Coherencia estricta suele costar rendimiento en cargas pesadas en metadata.
Caché agresivo puede producir comportamientos confusos de “el archivo está en un cliente pero no en otro” si no se manejan las semánticas multi-writer.

En producción, prefiere la corrección para datos compartidos y mutables. Para recursos mayormente de lectura, puedes tolerar más caché.

Oplocks/leases: amigo del rendimiento, enemigo de setups multi-writer ingenuos

Los oplocks (y los leases más nuevos) permiten a los clientes cachear datos y metadata. Genial para rendimiento. Pero cuando múltiples clientes escriben, el servidor debe romper oplocks y coordinar. Si tu app hace muchos ciclos abrir/cerrar, puedes ver thrash.

Vigila los oplock breaks en las estadísticas CIFS y correlaciónalos con las quejas. Si coincide, puede que necesites rediseñar el flujo de trabajo o ajustar expectativas de caché.

Multichannel: potencialmente genial, a menudo malentendido

SMB multichannel puede usar múltiples rutas de red/NICs para throughput y resiliencia. Pero debe ser soportado y configurado correctamente en ambos extremos, y la red debe comportarse de forma predecible. Si tienes MTUs desajustadas o caminos asimétricos, multichannel puede convertir “rápido” en “inestable”.

Fiabilidad ante reinicios del servidor: tus flags de montaje deciden la experiencia de usuario

Si el servidor de archivos Windows se reinicia, ¿qué debería hacer Linux?

Comportamiento hard puede causar que procesos se cuelguen mientras el recurso se recupera. A veces eso es correcto (no corrompas escrituras), pero puede parecer un corte.
Comportamiento más soft puede generar errores de I/O que la aplicación debe manejar. Muchas aplicaciones no lo hacen.

Decide según la capacidad de tu app para tolerar errores. Luego documéntalo para que el siguiente de guardia no lo “arregle” por accidente.

Broma #2: Si quieres emoción, ajusta rendimiento un viernes. Si quieres dormir, no lo hagas.

Tres mini-historias corporativas (anonimizadas, dolorosamente plausibles)

Mini-historia 1: El incidente causado por una suposición equivocada

Tenían una flota Linux montando un recurso de Windows que alojaba paquetes de configuración. Nada sofisticado: leer un archivo al inicio, vigilar cambios, recargar ocasionalmente. Funcionó durante meses, que es cómo sabes que lo siguiente va a doler.

Un proyecto de hardening en Windows pasó y “estandarizó” configuraciones SMB. El equipo asumió que era inocuo porque los clientes Windows seguían mapeando unidades bien. El lado Linux empezó a registrar errores intermitentes de permiso, pero solo en algunos hosts.

La suposición equivocada: “Si las credenciales funcionan una vez, el montaje es estable.” En realidad, algunos clientes caían silenciosamente de Kerberos a NTLM dependiendo de DNS y resolución de SPN. Tras el hardening, NTLM se restringió más agresivamente. Hosts con caminos Kerberos limpios siguieron funcionando; hosts con entradas DNS desordenadas o montando vía alias se rompieron.

On-call inicialmente persiguió opciones de montaje CIFS, alternando caché y versiones de dialecto. No importó. La falla era la negociación de autenticación bajo cambios de política.

La solución fue poco glamorosa y decisiva: estandarizar el objetivo de montaje al FQDN correcto del servidor, arreglar registros DNS, imponer sec=krb5 y fallar montajes ruidosamente cuando Kerberos no estuviera disponible. El incidente terminó no por “hacer SMB más permisivo”, sino por eliminar la ambigüedad.

Mini-historia 2: La optimización que salió mal

Un grupo de ingeniería de datos tenía tiempos de inicio lentos porque su pipeline enumeraba un árbol de directorios de pequeños archivos de referencia en un recurso SMB. Alguien notó mucho tiempo en operaciones de metadata y decidió “hacerlo más rápido” aflojando controles de caché.

Cambiaron las opciones de montaje para reducir la frecuencia de revalidación de atributos. El inicio se aceleró. Todos celebraron. Dos semanas después, jobs downstream empezaron a consumir datos de referencia obsoletos por ventanas cortas tras actualizaciones. No siempre. Suficiente para corromper la confianza.

El revés no fue que el caché sea malo. Fue que aplicaron un arreglo de rendimiento del lado cliente a un flujo que asumía coherencia global inmediata entre múltiples lectores. El lado Windows actualizaba archivos en sitio; clientes Linux a veces no veían cambios rápidamente debido al caché relajado de atributos.

La remediación fue cambiar el patrón de publicación: publicar datos de referencia mediante intercambio atómico de directorio (nueva versión en nuevo directorio, luego actualizar un archivo puntero), o usar rutas versionadas. Revirtieron el caché agresivo para el puntero “current” compartido y conservaron optimizaciones para directorios inmutables versionados.

Resultado neto: el rendimiento mejoró y la corrección volvió, pero solo después de que reconocieron que el filesystem no era el contrato. El patrón de publicación de datos sí lo era.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de plataforma gestionaba montajes SMB para un entorno mixto Windows/Linux: directorios home de desarrolladores, herramientas compartidas y artefactos de CI. No glamoroso. El tipo de sistema del que todos se quejan y nadie quiere poseer.

Tenían una regla: cada montaje se declara en la gestión de configuración, incluye vers= y sec= explícitos, y viene con un pequeño script de validación que corre al arranque y alerta si el dialecto negociado o el modo de seguridad cambia. Nada de “defaults”. Nada de “ya veremos”.

Un martes, una actualización del SO cambió el comportamiento del cliente para un subconjunto pequeño de hosts (actualizaciones del kernel + módulo cifs pueden hacer eso). El script de validación notó que la negociación de firmado cambió en comparación con la línea base. No estaba roto aún, pero diferente.

Pausaron el despliegue, probaron el impacto en rendimiento con firmado requerido y coordinaron con el equipo Windows para confirmar políticas. Cuando el resto de la organización más tarde cambió un requerimiento de firmado globalmente, su flota no se desplomó; ya había sido testeada, planificada en capacidad y documentada.

Así es como se ve lo aburrido cuando está bien hecho: detectas la deriva antes de que sea un incidente y puedes dormir.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “Permission denied” al montar, pero smbclient funciona

Causa raíz: Diferentes rutas de auth (Kerberos vs NTLM), o smbclient usando credenciales explícitas mientras el montaje usa comportamiento implícito/fallback.

Solución: Monta con sec=krb5 explícito (o usuario/dominio explícito), verifica klist y revisa dmesg por errores SessSetup.

2) Síntoma: Listados de directorio dolorosamente lentos; lecturas de archivos grandes bien

Causa raíz: Latencia de metadata amplificada por firmado/cifrado, escaneo antivirus o caché de atributos conservador.

Solución: Benchmark de operaciones de metadata; considera ajustar estrategia de caché para árboles mayormente de lectura, reduce churn de archivos pequeños o rediseña la carga para evitar grandes recorridos de directorio en SMB.

3) Síntoma: “Stale file handle” o retrasos extraños de visibilidad entre clientes

Causa raíz: Caché y oplocks/leases interactuando con escrituras multi-cliente; aplicaciones que asumen coherencia POSIX.

Solución: Usa patrones de publicación más seguros (directorios versionados, actualizaciones de puntero atómicas), asegura que los clientes usen caché coherente cuando sea necesario y prueba explícitamente consistencia multi-host.

4) Síntoma: El montaje falla intermitentemente después de cambios de contraseña

Causa raíz: Contraseña almacenada en un archivo de credenciales; rotación sucedió; montajes no se actualizaron; reintentos de systemd crean efecto thundering herd.

Solución: Prefiere keytabs Kerberos o secretos gestionados; añade una estrategia de reintento controlada; alerta sobre fallos de auth antes de que la cola de jobs se acumule.

5) Síntoma: Funciona por dirección IP, falla por nombre de host (especialmente Kerberos)

Causa raíz: SPN ligado al hostname; usar IP rompe el match de nombres de Kerberos; alias DNS no registrado en el SPN.

Solución: Usa el FQDN canónico; asegura que los SPNs correctos existan para alias y mantén DNS forward/reverse saneado.

6) Síntoma: Throughput colapsa después de habilitar firmado o cifrado

Causa raíz: CPU limitada por crypto/firmado en servidor o cliente; hardware antiguo o límites de VM.

Solución: Mide CPU durante la transferencia; escala CPU del servidor de archivos, reparte la carga o aplica cifrado selectivamente a nivel de recurso cuando sea requerido.

7) Síntoma: Errores aleatorios de la aplicación durante renombrados o reemplazo de archivos

Causa raíz: Semánticas de renombrado/bloqueo de SMB y evaluación de ACLs de Windows difieren de las expectativas POSIX locales; algunos patrones son racy entre clientes.

Solución: Ajusta la lógica de la aplicación (escribe temp + fsync-equivalente + rename dentro del mismo directorio), evita suposiciones atómicas entre directorios y prueba bajo concurrencia.

8) Síntoma: El montaje tiene éxito, pero los archivos muestran propiedad/modos incorrectos en Linux

Causa raíz: Uso de opciones uid/gid y file_mode/dir_mode que enmascaran o sobrescriben metadatos esperados; o mapeo de IDs faltante.

Solución: Decide si quieres propiedad fijada para una app o mapeo de identidad real; establece las opciones en consecuencia y documenta la intención.

Preguntas frecuentes

1) ¿Debo usar alguna vez SMB1/CIFS desde Linux a Windows?

Casi nunca. Si necesitas SMB1 por un dispositivo legacy, aíslalo y trátalo como una excepción de riesgo. Para compatibilidad Windows-Linux, apunta a SMB3.

2) ¿Qué versión de SMB debo forzar en el montaje Linux?

Prefiere vers=3.1.1 cuando ambos lados lo soporten. Si ves negociación extraña o un servidor antiguo, baja a vers=3.0 o vers=2.1 intencionalmente. No lo dejes sin especificar en producción; la negociación implícita cambia con actualizaciones del cliente.

3) El montaje Kerberos falla pero usuario/contraseña funciona. ¿Por qué?

Kerberos es estricto con nombres y tiempo. Revisa sincronización de tiempo, DNS y si el SPN coincide con el nombre de servidor que montaste. La auth por contraseña funcionando típicamente indica que el servidor es accesible y el recurso existe; no valida la corrección de Kerberos.

4) ¿Por qué mi app Linux ve “permission denied” aun cuando la ACL de Windows lo permite?

O te autenticaste como una identidad diferente de la que crees (fallback auth), o los permisos de compartido te bloquean aunque las ACLs NTFS permitan, o estás alcanzando un servidor distinto vía referral DFS.

5) ¿Es seguro usar caché cliente agresivo para velocidad?

Seguro para contenido inmutable o versionado. Arriesgado para directorios compartidos mutables “current” donde múltiples clientes esperan visibilidad inmediata. Si la corrección importa, rediseña el patrón de publicación antes de tocar los controles de caché.

6) ¿Por qué las operaciones de directorio son lentas comparadas con NFS o discos locales?

Las operaciones SMB a menudo incluyen más comprobaciones del lado servidor y pueden requerir más rondas, especialmente con firmado/cifrado y evaluación de ACLs complejas. Cargas con muchos archivos pequeños y metadata lo exponen inmediatamente.

7) ¿Cómo manejo credenciales de forma segura en Linux?

En entornos de dominio: Kerberos con keytabs para servicios, o caches Kerberos por usuario para uso interactivo. Evita contraseñas estáticas en archivos cuando puedas. Si debes usarlas, restringe permisos y rota con automatización.

8) ¿Puedo usar SMB para workspaces de CI?

Puedes, pero probablemente no deberías para el workspace activo de build. CI genera archivos pequeños, churn de locks y tormentas de metadata. Usa discos locales para workspaces y publica artefactos a SMB (mayormente lectura) si ese es tu punto de integración.

9) ¿Cuál es la forma más limpia de evitar problemas de “servidor equivocado”?

Usa el FQDN canónico del rol del servidor de archivos, no una IP. Si debes usar DFS, prueba referrals explícitamente y monitoriza qué backend usan realmente los clientes.

10) ¿Por qué el montaje se cuelga cuando el servidor se reinicia?

Eso suele ser comportamiento hard combinado con lógica de reintento en el cliente CIFS. Conserva la integridad de datos pero puede congelar procesos. Si tu app puede manejar errores de I/O, puedes elegir distinto comportamiento, pero hazlo intencionalmente y pruébalo.

Conclusión: próximos pasos que puedes ejecutar esta semana

Inventario tus montajes: registra nombre del servidor, nombre del recurso, opciones de montaje y si se usa Kerberos.
Elimina la ambigüedad: aplica una versión SMB explícita (vers=) y modo de seguridad (sec=krb5 cuando corresponda).
Ejecuta la guía de diagnóstico rápido en un host conocido bueno y en uno problemático. Compara dialecto negociado y firmado/cifrado.
Elige una estrategia de permisos (cuenta de servicio vs por usuario) y hazla estándar, no una invención por equipo.
Benchmarkea la forma de tu carga (metadata vs throughput). Optimiza lo correcto, no la queja más ruidosa.
Automatiza y monitoriza la deriva: definiciones de montaje en CM; alerta cuando cambie dialecto/modo de seguridad.

Si haces solo dos cosas: fuerza Kerberos (o decide explícitamente que no lo harás), y estandariza opciones de montaje. La mayoría de las historias de “SMB es inestable” son en realidad “nuestras suposiciones son inestables”.