Mapeo de ACL de ZFS para SMB: evitar pesadillas de permisos

Un modelo mental que detiene la hemorragia

Estás manejando tres lenguajes de permisos diferentes:
ACLs de Windows (clientes SMB), la interpretación de Samba y el modelo de ACL en disco de ZFS. Si no están de acuerdo, los usuarios no reciben una advertencia educada; obtienen
Access denied y entonces tu cola de tickets se convierte en una escena del crimen.

Aquí está el modelo mental sensato:

• ZFS almacena ACLs estilo NFSv4 (también llamadas “NFS4 ACLs”) cuando acltype=nfsv4. Estas pueden representar ACEs similares a Windows:
  allow/deny, flags de herencia y permisos detallados. Esta es la mejor correspondencia para SMB.
• Los bits de modo POSIX aún existen (rwxrwxrwx), pero dependiendo de propiedades como aclmode y aclinherit,
  son o bien una puerta significativa o una pegatina decorativa.
• Samba mapea SIDs a IDs UNIX. Si ese mapeo cambia, las entradas ACL todavía apuntan a la identidad antigua. La ACL no “se rompió”;
  lo que falló fue la capa de identidades.
• “Permisos del recurso compartido” vs “permisos del archivo”: Samba tiene restricciones a nivel de recurso compartido y ACLs a nivel de sistema de archivos. El permiso efectivo es
  la intersección. Puedes ser generoso en uno y estricto en el otro, pero si eres estricto en ambos inventarás nuevas formas de sufrimiento.

Trata tu entorno como un sistema de identidad primero, un sistema de ACLs segundo y un sistema de almacenamiento tercero. Ese orden no es filosófico: es la
secuencia de fallos que verás en producción.

Una idea parafraseada de W. Edwards Deming aplica: una mala sistema derrotará a buenas personas cada vez. En el trabajo con permisos,
el “sistema” es tu capa de mapeo y tu estrategia de herencia.

Datos interesantes y contexto histórico

Algo de contexto ayuda porque la mitad del dolor actual es el compromiso de ayer.

1. Windows NT introdujo las ACLs a principios de los 90 con semántica allow/deny y herencia. El modelo es anterior a los despliegues modernos de Samba
   por décadas, por eso los clientes Windows tienen opiniones fuertes.
2. Los bits de modo POSIX son más antiguos y simples: user/group/other con rwx. No pueden expresar “deny”, no pueden expresar excepciones por usuario,
   y la herencia no es nativa.
3. Las ACLs de NFSv4 se diseñaron para ser más ricas que POSIX y más cercanas a la semántica de Windows, por eso ZFS se apoya en ellas para ACLs compatibles con SMB.
4. Samba lleva tiempo usando módulos VFS enchufables; los enfocados en ZFS existen porque el manejo genérico de ACL POSIX no puede capturar completamente la semántica de NFSv4 de ZFS
   sin traducción.
5. ZFS de la era Solaris trataba NFSv4 ACLs como una característica de primera clase. Esta elección de diseño resuena en OpenZFS hoy: el modelo de ACL no es un complemento.
6. “ACLs ricas” no son gratuitas: incrementan el trabajo de metadatos, y operaciones como arreglar herencia recursiva pueden ser costosas. Cuando los problemas de permisos
   ocurren a escala, rara vez es un solo archivo: es el árbol de un millón de archivos detrás.
7. El mapeo de identidades es la dependencia oculta: SMB habla SID; UNIX habla UID/GID. La capa SID→UID es donde nace “esto funcionó ayer”.
8. ZFS tiene propiedades que influyen en el comportamiento de las ACL (aclmode, aclinherit, xattr). No son conmutadores cosméticos.
   Cambian lo que hace chmod y si la herencia se comporta como Windows espera.

Cómo las ACL de ZFS se mapean a SMB (y dónde falla)

1) Las dos grandes elecciones de compatibilidad: ACL POSIX vs ACL NFSv4

Si sirves SMB a clientes Windows y quieres edición de ACLs al estilo Windows, quieres acltype=nfsv4 en el dataset. Eso le da a ZFS un vocabulario de ACL
que puede representar conceptos de Windows: flags de herencia, entradas “deny” y permisos finos.

Las ACLs POSIX (acltype=posixacl) pueden funcionar para entornos centrados en Linux, pero mapear a la semántica de Windows se vuelve “aproximado.” Aproximado es una
palabra educada. Es como medir un centro de datos con una cinta métrica que imprimiste de memoria.

2) El trabajo de Samba: traducir descriptores de seguridad de Windows a ACLs del sistema de archivos

