Recurso compartido SMB ‘Acceso denegado’: el permiso que todos pasan por alto

El permiso que todos pasan por alto: permisos a nivel de recurso compartido

El acceso SMB es la intersección de múltiples puertas. No «tienes acceso» porque una ACL lo diga; tienes acceso porque todas las puertas lo permiten.

Windows: permisos de recurso compartido + permisos NTFS

En servidores de archivos Windows hay dos sistemas de permisos separados involucrados cuando accedes a un recurso compartido:

• Permisos de recurso compartido (el objeto de compartición). Históricamente configurados como Read/Change/Full Control en el recurso compartido.
• Permisos NTFS (la ACL del sistema de archivos) en el árbol de carpetas subyacente.

El acceso efectivo es la combinación más restrictiva. Si NTFS concede Modify pero el recurso compartido solo concede Read, obtienes Read. Si el recurso compartido niega a un grupo, te deniegan aunque NTFS esté abierto.

Samba: restricciones en la definición del recurso + permisos del sistema de archivos

En Samba la idea es la misma aunque los controles luzcan distintos. Tu acceso está restringido por:

• Controles a nivel de recurso en Samba: valid users, write list, read list, hosts allow, veto files, force user, guest ok y compañía.
• Permisos del sistema de archivos: bits de modo POSIX, ACLs (NFSv4 ACLs en ZFS, POSIX ACLs en ext4/xfs), además de cualquier capa MAC (SELinux/AppArmor).
• Mapeo de identidades: si Samba te mapea a un UID/GID distinto al que espera el sistema de archivos, es una denegación por matemáticas.

Si quieres una verdad operativa en una línea: SMB nunca es «solo permisos». Es permisos más traducción.

Broma #1: Los permisos SMB son como la seguridad de un aeropuerto: puedes estar aprobado en la puerta y aun así te paren porque olvidaste que llevas una botella de agua llamada «Deny ACE».

Un modelo mental que detiene el ping-pong

Cuando alguien dice «tengo permisos», normalmente quieren decir «estoy en el grupo AD». Cuando otro dice «la ACL está correcta», quieren decir «el sistema de archivos se ve bien». Ambos pueden ser verdad. Aun así te deniegan.

Piensa en puertas, no en listas

Para el acceso SMB, recorre las puertas en este orden:

1. Resolución de nombres y accesibilidad: ¿estás alcanzando el servidor que crees que alcanzas?
2. Autenticación: ¿iniciaste sesión como la identidad que crees que usaste?
3. Autorización en el recurso compartido: ¿el objeto de recurso compartido te permite?
4. Autorización en el sistema de archivos: ¿la ACL del directorio te permite (y tienes derechos de traversa en la ruta)?
5. Capas de política: requisitos de cifrado/firmado, incompatibilidad de dialecto SMB, «Network access: Sharing and security model», «map to guest» de Samba, etc.
6. Caché de tokens/credenciales: Windows cachea credenciales SMB agresivamente. Los humanos también.

Por qué los permisos del recurso importan más de lo que «deberían»

En muchos entornos Windows maduros, los administradores configuran permisos de recurso compartido a «Everyone: Full Control» y confían en las ACL NTFS. Es una práctica defendible: un plano de control (NTFS), menos deriva, menos confusión. Pero en el momento en que alguien se desvía—a menudo durante un «endurecimiento rápido» o una «restricción temporal»—aparece un segundo plano de control y la deriva comienza.

En entornos Samba, las puertas a nivel de recurso son inevitables: valid users y compañía son el modelo de permisos del recurso. Si una definición de recurso restringe el acceso, puedes hacer chmod 777 hasta que te canses; no importará.

El permiso que todos olvidan, explícitamente

El modo de fallo recurrente es este:

• Windows: la pestaña Security/Permissions del recurso compartido no incluye el grupo del usuario, o lo incluye con Read mientras NTFS espera Write, o contiene un Deny explícito.
• Samba: el recurso tiene valid users = @somegroup pero el usuario no pertenece realmente a ese grupo según la vista de Samba (idmap mismatch), o el recurso tiene read only = yes, o una write list lo excluye.

Guía de diagnóstico rápido (primero/segundo/tercero)