Un cliente Windows envía un descriptor de seguridad (algo parecido a SDDL en el fondo). Samba evalúa si el cliente puede establecerlo y luego lo traduce a
entradas ACL del sistema de archivos. Con ACLs NFSv4 de ZFS, esta traducción puede ser casi directa.

Cuando la traducción es con pérdida —porque el sistema de archivos no puede representar alguna bandera de Windows— Samba hace lo mejor posible y obtienes “funciona mayormente” hasta que encuentras casos límite:
denies heredados, semántica CREATOR OWNER o evaluaciones raras de membresía de grupo.

3) Propiedades de ZFS que deciden si te despiertas de noche

• aclmode: controla cómo chmod interactúa con las ACLs. En entornos SMB, a menudo quieres que chmod no elimine la intención de las ACL.
• aclinherit: controla cómo se heredan las ACLs y si se reescriben. Si esto no se alinea con las expectativas de Windows,
  verás “los archivos nuevos no coinciden con los permisos de la carpeta.”
• xattr: controla cómo se almacenan atributos extendidos (on, sa). Esto puede afectar el rendimiento y el comportamiento para
  cargas de trabajo con muchas ACLs porque las ACLs y el metadata de SMB usan xattrs.
• casesensitivity: Windows es por defecto case-insensitive. Los desajustes aquí causan “duplicados fantasma” o comprobaciones de acceso confusas.

4) La capa de identidades: SIDs, UIDs y el arte de no cambiarlos

Windows usa SIDs. ZFS en un sistema tipo UNIX finalmente aplica el acceso usando UIDs/GIDs. Samba puentear esto mediante idmap. Si tu configuración de idmap cambia
(o cambia la confianza de dominio), el mismo SID de usuario podría mapear a un UID diferente, o no mapear en absoluto. Tus entradas ACL todavía referencian identidades, pero ya no
coinciden con el usuario en la red.

Aquí nace el “los permisos se rompieron aleatoriamente”. No pasó nada aleatorio. Cambiaste la regla de medida.

Broma #1: Los errores de permisos son como el brillo (glitter): una vez que están en la organización, los seguirás encontrando en lugares que nadie recuerda haber tocado.

5) Entradas “deny” y orden: por qué los administradores de Windows pueden inutilizar el acceso al instante

La evaluación de ACLs en Windows incluye semántica explícita de deny. Las ACLs NFSv4 también pueden expresar entradas deny. Pero aún debes tener cuidado con denies heredados
y las reglas de “quién es el propietario del archivo”. Si una carpeta tiene un deny sobre un grupo amplio, la herencia puede propagar ese deny a archivos de formas que sorprenden a quienes están acostumbrados
a “simplemente agregamos un allow.”

Enseña a tus administradores: evita deny a menos que estés bloqueando activamente algo y puedas explicar el orden de evaluación. La mayoría de las entradas deny son política expresada como
sabotaje.

Elige tu estrategia de permisos (y comprométete)

Estrategia A: Prioridad Windows (recomendada para entornos con mucho SMB)

Usa ZFS acltype=nfsv4. Gestiona permisos desde Windows (Explorer, icacls) y deja que Samba escriba las ACLs. Mantén chmod/chown del lado Linux lejos de
datasets que son “propiedad de Windows,” o al menos restringelos a automatizaciones controladas que respeten las propiedades de ACL.

Aún necesitas un owner/group UNIX para compatibilidad POSIX, pero trata los bits de modo como una vista de compatibilidad, no como la fuente de la verdad.

Estrategia B: Prioridad UNIX con acceso SMB (funciona, pero estarás traduciendo)

Si la mayoría de la administración ocurre en Linux y los clientes Windows son consumidores, las ACLs POSIX pueden ser suficientes. Pero debes aceptar: las ediciones desde la UI de Windows pueden no comportarse
de forma intuitiva. Manejarás más conversaciones de “¿por qué no puedo establecer este permiso?”.

Estrategia C: Administración mixta desde ambos lados (evitar)

Así obtienes deriva de permisos. Un admin de Windows establece una ACL heredada compleja. Un admin de Linux ejecuta un chmod recursivo porque “se veía mal.”
Ahora tienes un dataset lleno de intención medio preservada y muchos tickets nuevos.

Guion de diagnóstico rápido

Cuando alguien reporta “SMB permission denied” o “el acceso cambió,” no empieces haciendo clic en el Explorer. Empieza con una secuencia corta que aísle
dónde está la falla: identidad, restricciones del recurso compartido, ACL del sistema de archivos o deriva de herencia.

Primero: identidad y mapeo (lo más común, lo más catastrófico)

1. Confirma que el SID del usuario se mapea al UID/GID esperado en el servidor.
2. Confirma que la membresía de grupos es visible para Samba (el token tiene los grupos correctos).
3. Confirma que el backend y el rango de idmap no han cambiado.

Segundo: restricciones a nivel SMB

1. Revisa la configuración del recurso compartido: valid users, read only, write list, inherit permissions, veto files, etc.
2. Verifica si el cliente se conecta con la cuenta esperada (credenciales en caché son clásicas).

Tercero: ACL del sistema de archivos + propiedades de ZFS

1. Inspecciona las propiedades del dataset ZFS: acltype, aclmode, aclinherit, xattr, casesensitivity.
2. Inspecciona la ACL del archivo/directorio desde el servidor, no solo desde Windows.
3. Busca entradas deny explícitas y flags de herencia rotas.

Cuarto: la investigación “alguien ejecutó chmod”

1. Busca cambios recientes: diffs de snapshots, logs de auditoría si están habilitados, snapshots ZFS o patrones de mtime en el sistema de archivos.
2. Identifica si las ACLs fueron eliminadas o reescritas por chmod/chown o por una herramienta de migración.

Tareas prácticas: comandos, salidas, decisiones

Estas son las tareas que realmente realizo al depurar el mapeo ACL ZFS + SMB. Cada tarea incluye un comando realista, un ejemplo de cómo se ve “bien” o “mal”
y la decisión que tomas a continuación.

Tarea 1: Identificar dataset y punto de montaje

cr0x@server:~$ zfs list -o name,mountpoint,acltype,aclmode,aclinherit,xattr,casesensitivity tank/share
NAME        MOUNTPOINT    ACLTYPE  ACLMODE    ACLINHERIT  XATTR  CASESENSITIVITY
tank/share  /tank/share   nfsv4    restricted passthrough sa     insensitive

Qué significa: Estás en ACLs NFSv4, chmod está restringido para no sobrescribir ACLs, la herencia pasa tal cual, xattrs en SA, comportamiento de mayúsculas parecido a Windows.

Decisión: Este dataset está plausiblemente configurado para ACLs con prioridad SMB. Procede a comprobaciones de identidad y ACL efectivas en lugar de cambiar propiedades.

Tarea 2: Confirmar que la definición del recurso compartido de Samba apunta aquí

cr0x@server:~$ testparm -s | sed -n '/^\[share\]/,/^\[/{p}'
[share]
	path = /tank/share
	read only = No
	vfs objects = zfsacl streams_xattr
	inherit acls = Yes
	store dos attributes = Yes

Qué significa: La ruta del recurso coincide con el punto de montaje del dataset. El módulo VFS consciente de ACL de ZFS está habilitado. Los atributos DOS se almacenan como xattrs.

Decisión: Si vfs objects no incluye zfsacl (o el equivalente de tu plataforma), el mapeo puede estar degradado. Arregla la configuración de Samba antes de tocar las ACLs.

Tarea 3: Ver qué usuario piensa Samba que eres (y tus grupos)

cr0x@server:~$ wbinfo --user-sid 'EXAMPLE\alice'
S-1-5-21-111111111-222222222-333333333-1107

Qué significa: El usuario de dominio se resuelve a un SID. Si esto falla, no tienes un problema de ACLs—tienes un problema de servicios de directorio.

Decisión: Si esto falla, detente y arregla la unión al dominio / winbind / confianza antes de cualquier otra cosa.

Tarea 4: Mapear SID a ID UNIX y verificar que sea estable

cr0x@server:~$ wbinfo --sid-to-uid S-1-5-21-111111111-222222222-333333333-1107
2001107

Qué significa: Samba mapea el SID al UID 2001107. Este UID es lo que al final le importa a la aplicación de las ACLs en el sistema de archivos.

Decisión: Si el mapeo cambió recientemente, las entradas ACL que hacían referencia al UID antiguo ya no coincidirán. Investiga el backend/rangos de idmap y si un servidor diferente está emitiendo mapeos distintos.

Tarea 5: Revisar la configuración de idmap desde la perspectiva de Samba

cr0x@server:~$ testparm -s | grep -E '^idmap config|^security|^realm'
security = ADS
realm = EXAMPLE.COM
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config EXAMPLE : backend = rid
idmap config EXAMPLE : range = 2000000-2999999

Qué significa: El dominio EXAMPLE usa mapeo RID a un rango UID específico. Tiende a ser estable si mantienes el rango consistente entre servidores.

Decisión: Asegúrate de que cada servidor SMB que accede al mismo dataset ZFS use el mismo backend y rangos de idmap. Si no, te garantizas desajustes en las identidades en disco de las ACLs.

Tarea 6: Validar que el token del usuario incluya los grupos esperados