Esta es la rutina de «dejen de discutir y encuentren el cuello de botella». Úsala cuando tienes un usuario fallando, otro usuario funcionando, y todos tienen teorías.

Primero: demuestra qué servidor y qué credenciales

• Confirma que el cliente se conecta al host correcto (DFS puede enviarte a otro lugar; DNS puede mentir; IPs antiguas permanecen).
• Confirma qué nombre de usuario se está usando (credential manager, sesiones en caché, dominio implícito).
• Confirma que la sesión SMB está establecida (o fallando en la autenticación).

Segundo: comprueba el acceso a nivel de recurso (la puerta olvidada)

• Windows: Get-SmbShareAccess en el servidor para el recurso.
• Samba: inspecciona smb.conf y la vista en tiempo de ejecución (testparm -s), revisa valid users, write list, read list, hosts allow.

Tercero: comprueba el acceso a nivel de sistema de archivos y la traversa

• Windows: ACLs NTFS más traversa en la ruta del recurso. Usa icacls y comprobaciones de acceso efectivo.
• Linux: bits de modo POSIX, ACLs (getfacl), además de denegaciones SELinux (ausearch).

Condición de parada

En cuanto encuentres una puerta que deniega, para. No «arregles» tres otras cosas «por si acaso». Ahí es donde conviertes un bug de permisos en un incidente.

Hechos interesantes e historia (por qué se volvió extraño)

1. SMB nació en IBM en los años 80, luego Microsoft lo adoptó y extendió. Esa ascendencia explica por qué todavía encuentras conceptos antiguos integrados en el comportamiento moderno de compartición de Windows.
2. Los permisos de recurso preceden a las ACLs NTFS tal como la mayoría las entiende hoy. Los controles a nivel de recurso fueron una puerta de red temprana; NTFS evolucionó hacia el modelo de seguridad local más fino.
3. El significado de «Everyone» cambió con el tiempo. En Windows antiguo, «Everyone» podía incluir anónimos; posteriores endurecimientos separaron «Everyone» de «Anonymous Logon», pero las suposiciones antiguas perduran en scripts y conocimiento tribal.
4. La larga desprecación de SMB1 creó hábitos de «endurecimiento por compatibilidad»: los administradores activaban ajustes para arreglar dispositivos antiguos, a veces rompiendo accidentalmente la autenticación moderna o endureciendo el acceso sin querer.
5. DFS puede ocultar el objetivo real. Los usuarios dicen «el recurso está caído», pero están alcanzando una referencia a otro servidor con permisos diferentes.
6. El idmap de Samba es un mundo de dolor porque conecta SIDs de Windows con UIDs/GIDs Unix. Un grupo AD perfectamente válido puede volverse irrelevante si cambia el backend de mapeo o se solapan rangos.
7. Los tokens de acceso de Windows son instantáneas. Los cambios en la membresía de grupos no siempre se aplican hasta que se crea un nuevo inicio de sesión/token, lo que convierte en una trampa el decir «acabo de añadirlos al grupo».
8. Los ACEs Deny explícitos ganan (en general). Existen por una razón, pero también son la vía más rápida para crear enigmas del tipo «funciona para admins pero no para finanzas».
9. El firmado/cifrado SMB puede parecer un problema de acceso. Algunos clientes fallan con errores engañosos cuando la política bloquea la conexión antes de que ocurra la autorización.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estos son movimientos operativos reales. Ejecútalos desde el lugar correcto (cliente vs servidor) y lee la salida como si te contara una historia. Porque lo hace.

Tarea 1 (cliente Windows): listar conexiones SMB actuales

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Format-Table -AutoSize"
ServerName ShareName UserName Credential Dialect NumOpens
---------- --------- -------- ----------- ------- --------
FS01       Finance$  CONTOSO\jdoe          3.1.1   4

Qué significa: Ya estás conectado a FS01 como CONTOSO\jdoe al recurso Finance$. Si el usuario «probó» con credenciales distintas, puede que lo haga sin saberlo.

Decisión: Si el nombre de usuario es incorrecto, desconecta y reconecta explícitamente con la cuenta prevista (ver Tarea 2).

Tarea 2 (cliente Windows): limpiar la sesión SMB en caché hacia un servidor

cr0x@server:~$ powershell -NoProfile -Command "net use \\FS01\Finance$ /delete"
\\FS01\Finance$ was deleted successfully.

Qué significa: Esa sesión SMB se ha eliminado. Ahora tu siguiente intento de acceso solicitará/negociará credenciales de nuevo.

Decisión: Vuelve a probar el acceso de inmediato. Si ahora funciona, el problema de «permisos» era el caché de credenciales.

Tarea 3 (cliente Windows): confirmar que DNS te apunta donde crees

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FS01 | Select-Object -First 3 | Format-Table -AutoSize"
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
FS01  A   60  Answer  10.10.5.21

Qué significa: El cliente resuelve FS01 a 10.10.5.21.

Decisión: Si esta IP no es tu servidor de archivos previsto (común en migraciones), estás depurando en la máquina equivocada. Arregla DNS/DFS antes de tocar ACLs.

Tarea 4 (servidor Windows): inspeccionar permisos a nivel de recurso (la puerta olvidada)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShareAccess -Name Finance$ | Format-Table -AutoSize"
Name     ScopeName AccountName        AccessControlType AccessRight
----     --------- -----------        ----------------- -----------
Finance$ *         BUILTIN\Administrators Allow          Full
Finance$ *         CONTOSO\FinanceRW      Allow          Change
Finance$ *         CONTOSO\FinanceRO      Allow          Read
Finance$ *         CONTOSO\Interns        Deny           Full

Qué significa: Hay un Deny explícito para CONTOSO\Interns. Si tu usuario pertenece a ese grupo (directa o anidada), pierde, independientemente de NTFS.

Decisión: Confirma la membresía del grupo y elimina/reemplaza el Deny por un modelo más limpio. Deny debe ser el último recurso, no tu primer instinto.

Tarea 5 (servidor Windows): mostrar la ruta física detrás de un recurso

cr0x@server:~$ powershell -NoProfile -Command "(Get-SmbShare -Name Finance$).Path"
D:\Shares\Finance

Qué significa: El recurso apunta a D:\Shares\Finance.

Decisión: Ahora sabes exactamente qué ACL de directorio inspeccionar. Sin adivinanzas.

Tarea 6 (servidor Windows): inspeccionar ACLs NTFS rápidamente

cr0x@server:~$ powershell -NoProfile -Command "icacls D:\Shares\Finance"
D:\Shares\Finance CONTOSO\FinanceRW:(OI)(CI)(M)
                 CONTOSO\FinanceRO:(OI)(CI)(RX)
                 BUILTIN\Administrators:(OI)(CI)(F)
                 NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                 Successfully processed 1 files; Failed processing 0 files

Qué significa: En la capa de sistema de archivos, el modelo parece sensato: RW tiene Modify, RO tiene Read/Execute.

Decisión: Si el usuario está en FinanceRW y aún así se le deniega, la puerta a nivel de recurso (Tarea 4) o problemas de identidad/token son más probables que NTFS.

Tarea 7 (servidor Windows): comprobar acceso efectivo (para detectar sorpresas por grupos anidados)

cr0x@server:~$ powershell -NoProfile -Command "Get-Acl D:\Shares\Finance | Select-Object -ExpandProperty Access | Select-Object -First 6 | Format-Table -AutoSize"
FileSystemRights AccessControlType IdentityReference          IsInherited InheritanceFlags PropagationFlags
---------------- ----------------- -----------------          ----------- ---------------- ---------------
Modify           Allow             CONTOSO\FinanceRW          False       ContainerInherit ObjectInherit None
ReadAndExecute   Allow             CONTOSO\FinanceRO          False       ContainerInherit ObjectInherit None
FullControl      Allow             BUILTIN\Administrators     False       ContainerInherit ObjectInherit None
FullControl      Allow             NT AUTHORITY\SYSTEM        False       ContainerInherit ObjectInherit None

Qué significa: Estás viendo los ACEs crudos. No calcula directamente el «efectivo» para un usuario específico, pero revela si hay un Deny escondido o si la herencia está rota.

Decisión: Si ves entradas explícitas inesperadas o herencia rota, arregla eso antes de tocar permisos de recurso.

Tarea 8 (servidor Windows): confirmar la membresía de grupo del usuario según el servidor