cr0x@server:~$ wbinfo --user-groups 'EXAMPLE\alice' | head
S-1-5-21-111111111-222222222-333333333-513
S-1-5-21-111111111-222222222-333333333-2201
S-1-5-21-111111111-222222222-333333333-2209

Qué significa: Estos son SIDs de grupos en la lista de membresía del usuario.

Decisión: Si un permiso debería venir de un grupo pero el SID del grupo no está presente, estás mirando a la membresía de directorio, refresco de token, visibilidad de grupos anidados o caché de winbind —no a ZFS.

Tarea 7: Inspeccionar la ACL en un directorio desde el servidor (estilo NFSv4)

cr0x@server:~$ ls -V /tank/share/Projects
drwxrwx---+  15 root  domain_users  15 Dec 26 10:12 /tank/share/Projects
                owner@:rwxpDdaARWcCos:fd-----:allow
                group@:rwxpDdaARWcCos:fd-----:allow
             everyone@:------a-R-c--s:fd-----:allow

Qué significa: El + indica una ACL más allá de los bits de modo. Las flags de herencia (f, d) están presentes para archivos/dirs. Esto parece una línea base controlada.

Decisión: Si no ves flags de herencia en directorios donde las esperas, probablemente tengas un problema de configuración de herencia o se realizó un reinicio de ACL.

Tarea 8: Confirmar que la vista de Windows coincide (desde herramientas Samba)

cr0x@server:~$ smbcacls //localhost/share Projects -U 'EXAMPLE\alice'
REVISION:1
CONTROL:SR|DP
OWNER:EXAMPLE\Administrator
GROUP:EXAMPLE\Domain Users
ACL:EXAMPLE\Domain Admins:ALLOWED/0x0/FULL
ACL:EXAMPLE\Project Team:ALLOWED/0x0/CHANGE
ACL:EXAMPLE\Domain Users:ALLOWED/0x0/READ

Qué significa: Samba puede presentar una ACL coherente de Windows a los clientes.

Decisión: Si esto difiere enormemente de ls -V, el mapeo puede estar degradado, o estás mirando objetos distintos (desajuste de ruta), o tu módulo VFS no está activo.

Tarea 9: Comprobar el acceso efectivo para una identidad específica (lado servidor)

cr0x@server:~$ id EXAMPLE\\alice
uid=2001107(alice) gid=2000513(domain_users) groups=2000513(domain_users),2002201(project_team)

cr0x@server:~$ sudo -u '#2001107' test -w /tank/share/Projects && echo WRITABLE || echo NOT_WRITABLE
WRITABLE

Qué significa: El servidor cree que Alice puede escribir. Esto aísla “el sistema de archivos dice sí” de “SMB dice no.”

Decisión: Si el sistema de archivos dice WRITABLE pero los clientes SMB reciben denegación, revisa restricciones a nivel de recurso compartido, configuración de Samba, oplocks, vetoes o autenticación de cliente/credenciales en caché.

Tarea 10: Detectar si los bits de modo POSIX se usan como puerta

cr0x@server:~$ stat -c '%A %a %U %G %n' /tank/share/Projects
drwxrwx--- 770 root domain_users /tank/share/Projects

Qué significa: Los bits de modo son 770. Si tu ACL pretende un acceso más amplio pero “other” es 0, algunas herramientas aún pueden verse limitadas dependiendo de la configuración de ACL y la ruta de evaluación.

Decisión: Si a usuarios Windows se les niega el acceso y los bits de modo son demasiado restrictivos, confirma el comportamiento de aclmode y aclinherit y asegúrate de que la ACL incluya las entradas allow necesarias. No pongas chmod 777 a ciegas.

Tarea 11: Verificar los controles de comportamiento del dataset (los que la gente olvida)

cr0x@server:~$ zfs get -H -o property,value acltype,aclmode,aclinherit,xattr tank/share
acltype	nfsv4
aclmode	restricted
aclinherit	passthrough
xattr	sa

Qué significa: Esta combinación generalmente preserva la intención de Windows. restricted evita que chmod elimine ACLs. passthrough mantiene los ACEs tal como están para la herencia.

Decisión: Si ves aclmode=discard o aclinherit=discard en un dataset SMB, eso es una bomba de tiempo de permisos. Arregla las propiedades y luego repara las ACLs.

Tarea 12: Encontrar entradas deny explícitas que bloqueen todo

cr0x@server:~$ ls -V /tank/share/Projects/Quarterly
drwxrwx---+  10 root  domain_users  10 Dec 26 10:18 /tank/share/Projects/Quarterly
                owner@:rwxpDdaARWcCos:fd-----:allow
                group@:rwxpDdaARWcCos:fd-----:allow
        project_team@:------a-R-c--s:fd-----:deny