cr0x@server:~$ powershell -NoProfile -Command "whoami /groups | Select-String -Pattern 'Finance|Interns' -CaseSensitive"
BUILTIN\Administrators                                 Alias            S-1-5-32-544  Enabled
CONTOSO\FinanceRW                                      Group            S-1-5-21-...   Enabled
CONTOSO\Interns                                        Group            S-1-5-21-...   Enabled

Qué significa: El token de acceso incluye tanto FinanceRW como Interns. Si el recurso niega Interns, ese Deny gana.

Decisión: Quita al usuario del grupo denegado, o rediseña los permisos del recurso para no necesitar Deny en absoluto.

Tarea 9 (servidor Windows): verificar que la configuración del servidor SMB no esté bloqueando la autenticación

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object RejectUnencryptedAccess,RequireSecuritySignature,EnableSMB1Protocol | Format-List"
RejectUnencryptedAccess : True
RequireSecuritySignature : True
EnableSMB1Protocol : False

Qué significa: Este servidor requiere firmado y rechaza accesos sin cifrar (dependiendo de la negociación del cliente). Algunos clientes antiguos o appliances pueden fallar y reportarlo mal.

Decisión: Si el cliente que falla es antiguo o no-Windows, verifica dialecto/firmado/cifrado antes de perseguir permisos.

Tarea 10 (cliente Linux): probar listado de recursos con credenciales explícitas

cr0x@server:~$ smbclient -L //fs01 -U 'CONTOSO\jdoe'
Password for [CONTOSO\jdoe]:
        Sharename       Type      Comment
        ---------       ----      -------
        Finance$        Disk      Finance data
        IPC$            IPC       Remote IPC
SMB1 disabled -- no workgroup available

Qué significa: La autenticación tuvo éxito y el servidor listó los recursos. La línea «SMB1 disabled» es informativa en muchos casos.

Decisión: Si el listado falla con NT_STATUS_LOGON_FAILURE, aún no estás en la etapa de permisos. Arregla la autenticación o el formato del realm.

Tarea 11 (cliente Linux): intentar acceder al recurso y observar el error exacto

cr0x@server:~$ smbclient //fs01/Finance$ -U 'CONTOSO\jdoe' -c 'ls'
Password for [CONTOSO\jdoe]:
NT_STATUS_ACCESS_DENIED listing \*

Qué significa: La autenticación tuvo éxito, pero la autorización falló. Eso apunta a permisos a nivel de recurso, ACLs del sistema de archivos, o una capa de política (menos común).

Decisión: Pasa a verificaciones del lado servidor: ACL del recurso (Windows) o valid users/write list (Samba), luego ACLs del sistema de archivos.

Tarea 12 (servidor Linux con Samba): imprimir la configuración efectiva de Samba para el recurso

cr0x@server:~$ testparm -s
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_ACTIVE_DIRECTORY_MEMBER

[Finance$]
	path = /srv/shares/finance
	read only = no
	valid users = @FINANCE_RW @FINANCE_RO
	write list = @FINANCE_RW

Qué significa: Solo los miembros de FINANCE_RW o FINANCE_RO pueden acceder en absoluto. Las escrituras están restringidas a FINANCE_RW.

Decisión: Si el usuario está en AD pero Samba no lo reconoce como miembro de estos grupos en el host, investiga idmap y la resolución de grupos NSS.

Tarea 13 (servidor Linux): confirmar la identidad del usuario y el mapeo de grupos

cr0x@server:~$ id 'jdoe'
uid=123450110(jdoe) gid=123450513(domain users) groups=123450513(domain users),123450988(finance_ro),123450999(interns)

Qué significa: Desde la perspectiva Unix, jdoe pertenece a finance_ro e interns. Si el recurso espera finance_rw, no obtendrá escritura. Si el recurso bloquea interns vía invalid users o similar, puede ser denegado por completo.

Decisión: Alinea la configuración de grupos en la configuración de Samba con lo que el sistema realmente resuelve, y evita nombres de grupo ambiguos entre realms.

Tarea 14 (servidor Linux): comprobar ACLs del sistema de archivos en la ruta del recurso

cr0x@server:~$ getfacl -p /srv/shares/finance | sed -n '1,25p'
# file: /srv/shares/finance
# owner: root
# group: finance_rw
user::rwx
group::rwx
group:finance_ro:r-x
mask::rwx
other::---

Qué significa: Los permisos del sistema de archivos permiten a finance_ro leer, a finance_rw escribir, y a otros no obtener nada.

Decisión: Si Samba permite pero el sistema de archivos deniega, arregla las ACLs (o estrategias de force group/create mask). Si el sistema de archivos permite pero Samba deniega, corrige la configuración a nivel de recurso.

Tarea 15 (servidor Linux con SELinux): comprobar denegaciones SELinux que afecten a Samba

cr0x@server:~$ ausearch -m avc -ts recent | tail -n 5
type=AVC msg=audit(1700000000.123:456): avc:  denied  { read } for  pid=1200 comm="smbd" name="finance" dev="sda1" ino=123456 scontext=system_u:system_r:smbd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0

Qué significa: SELinux bloqueó a smbd leer el directorio etiquetado default_t.

Decisión: Etiqueta el directorio correctamente para Samba (o configura el boolean/política SELinux). No soluciones esto con chmod.

Tarea 16 (servidor Windows): verificar que los permisos del recurso no derivaron del estándar

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Where-Object Name -like '*$' | Select-Object Name,Path | Sort-Object Name | Format-Table -AutoSize"
Name      Path
----      ----
Finance$  D:\Shares\Finance
HR$       D:\Shares\HR
Legal$    D:\Shares\Legal

Qué significa: Tienes múltiples recursos ocultos de estilo administrativo. La deriva tiende a ocurrir por recurso, no a nivel de servidor completo.

Decisión: Compara ACLs de recursos entre recursos. Si Finance$ es el único con un Deny o una ACL de recurso personalizada, probablemente hayas encontrado la causa.

Tres micro-historias del mundo corporativo

1) Incidente causado por una suposición equivocada: «NTFS lo es todo»

La empresa tenía un patrón de servidor de archivos ordenado: los permisos de recurso estaban en «Everyone: Full Control», y NTFS hacía el trabajo real. Es una práctica común. Reduce el número de piezas en movimiento y facilita las auditorías porque un sistema es el autoritativo.

Luego llegó un cambio por cumplimiento durante un trimestre ocupado. Alguien endureció temporalmente los permisos del recurso en un recurso particularmente sensible. Añadieron un Deny para un grupo amplio que «no debería» tener acceso. En papel se veía limpio: quitar una gran población con una regla.

El lunes por la mañana, un analista senior no pudo abrir archivos de fin de mes. Su gerente escaló, luego Finanzas escaló, luego el helpdesk lo convirtió en una «caída del servidor de archivos» porque esa es la única categoría con urgencia asignada. Taxonomía corporativa clásica: si está roto, es infraestructura.

El SRE de guardia comprobó la salud del almacenamiento. Bien. Revisó la red. Bien. Revisó la ACL NTFS. Bien. El analista estaba en el grupo correcto FinanceRW. Todos se relajaron—hasta que alguien miró Get-SmbShareAccess y notó un Deny en un grupo anidado que incluía al analista por un paquete de incorporación legado.

La solución fue simple: quitar el Deny y reemplazarlo por un modelo de lista de permitidos en NTFS. La lección no lo fue. El postmortem anotó la causa raíz real: una suposición incrustada en la organización («los permisos de recurso son irrelevantes») chocó con un cambio puntual que nadie revisó porque parecía «pequeño».

2) Optimización que salió mal: «Aceleremos con DFS y consolidación»

En otro lugar, otro sabor de dolor. Consolidaron servidores de archivos e introdujeron namespaces DFS para que los usuarios siguieran usando \\corp\files\... mientras el almacenamiento se movía por debajo. Esto es modernización normal. También es una gran forma de depurar el sistema equivocado durante días.

Para «optimizar», redirigieron un recurso muy usado a un servidor backend nuevo con discos más rápidos y mejor monitoreo. Funcionó para la mayoría. Para un subgrupo pequeño, el acceso empezó a fallar intermitentemente con «Access Denied». Intermitente es una palabra fuerte; significa «nadie te cree hasta que pasa en una pantalla compartida».