Qué significa: Hay un deny explícito para project_team@. Si tus redactores están en ese grupo, están bloqueados independientemente de otros allows.

Decisión: Elimina o restringe la entrada deny. En la mayoría de árboles corporativos, los denies se usan como “política,” y la política pertenece a la membresía de grupos, no a una granada deny heredada.

Tarea 13: Probar si la herencia sucede (o no) para archivos nuevos

cr0x@server:~$ sudo -u '#2001107' touch /tank/share/Projects/inheritance_test.txt

cr0x@server:~$ ls -V /tank/share/Projects/inheritance_test.txt
-rw-rw----+  1 alice  domain_users  0 Dec 26 10:20 /tank/share/Projects/inheritance_test.txt
                owner@:rw-p--aARWcCos:------:allow
                group@:rw-p--aARWcCos:------:allow
             everyone@:------a-R-c--s:------:allow

Qué significa: El archivo heredó una plantilla de ACL sensata. Si no lo hubiera hecho, verías entradas faltantes o flags diferentes.

Decisión: Si los archivos nuevos tienen ACLs “incorrectas”, revisa aclinherit, inherit acls de Samba y si Windows está aplicando una ACL padre distinta a la que crees.

Tarea 14: Detectar el modo de almacenamiento de xattr y si estás pagando impuesto de metadatos

cr0x@server:~$ zfs get -H -o property,value xattr tank/share
xattr	sa

Qué significa: xattr=sa almacena xattrs pequeñas en el área de “system attributes” del dnode, reduciendo I/O separado para cargas SMB con mucho metadata.

Decisión: Si ves mal rendimiento de metadata y xattr=on, considera cambiar a sa para datasets nuevos (cambiarlo en datasets existentes puede tener implicaciones; planifica con cuidado).

Tarea 15: Validar que Samba vea el módulo ACL de ZFS cargado

cr0x@server:~$ smbstatus -b | head -n 15
Samba version 4.19.5
PID     Username     Group        Machine
-------------------------------------------------------------------
4123    alice        domain_users  10.20.30.40 (ipv4:10.20.30.40:52514)

Service      pid     Machine       Connected at
-------------------------------------------------------
share        4123    10.20.30.40    Wed Dec 26 10:21:14 2025

Locked files:
No locked files

Qué significa: Existe una sesión SMB activa; puedes correlacionar el comportamiento del cliente con logs del servidor y comprobaciones del sistema de archivos.

Decisión: Si no hay sesiones, tu problema puede ser autenticación/conectividad, no permisos de archivos. No “arregles” ACLs por un problema de inicio de sesión.

Tarea 16: Correlacionar una denegación de cliente con logs de Samba (logging quirúrgico)

cr0x@server:~$ sudo smbcontrol all debug 3

cr0x@server:~$ sudo tail -n 30 /var/log/samba/log.smbd
[2025/12/26 10:22:03.114820,  3] smbd/open.c:5963(open_file)
  open_file: unable to open file Projects/Quarterly/report.xlsx. Error was NT_STATUS_ACCESS_DENIED

Qué significa: Samba está denegando en tiempo de apertura. Eso te empuja hacia la evaluación de ACLs del sistema de archivos o restricciones del recurso compartido.

Decisión: Si la denegación es consistente para una ruta, inspecciona la ACL de esa ruta por denies explícitos o problemas de propiedad, y confirma los grupos en el token del usuario.

Tres microhistorias corporativas desde las trincheras de permisos

Microhistoria #1: El incidente causado por una suposición equivocada

Una empresa mediana migró desde un servidor de archivos Windows a un reluciente clúster SMB respaldado por ZFS. El plan sonaba simple: copiar datos, mantener permisos, cambiar.
El project manager hizo una pregunta: “¿Las ACL de Windows se mapearán tal cual?” La respuesta que recibieron fue “Sí, mayormente.”

En el día de cambio, el helpdesk se inundó. Algunos equipos podían leer pero no escribir. Otros podían escribir pero no renombrar. Algunos jefes de departamento descubrieron que
eran “propietarios” en carpetas aleatorias que no reconocían, lo cual es una excelente manera de poner nerviosas a las personas frente a una auditoría no solicitada.

La causa raíz no fue que ZFS fuera extraño. Fue la suposición de que el mapeo de identidades era universal entre servidores. El antiguo servidor Windows tenía SIDs estables.
La nueva configuración de Samba usaba un backend idmap diferente en un nodo que en los demás. Mismo dominio, mismos usuarios, asignaciones UID/GID diferentes dependiendo de
qué nodo SMB manejaba la solicitud.