Resultó que las referencias DFS enviaban a algunos clientes al objetivo nuevo y a otros al antiguo según site costing y referencias en caché. Los dos objetivos tenían permisos de recurso ligeramente diferentes. NTFS estaba espejado. Las ACLs de recurso no lo estaban. Así que la misma ruta tenía éxito o fallo puramente según en qué servidor aterrizases.

La «optimización» no fue DFS; DFS hacía exactamente lo que debía. El problema fue asumir que los permisos de recurso serían «iguales en todas partes» sin aplicarlos como código. Una vez estandarizaron plantillas de ACL de recurso y las validaron durante cambios, las fallas intermitentes desaparecieron.

3) Práctica aburrida pero correcta que salvó el día: «Un plano de control, y prueba desde el cliente»

En una organización de salud, el equipo de servicios de archivos era alérgico a la creatividad. Tenían una política: permisos de recurso siempre permisivos, NTFS es autoritativo, y las entradas Deny requieren revisión por pares. También exigían que cada ticket de cambio incluyera una prueba desde el cliente usando la identidad real del usuario, no una cuenta admin «porque es más fácil».

Una tarde, una aplicación clínica empezó a fallar al escribir informes en un recurso. El equipo de la app dijo «el almacenamiento está lleno» (no lo estaba). Red dicen «SMB está caído» (no lo estaba). El equipo de archivos pidió los campos de la plantilla del ticket: nombre del recurso, ruta, usuario, hostname del cliente, error exacto y una prueba usando la cuenta de servicio.

Descubrieron que la cuenta de servicio había sido rotada y la nueva cuenta no se añadió al grupo NTFS. Los permisos de recurso eran permisivos, así que no hubo una segunda puerta que confundiera las cosas. La corrección de la ACL tomó minutos, no horas.

No pasó nada heroico. No hubo war room. No hubo restauración a medianoche. La práctica correcta—aburrida, consistente, documentada—hizo la falla obvia. Así es la fiabilidad: menos historias interesantes.

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

1) «Puedo acceder localmente pero no vía \\server\share» → el recurso deniega

Síntoma: El usuario puede abrir la carpeta cuando inicia sesión en el servidor (RDP/consola) pero recibe «Access Denied» por SMB.

Causa raíz: El acceso local usa NTFS; el acceso SMB usa permisos de recurso + NTFS. La puerta del recurso lo bloquea.

Solución: En Windows, ejecuta Get-SmbShareAccess y corrige la ACL del recurso. En Samba, revisa valid users/write list.

2) «Solo este usuario está denegado» → pertenece a un grupo denegado (a menudo anidado)

Síntoma: Mismo rol, mismo equipo, un usuario falla. Todos sospechan «perfil corrupto» o «Windows siendo Windows».

Causa raíz: Un Deny explícito se aplica por membresía de grupo anidada, o su token incluye un grupo legado.

Solución: Comprueba whoami /groups (Windows) o id (Linux). Quita al usuario del grupo denegado o elimina la entrada Deny rediseñando el modelo de permitidos.

3) «Funciona tras reiniciar/cerrar sesión» → token de acceso obsoleto o credenciales en caché

Síntoma: Añades al usuario a un grupo, no pasa nada, y luego mágicamente funciona.

Causa raíz: Los tokens de Windows se crean al iniciar sesión; los cambios en membresía no se reflejan hasta un nuevo inicio. Las sesiones SMB también cachean credenciales por servidor.

Solución: Cierra sesión/abrete sesión de nuevo (o reinicia la sesión del servicio/usuario en cuentas de servicio). Limpia sesiones SMB con net use ... /delete y vuelve a probar con credenciales explícitas.

4) «Leer funciona, escribir está denegado» → el recurso está en Read o la write list de Samba lo excluye

Síntoma: El usuario puede explorar y abrir archivos pero no crear/renombrar/borrar.

Causa raíz: El recurso a nivel de recurso está Read-only, o la write list de Samba no lo incluye, o NTFS concede solo RX.

Solución: Compara los derechos de acceso del recurso (Read/Change) vs NTFS Modify. En Samba, asegura read only = no y que write list coincida con el grupo previsto.

5) «Acceso denegado intermitente» → referencias DFS o múltiples destinos con ACLs de recurso desiguales

Síntoma: La misma ruta a veces funciona, a veces falla, a menudo según ubicación o tiempo.

Causa raíz: DFS envía clientes a distintos servidores; los permisos de recurso difieren entre objetivos.

Solución: Estandariza permisos de recurso en todos los objetivos. Verifica a qué servidor está conectado un cliente antes de depurar.

6) «Samba niega pero el sistema de archivos parece abierto» → SELinux/AppArmor lo bloquea

Síntoma: Los bits de modo/ACLs muestran permitir, pero SMB aún devuelve acceso denegado.

Causa raíz: El control de acceso obligatorio niega a smbd.

Solución: Inspecciona denegaciones AVC y etiqueta las rutas correctamente; no trates SELinux como un rumor.

7) «Todos acceden excepto máquinas no unidas al dominio» → incompatibilidad del modelo de autenticación

Síntoma: Máquinas unidas al dominio funcionan; clientes no unidos fallan con errores de «denegado» confusos.

Causa raíz: El servidor requiere Kerberos, firmado, o políticas de autenticación específicas; o Samba mapea usuarios desconocidos a guest y guest está bloqueado.

Solución: Confirma el método de autenticación; para Samba revisa map to guest y derechos de guest; en Windows revisa las políticas del servidor SMB.

Listas de verificación / plan paso a paso

Paso a paso: diagnosticar un usuario que no accede a un recurso

1. Identifica la ruta UNC exacta que usa el usuario. Si es un namespace DFS, pésalo.
2. Desde el cliente, lista conexiones SMB activas (Tarea 1). Confirma el nombre de usuario.
3. Limpia sesiones obsoletas hacia el servidor objetivo (Tarea 2). Reconecta con credenciales explícitas.
4. Verifica la resolución de nombres (Tarea 3). Confirma que alcanzas el servidor/IP correcto.
5. Prueba autenticación vs autorización usando smbclient (Tareas 10–11) o intentos de mapeo en Windows. Si falla la autenticación, detente y arregla auth.
6. En el servidor, vuelca permisos de recurso (Tarea 4). Busca faltas de allows y denies explícitos.
7. Confirma la ruta del recurso (Tarea 5). Asegúrate de revisar la carpeta correcta.
8. Comprueba ACLs del sistema de archivos (Tarea 6). Asegura que el grupo correcto tiene Modify/Write y que la herencia tiene sentido.
9. Comprueba token/membresía de grupo (Tarea 8 / Tarea 13). Confirma la vista del servidor, no la del sistema de RRHH.
10. Si es Samba, valida la configuración en tiempo de ejecución (Tarea 12) y la resolución idmap/grupos (Tarea 13).
11. Si es Linux, revisa la capa MAC (Tarea 15) si los permisos parecen correctos pero el acceso sigue fallando.
12. Cambia una cosa, vuelve a probar inmediatamente y documenta qué puerta fallaba y por qué.

Un estándar seguro que previene la mayoría de incidentes de permisos SMB

• Windows: Configura permisos de recurso de forma amplia (a menudo «Authenticated Users: Full» o equivalente aprobado por política) y aplica el acceso real con grupos NTFS. Mantén las entradas Deny raras y revisadas.
• Samba: Sé explícito y consistente: define valid users y write list usando un esquema de nombres de grupos predecible. Evita excepciones creativas por recurso a menos que te guste el pager.
• En todas partes: Trata el mapeo de identidades como infraestructura de producción. Si cambias backends o rangos de idmap, estás cambiando «quién es quién» en disco.

Checklist operativa para cambios (permisos, recursos, migraciones)

• Registra la ACL actual del recurso y la ACL del sistema de archivos antes de cambios (capturas no son un sistema de control).
• Prueba con un usuario no-admin real además de la cuenta de servicio usada por automatizaciones/aplicaciones.
• Para DFS: prueba cada objetivo directamente (\\server\share) y a través del namespace.
• Después de cambios en membresías de grupo: asegura que los usuarios refresquen tokens (cerrar sesión/abrir sesión) para validación.
• Anota el modelo de permisos previsto: «recurso permisivo, filesystem restrictivo» o «recurso restrictivo, filesystem alineado». No lo dejes accidental.

Broma #2: El Deny ACE «temporal» tiene el mismo ciclo de vida que una base de datos de staging: es para siempre, solo que con peor documentación.

Preguntas frecuentes (FAQ)