Lo irónico: las ACLs en disco estaban “correctas” desde la perspectiva del nodo que las escribió. Eran un disparate desde la perspectiva del otro nodo.
Parecía una falla aleatoria de permisos porque dependía de la colocación de la conexión.

Lo solucionaron estandarizando el backend y los rangos de idmap en todo el clúster, luego reescribiendo la propiedad de las ACL para coincidir con mapeos estables. El tiempo de inactividad se midió
en horas. La limpieza tomó semanas porque la confianza fue la verdadera víctima.

Microhistoria #2: La optimización que salió mal

Otra organización tenía una queja de rendimiento: listar directorios sobre SMB se sentía lento en horas punta. Alguien miró gráficos, vio presión de metadata y
decidió “simplificar” permisos. La idea: reducir la complejidad de ACL colapsando muchos ACEs en grupos amplios, eliminar el “ruido” de herencia y establecer
aclinherit=discard para evitar escribir entradas heredadas adicionales.

Durante dos días, todos estuvieron encantados. Los archivos nuevos se creaban rápido. Los listados de directorio fueron más ágiles. La persona que lo sugirió consiguió una aprobación silenciosa
de la dirección, que en la vida corporativa es básicamente un desfile.

Luego los equipos de proyecto notaron algo: los archivos nuevos no heredaban el acceso esperado para grupos interfuncionales. La gente volvió a mandar documentos por correo
porque “el recurso compartido está roto.” Ahí sabes que estás perdiendo: cuando los usuarios inventan un procedimiento alternativo que también arruina el cumplimiento.

El efecto adverso fue sutil. Al descartar la herencia, forzaron a que los permisos dependieran de modos por defecto y de lo que Samba eligiera al crear. El resultado
fue ACLs inconsistentes dependiendo de la app cliente y cómo creaba archivos. Algunas aplicaciones creaban archivos temporales con descriptores de seguridad distintos a los finales.
Sin herencia para corregirlos, las rarezas permanecieron.

La solución no fue glamorosa: revertir a passthrough de herencia, usar una ACL base limpia en las raíces y mejorar el rendimiento abordando metadata correctamente
(estrategia xattr, elección de recordsize y no hacer cirugía recursiva de ACL a las 9 a.m.).

Microhistoria #3: La práctica aburrida pero correcta que salvó el día

Una gran empresa operó un servicio SMB sobre ZFS durante años con mínima drama. Su secreto no fue una configuración mágica. Fue disciplina: un único “root de ACL”
por recurso compartido, nomenclatura de grupos estandarizada y la regla que sólo las herramientas de Windows establecieran ACLs en shares de producción. La automatización Linux podía crear directorios, pero
no tenía permitido hacer chmod recursivo. Nunca.

Un día ocurrió una reestructuración de dominio. Nuevos grupos, grupos retirados, cambios en membresías anidadas. Este tipo de cambio suele convertir los shares en arte abstracto. Esperaban tickets.

No llegaron tickets. ¿Por qué? Tenían un trabajo nocturno que validaba la consistencia del mapeo de identidades y marcaba entradas con “SID desconocido” antes de que los humanos notaran.
También hacían snapshots agresivos y podían comparar diffs de cambios en ACL cuando algo olía mal.

Durante la reestructuración, su monitoreo marcó que un subconjunto de SIDs de grupo dejó de resolverse en un nodo SMB. Drenaron conexiones de ese nodo, arreglaron la conectividad winbind y lo devolvieron.
La mayoría de usuarios no lo sintió.

Fue trabajo aburrido. El mejor tipo. Cuando alguien preguntó por qué se molestan con “chequeos de salud de permisos,” la respuesta fue simple: porque la alternativa es aprender sobre ACLs durante una caída, lo cual es como aprender a nadar durante una inundación.

Broma #2: Lo único más persistente que un mapeo SID obsoleto es la persona que insiste “los permisos son fáciles” porque una vez ejecutó chmod -R.

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

1) Síntoma: “Funciona en un nodo SMB, falla en otro”

Causa raíz: Backend/rangos de idmap inconsistentes entre nodos; SID→UID difiere por nodo.

Solución: Estandariza la configuración de idmap en todos lados. Valida con wbinfo --sid-to-uid en cada nodo. Solo entonces considera reparar ACLs.

2) Síntoma: “Los archivos nuevos no heredan los permisos de la carpeta”

Causa raíz: aclinherit=discard/restricted desajuste, o ajustes de herencia de Samba deshabilitados, o la ACL padre carece de flags de herencia.

Solución: Usa aclinherit=passthrough (o tu política consistente), asegura inherit acls = yes y restablece la ACL del padre para incluir flags de herencia adecuados.

3) Síntoma: “chmod de Linux lo arregló… y luego todo se rompió más tarde”

Causa raíz: chmod/chown interactuó con las ACLs vía aclmode y eliminó o reescribió entradas. O cambió la propiedad e invalidó ACEs dirigidos a ella.

Solución: Ajusta aclmode=restricted para datasets con prioridad SMB. Deja de usar chmod recursivo en shares de producción. Reaplica una línea base de ACL desde una plantilla conocida y buena.

4) Síntoma: “Todos tienen acceso de lectura, pero los redactores no pueden renombrar/eliminar”

Causa raíz: Permisos de directorio faltantes como delete/rename (o sus equivalentes NFSv4). En Windows, la semántica de borrado implica permisos en el directorio padre.

Solución: Asegura que el grupo de escritura tenga derechos de modify/change en el directorio, no solo write sobre archivos. Valida creando, renombrando y borrando desde SMB y desde el servidor.

5) Síntoma: “El propietario aparece como un SID desconocido en Windows”

Causa raíz: El SID ya no se resuelve (grupo eliminado/renombrado sin persistencia de SID), o el servidor no puede contactar controladores de dominio, o la caché de idmap está obsoleta/rota.

Solución: Restaura la conectividad del servicio de directorio, limpia/actualiza caches de winbind con cuidado y evita reescribir ACLs hasta que las identidades se resuelvan nuevamente.

6) Síntoma: “Un subconjunto de usuarios recibe Access Denied después de cambios de dominio”

Causa raíz: Cambios de membresía no reflejados debido a caché de tokens, límites en evaluación de grupos anidados o winbind sin ver actualizaciones.

Solución: Valida los SIDs de grupos en el token con wbinfo --user-groups. Ajusta la configuración de directorio/Samba para grupos anidados si es necesario; pide a usuarios reconectar/cerrar sesión para refrescar tokens.

7) Síntoma: “Windows dice que tengo Control total pero aún así deniega”

Causa raíz: Restricciones a nivel de recurso compartido (valid users, write list), o desajuste de ruta de sistema de archivos (symlinks, bind mounts), o un deny explícito más arriba en el árbol.

Solución: Revisa la config del recurso con testparm. Confirma la ruta exacta. Inspecciona ACLs del directorio padre y busca entradas deny.

8) Síntoma: “Después de la migración de datos, los permisos se ven aplanados”

Causa raíz: La herramienta de migración no preservó ACLs (o las tradujo a bits de modo POSIX), o se copiaron como root sin preservar xattrs/ACLs.

Solución: Re-migra con un método que preserve ACLs apropiado para tu plataforma, o restaura desde snapshot. Luego asegúrate de bloquear la estrategia para que no vuelva a ocurrir.

Listas de verificación / plan paso a paso

Lista 1: Crear un nuevo recurso compartido SMB en ZFS sin arrepentimientos futuros

1. Crea un dataset dedicado por recurso compartido. No lo metas todo en un dataset y esperes lo mejor.
2. Establece propiedades del dataset explícitamente: acltype=nfsv4, un aclmode deliberado, un aclinherit deliberado y una elección de sensibilidad de mayúsculas alineada con clientes Windows.
3. Elige una estrategia de idmap y estandarízala en cada nodo SMB que toque los datos.
4. Configura Samba con módulos VFS conscientes de ACL de ZFS y habilita el comportamiento de herencia de ACLs que realmente quieras.
5. Define una ACL raíz en Windows, valida la herencia creando archivos de prueba desde múltiples aplicaciones cliente.
6. Haz snapshot antes de entregarlo a usuarios reales. Quieres una vía de escape antes de que empiece la “creativa gestión de permisos”.

Lista 2: Respuesta a incidentes de permisos (30–60 minutos)

1. Identifica la ruta exacta y un usuario afectado. No “un montón de gente.” Una identidad. Un objeto.
2. Confirma que el mapeo SID→UID del usuario es correcto en el nodo SMB que maneja la sesión.
3. Revisa restricciones a nivel de recurso en Samba y confirma que el usuario se conecta con la cuenta esperada.
4. Inspecciona ACLs del servidor en el directorio y archivo; busca denies explícitos y flags de herencia faltantes.
5. Prueba la escritura efectiva del lado servidor con sudo -u '#UID' test -w.
6. Si hace falta, aumenta el debug de Samba brevemente y correlaciona un evento NT_STATUS_ACCESS_DENIED con la ruta.
7. Arregla lo más pequeño que restaure la corrección (a menudo el mapeo de identidad o un solo ACE malo), luego restaura el nivel de logging.

Lista 3: Prevenir la deriva de permisos (continuo)