1) ¿Cuál es «el permiso que todos pasan por alto»?

La puerta a nivel de recurso: permisos de recurso en Windows o restricciones en la definición del recurso en Samba. La gente se obsesiona con ACLs NTFS/POSIX y olvida que el recurso puede bloquear el acceso primero.

2) En Windows, ¿debería poner permisos de recurso en Everyone: Full Control?

En muchas empresas, la variante moderna más segura es «Authenticated Users» (depende de la política) con Full Control en el recurso, y luego aplicar el acceso real con grupos NTFS. La clave es la consistencia: un lugar autoritativo para las restricciones.

3) ¿Por qué Deny causa tantos errores extraños?

Porque es contundente y gana. Los usuarios acumulan membresías de grupo con el tiempo (grupos de proyecto, paquetes de incorporación, grupos anidados). Un único Deny puede anular múltiples allows de formas que no son obvias con una mirada rápida.

4) Añadí al usuario al grupo AD correcto. ¿Por qué aún se le deniega?

Pueden estar usando credenciales SMB en caché, o su token de acceso no incluye aún el nuevo grupo. Limpia sesiones SMB y que cierren sesión/abran sesión (o reinicia la sesión del servicio para cuentas de servicio).

5) ¿Por qué un administrador puede acceder y el usuario no?

Los administradores a menudo tienen derechos elevados, membresías de grupo distintas, o efectos de bypass (como acceso local de administrador) que no reflejan la autorización SMB normal. Siempre prueba con la identidad real del usuario o con una cuenta de prueba equivalente.

6) ¿Cómo digo si la falla es autenticación o autorización?

Si puedes listar recursos pero no directorios dentro del recurso, la autenticación tuvo éxito y la autorización falló. Herramientas como smbclient lo hacen visible: NT_STATUS_LOGON_FAILURE vs NT_STATUS_ACCESS_DENIED.

7) ¿Pueden las políticas de firmado/cifrado SMB parecer «Access Denied»?

Sí. Dependiendo del cliente y del manejo de errores, la aplicación de políticas puede aparecer como errores genéricos de acceso. Revisa la configuración del servidor (y las capacidades del cliente) antes de reescribir ACLs.

8) En Samba, configuré correctamente permisos del sistema de archivos. ¿Por qué Samba sigue denegando?

Porque Samba puede estar restringiendo el recurso vía valid users, read list, write list o restricciones de host, o estar mapeando tu usuario al UID/GID equivocado. Inspecciona testparm -s y verifica la salida de id para el usuario.

9) ¿Cuál es el comando servidor-lado más rápido en Windows para problemas de permisos de recurso?

Get-SmbShareAccess -Name <share>. Si el grupo previsto no aparece con el acceso correcto, o existe un Deny, probablemente encontraste el problema.

10) ¿Qué frase encaja mejor con todo este lío?

Werner Vogels (idea parafraseada): todo falla eventualmente, así que diseña y opera asumiendo fallos—y haz que el diagnóstico sea rápido.

Conclusión: próximos pasos que realmente funcionan

Cuando SMB dice «Access Denied», no empieces reescribiendo ACLs NTFS como si estuvieras realizando un exorcismo. Comprueba lo básico: servidor correcto, identidad correcta, autenticación vs autorización. Luego revisa la puerta del recurso—porque esa es la que todos olvidan que existe.

Haz esto a continuación:

1. Estandariza tu modelo: o «recurso permisivo, filesystem restrictivo» (común en Windows) o una lista de permitidos explícita en Samba respaldada por un mapeo de identidades consistente.
2. Prohíbe entradas Deny casuales: requieren revisión por pares y una razón documentada. Deny es un bisturí que la gente usa como una pala.
3. Conviértelo en memoria muscular: la guía de diagnóstico: comprobación de sesión cliente, permisos de recurso, ACLs del sistema de archivos, mapeo de identidades/refresh de token, capas de política.
4. Automatiza la detección de deriva: si ejecutas múltiples servidores de archivos o objetivos DFS, asegura que los permisos a nivel de recurso sean consistentes y auditables.

Si no haces nada más, haz esto: cuando alguien diga «pero NTFS está correcto», responde «muéstrame los permisos del recurso». Luego disfruta del repentino silencio en la sala—el tipo productivo.