1. Declara una única fuente de verdad para cambios de ACL (herramientas del lado Windows para datasets con prioridad SMB).
2. Prohíbe chmod recursivo en shares de producción; aplícalo mediante guardrails de automatización y revisión por pares.
3. Estandariza backend/rangos de idmap entre nodos; trata los cambios como proyecto de migración, no como ajuste.
4. Haz snapshots regularmente; conserva al menos un snapshot “baseline ACL conocido-bueno” para rollback/diff rápido.
5. Monitorea SIDs no mapeados y traducciones SID→UID fallidas; alerta temprano.

Preguntas frecuentes

1) ¿Debo usar acltype=nfsv4 para shares SMB?

Sí, para shares SMB centrados en Windows. Coincide con la semántica de ACLs de Windows mucho mejor que las ACLs POSIX y reduce las “sorpresas de traducción.”

2) ¿Por qué veo bits de modo (770) si las ACLs son el control real?

Porque UNIX todavía tiene un campo de modo y muchas herramientas lo muestran. Dependiendo de aclmode, chmod puede o no reescribir ACLs para coincidir. Trata los bits de modo
como metadata de compatibilidad a menos que hayas elegido intencionalmente una política centrada en modos.

3) ¿Cuál es la diferencia entre aclmode=restricted y aclmode=discard?

restricted tiende a preservar la intención de las ACL cuando se usa chmod. discard puede eliminar ACLs cuando cambian los bits de modo. Para datasets SMB, discard
es como convertir accidentalmente un modelo de permisos matizado en escombros.

4) ¿Por qué los permisos cambian dependiendo de qué servidor SMB golpeo?

Casi siempre configuración idmap inconsistente. El mismo SID se mapea a UIDs diferentes en nodos distintos, así que las entradas ACL en disco coinciden en un nodo y no en otro.

5) ¿Puedo ejecutar chown -R de forma segura en un dataset SMB?

“De forma segura” implica mucho trabajo. Cambios recursivos de propiedad pueden invalidar la semántica de ACLs (especialmente owner@ y group@) y sorprender a Windows.
Si debes hacerlo, haz snapshot primero, prueba en un clone y entiende tu modelo de ACL.

6) ¿Necesito vfs_zfsacl (o equivalente) en Samba?

Si quieres comportamiento correcto de NFSv4/ZFS ACL expuesto a clientes Windows, sí. Sin él, Samba puede recurrir a manejo genérico de ACLs y verás flags faltantes,
herencia rota o rarezas en la UI de Windows.

7) ¿Por qué un usuario puede crear un archivo pero no borrarlo?

Borrar suele controlarse por permisos en el directorio padre (y la semántica de borrado en Windows es sutil). Asegura que el usuario/grupo tenga derechos de modify en el
directorio, no solo write en archivos.

8) ¿Por qué veo entradas “SID desconocido” en las ACLs?

El servidor no puede resolver ese SID a un nombre, típicamente por problemas de conectividad al directorio, principales eliminados, problemas de confianza o caché idmap rota.
Arregla la resolución de identidades antes de reescribir ACLs, o grabarás identidades equivocadas.

9) ¿Es xattr=sa siempre mejor para SMB?

A menudo es mejor para cargas SMB con mucho metadata porque reduce I/O separado de xattrs. Pero es una elección de diseño—valida en tu plataforma y ten cautela al cambiarlo en datasets existentes sin plan.

10) ¿Cuál es la forma más simple de mantener los permisos sanos?

Un dataset por share, acltype=nfsv4, idmap consistente en todos lados, gestiona ACLs desde Windows y mantén chmod de Linux lejos del árbol. Lo aburrido gana.

Próximos pasos que puedes hacer esta semana

Si tus permisos SMB sobre ZFS parecen encantados, no persigas fantasmas. Elige un modelo limpio y luego fíjalo con configuración y hábitos.

1. Inventaría tus datasets SMB: registra acltype, aclmode, aclinherit, xattr y sensibilidad de mayúsculas. Arregla las bombas de tiempo obvias primero.
2. Estandariza idmap en cada nodo SMB que toque el mismo almacenamiento. Trata los cambios como migraciones. “Solo un ajuste” es cómo las ACLs se convierten en ficción histórica.
3. Define una línea base de ACL en la raíz de cada share, valida la herencia con aplicaciones cliente reales y haz snapshot de la línea base.
4. Pon el guion de diagnóstico rápido en un lugar que tu on-call pueda encontrar a las 2 a.m. Tú futuro estará cansado y no querrá volver a aprender mapeo de identidades.

Las pesadillas de permisos no son causadas por una sola casilla mal marcada. Son causadas por una visión inconsistente del mundo. Hazla consistente—y de repente tu servidor de archivos
vuelve a ser aburrido. Ese es el objetivo.