Ubuntu 24.04: montaje CIFS muestra «Permiso denegado» — las opciones exactas que lo solucionan

noviembre 27, 2025 • febrero 3, 2026 • Lectura: 27 min • Views: 6

¿Te fue útil?

Escribiste el comando mount que has ejecutado cien veces. Funcionó en Ubuntu 22.04. Funcionó en ese host antiguo que nadie se atreve a actualizar. Ahora en Ubuntu 24.04 obtienes la clásica y inútil respuesta: «Permiso denegado».

Esta es una de esas fallas en las que el servidor técnicamente dice la verdad, pero el cliente está hablando otro dialecto. La corrección suele ser una sola opción de montaje. Lo difícil es saber cuál opción y demostrarlo antes de “arreglarlo” y empeorar el problema.

Guía rápida de diagnóstico (comprueba esto primero)

Si estás de guardia, no tienes tiempo para convertirte en un historiador parcial de SMB. Aquí está la ruta más rápida hacia el cuello de botella probable, en el orden correcto.

1) Confirma que el servidor habla la versión SMB que estás pidiendo

La mayoría de los tickets “Permiso denegado” en Ubuntu 24.04 son en realidad “negociación de protocolo y expectativas de autenticación cambiaron”. Empieza por el dialecto SMB.

Si el servidor es antiguo o está muy restringido: especifica vers=3.0 o vers=2.1 explícitamente.
Si es un equipo NAS muy antiguo: puede que necesites vers=1.0 (y entonces deberías planificar su reemplazo).

2) Confirma el mecanismo de autenticación (sec=) coincide con la política del servidor

Windows y muchos dispositivos NAS están rechazando cada vez más variantes NTLM. Algunos entornos requieren Kerberos. Algunas políticas de “endurecimiento” requieren solo NTLMv2. Haz sec= explícito y deja de adivinar.

3) Revisa el log del kernel para la razón real (no confíes en la línea única de mount)

mount.cifs tiende a resumir todo como “Permission denied”. El cliente CIFS del kernel te dirá si es contraseña mala, SPN incorrecto, clave ausente, desajuste de reloj o fallo de firma.

4) Demuestra que tus credenciales son lo que piensas

Dominio equivocado, formato de usuario incorrecto, caracteres especiales en contraseñas o un archivo de credenciales con finales de línea de Windows pueden traducirse en “permission denied”. Sí, incluso en 2025.

5) Solo entonces persigue permisos de sistema de archivos y ACL

Los permisos POSIX a menudo no son el primer problema. En SMB puedes autenticarte correctamente y aun así que el share niegue el acceso por permisos o ACLs NTFS. Pero si no te autenticas, las comprobaciones de permisos son irrelevantes.

Una regla operativa: no cambies tres variables a la vez. Dialecto, autenticación y mapeo de identidad son tres diales separados. Gíralos uno a la vez y observa.

Qué significa realmente “Permiso denegado” para CIFS en Ubuntu 24.04

En Linux, “Permiso denegado” en un montaje CIFS suele mapear a EACCES (error 13). Ese error se lanza por múltiples situaciones distintas:

Fallo de autenticación (usuario/contraseña incorrectos, dominio equivocado, método de auth incorrecto).
Fallo de autorización (te autenticaste, pero el recurso compartido deniega el acceso).
Desajuste de negociación (dialecto SMB o firma/cifrado incompatible, a veces expuesto como acceso denegado).
Fallo de la canalización Kerberos (sin ticket, SPN incorrecto, desajuste de reloj, keytab incorrecto).
Desajuste de políticas de máquina (servidor rechaza guest, rechaza NTLM, requiere firma o requiere cifrado).
Confusión de mapeo en el cliente (el montaje tiene éxito pero las operaciones fallan; las apps reportan “permission denied” después).

Ubuntu 24.04 no está “rompiendo CIFS” por diversión. Trae kernels más recientes, herramientas cliente Samba más modernas y valores por defecto más estrictos en ecosistemas que intentan eliminar configuraciones SMB/NTLM inseguras. Eso es bueno para la seguridad. Es malo para tu sueño.

Idea parafraseada (atribuida): Werner Vogels ha argumentado que deberías construir sistemas asumiendo que la falla es normal, y luego diseñar para la recuperación. El montaje CIFS es un ejemplo perfecto: asume que la negociación y la autenticación fallarán de maneras nuevas y creativas, y construye un camino de diagnóstico repetible.

Las opciones de montaje exactas que lo arreglan (copiar/pegar y ajustar)

A continuación están los conjuntos de opciones de montaje que más a menudo convierten un “Permiso denegado” en Ubuntu 24.04 en un montaje limpio. Empieza por el que coincida con tu entorno. No improvises.

Caso A: Servidor Windows / Samba moderno, credenciales locales (el más común)

Si montas un recurso con usuario/contraseña (no Kerberos) y no quieres sorpresas:

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,seal,sign,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,nofail,x-systemd.automount

Por qué funciona:

vers=3.0: hace explícita la negociación; evita comportamientos de retroceso “útiles” que varían según el servidor.
sec=ntlmssp: común en Windows cuando no se usa Kerberos.
sign: satisface a los servidores que requieren firma; si el servidor no lo exige, firmar suele estar bien.
seal: habilita cifrado SMB3 donde esté soportado; si el servidor requiere cifrado, evita una denegación.
uid/gid + file_mode/dir_mode: proporciona propiedad/modo consistentes para procesos Linux.
x-systemd.automount: evita bloqueos en el arranque y hace los montajes más resistentes.

Caso B: El servidor Windows exige firma, pero no hay cifrado

Si seal causa problemas (servidor más antiguo, preocupaciones de rendimiento o la política del servidor no lo soporta), quítalo pero mantén la firma:

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign,uid=1000,gid=1000,dir_mode=0770,file_mode=0660

Caso C: NAS antiguo o Samba antiguo que no soporta SMB3

Aquí es donde “Permiso denegado” a menudo oculta un rechazo por dialecto. Prueba SMB2.1 primero:

cr0x@server:~$ sudo mount -t cifs //nas01/Archive /mnt/archive \
  -o credentials=/etc/cifs/archive.cred,vers=2.1,sec=ntlmssp,uid=1000,gid=1000,dir_mode=0775,file_mode=0664

Si el dispositivo es realmente antiguo, vers=1.0 podría ser la única respuesta. También es una buena razón para solicitar su reemplazo con un asunto muy calmado.

Caso D: Active Directory con Kerberos (el especial “funciona en un host”)

Para entornos integrados con AD, Kerberos es la elección correcta a largo plazo. También falla de maneras más interesantes.

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Engineering /mnt/eng \
  -o vers=3.0,sec=krb5,cruid=1000,multiuser,seal,sign,uid=1000,gid=1000,dir_mode=0770,file_mode=0660

Notas: cruid= ata la caché de credenciales del montaje al usuario local correcto. multiuser permite que múltiples usuarios usen sus credenciales Kerberos en un mismo montaje (útil en hosts compartidos, peligroso si no lo entiendes).

Caso E: Usuario de dominio con NTLMSSP, pero el formato del dominio es el culpable

Aquí “permiso denegado” es solo que tu nombre de usuario no se analiza como crees. Usa una de estas formas:

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o username='EXAMPLE\jdoe',password='REDACTED',vers=3.0,sec=ntlmssp

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o username='jdoe',domain='EXAMPLE',password='REDACTED',vers=3.0,sec=ntlmssp

Caso F: El recurso permite guest, pero Ubuntu ya no asume “guest”

El acceso guest está cada vez más bloqueado (por buenas razones). Pero si realmente tienes un share público de solo lectura:

cr0x@server:~$ sudo mount -t cifs //nas01/Public /mnt/public \
  -o guest,vers=3.0,sec=none,ro,uid=1000,gid=1000,dir_mode=0555,file_mode=0444

Sé explícito. Si el servidor rechaza guest, esto seguirá fallando, pero ahora sabes que no estás enviando por accidente un nombre de usuario que no querías.

Broma #1: SMB es el único protocolo que puede ser simultáneamente “retrocompatible” y “ya no soporta la cosa que has usado durante 12 años”.

Tareas prácticas: comandos, salidas y la decisión a tomar (12+)

Esta es la parte que usas durante incidentes. Cada tarea tiene: el comando, qué significa la salida y qué decisión tomar a continuación.

Task 1: Confirma la versión del kernel y de cifs-utils (la línea de base importa)

cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ dpkg -l | grep -E '^ii\s+cifs-utils'
ii  cifs-utils  2:7.0-2ubuntu2  amd64  Common utilities for SMB/CIFS mounts

Significado: Estás en la pila cliente CIFS más reciente; los valores por defecto y las capacidades de seguridad difieren de hosts más antiguos.

Decisión: Deja de comparar comportamiento con Ubuntu 20.04/22.04 a menos que también compares sec, vers y requisitos de firma/cifrado.

Task 2: Verifica la resolución de nombres (errores de permiso pueden enmascarar “servidor equivocado”)

cr0x@server:~$ getent hosts filesrv01.example.com
10.20.30.40  filesrv01.example.com

Significado: DNS resuelve a una IP. Si resuelve a una IP diferente a la esperada (VIP movido, DNS dividido, /etc/hosts obsoleto), podrías estar autenticándote en la máquina equivocada.

Decisión: Si la IP es inesperada, arregla DNS/hosts antes de tocar opciones de montaje.

Task 3: Confirma que el puerto TCP es accesible (los firewalls mienten calladamente)

cr0x@server:~$ nc -vz filesrv01.example.com 445
Connection to filesrv01.example.com (10.20.30.40) 445 port [tcp/microsoft-ds] succeeded!

Significado: El puerto 445 es accesible. Si falla, no tienes un problema de autenticación: tienes un problema de red.

Decisión: Si está bloqueado, detente. Escala a red/seguridad; no “arregles” opciones CIFS.

Task 4: Lista shares con smbclient (comprobación de sanidad de autenticación)

cr0x@server:~$ smbclient -L //filesrv01.example.com -U 'EXAMPLE\jdoe'
Password for [EXAMPLE\jdoe]:
        Sharename       Type      Comment
        ---------       ----      -------
        Finance         Disk      Finance Share
        Engineering     Disk      Engineering Share
        IPC$            IPC       Remote IPC
SMB1 disabled -- no workgroup available

Significado: Las credenciales son aceptadas y la negociación SMB funciona. Eso es la mitad de la batalla.

Decisión: Si smbclient falla con NT_STATUS_ACCESS_DENIED, céntrate en username/password/domain/sec. Si funciona pero el montaje falla, céntrate en opciones de montaje (firma/cifrado, vers, Kerberos, idmap).

Task 5: Prueba acceso al share específico (ACL del share vs fallo de montaje)

cr0x@server:~$ smbclient //filesrv01.example.com/Finance -U 'EXAMPLE\jdoe' -c 'ls'
Password for [EXAMPLE\jdoe]:
  .                                   D        0  Mon Dec  9 12:01:00 2025
  ..                                  D        0  Mon Dec  9 12:01:00 2025
  budgets                             D        0  Mon Dec  9 12:01:00 2025

                104857600 blocks of size 1024. 51372800 blocks available

Significado: Puedes autenticarte y acceder al contenido del share. Si el montaje sigue diciendo “permission denied”, el problema casi siempre es negociación/seguridad, no ACLs/NTFS.

Decisión: Prueba vers= y sec= explícitos, luego firma/cifrado.

Task 6: Ejecuta el mount con salida detallada (pistas desde user-space)

cr0x@server:~$ sudo mount -vvv -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign
mount.cifs kernel mount options: ip=10.20.30.40,unc=\\filesrv01.example.com\Finance,vers=3.0,sec=ntlmssp,sign
mount error(13): Permission denied

Significado: Sigue siendo ambiguo. Por eso revisamos los logs del kernel a continuación.

Decisión: Ve a dmesg y busca mensajes CIFS con la causa real.

Task 7: Lee mensajes del kernel para CIFS (la verdad está aquí)

cr0x@server:~$ sudo dmesg -T | tail -n 30
[Mon Dec 29 10:15:22 2025] CIFS: VFS: \\filesrv01.example.com Send error in SessSetup = -13
[Mon Dec 29 10:15:22 2025] CIFS: VFS: cifs_mount failed w/return code = -13

Significado: Falló la configuración de sesión (auth/negociación). A veces verás líneas más específicas como “Server requires packet signing” o “Krb5 authentication failed”.

Decisión: Si los logs mencionan firma/cifrado, añade sign y/o seal. Si mencionan Kerberos, pasa a diagnósticos de Kerberos.

Task 8: Confirma qué modos de seguridad cree que puede usar el cliente

cr0x@server:~$ modinfo cifs | grep -E 'parm:|version' | head
version:        2.45
parm:           CIFSMaxBufSize:Network buffer size (int)
parm:           SecurityFlags:SecurityFlags, comma separated (int)

Significado: El módulo CIFS del kernel está presente y es moderno. No vas a “arreglar” esto reinstalando cifs-utils.

Decisión: Céntrate en la configuración y el desajuste con la política del servidor, no en cambios de paquetes.

Task 9: Inspecciona el archivo de credenciales por problemas de formato (permisos y CRLF)

cr0x@server:~$ sudo ls -l /etc/cifs/finance.cred
-rw------- 1 root root 58 Dec 29 10:01 /etc/cifs/finance.cred
cr0x@server:~$ sudo sed -n '1,5p' /etc/cifs/finance.cred
username=jdoe
password=REDACTED
domain=EXAMPLE

Significado: El archivo es legible solo por root (bien). Si es legible por todos, has creado una fuga de credenciales.

Decisión: Si el archivo vino de herramientas Windows, comprueba CRLF. CRLF puede hacer que la contraseña sea incorrecta de una forma que no verás a simple vista.

cr0x@server:~$ sudo cat -A /etc/cifs/finance.cred
username=jdoe$
password=REDACTED$
domain=EXAMPLE$

Significado: $ al final de línea indica LF. Si ves ^M$, conviértelo (dos2unix) y reintenta.

Decisión: Arregla los finales de línea antes de culpar al servidor.

Task 10: Prueba un dialecto SMB diferente (rápido, reversible)

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.1.1,sec=ntlmssp,sign
mount error(13): Permission denied
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign

Significado: Si 3.1.1 falla pero 3.0 tiene éxito, el servidor podría ser exigente sobre negociación o características de seguridad ligadas a dialectos más nuevos.

Decisión: Fija el vers que funcione explícitamente en /etc/fstab y documenta por qué.

Task 11: Prueba modo de seguridad explícito (sec=) en lugar de depender de valores por defecto

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmv2,sign
mount error(13): Permission denied
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign

Significado: Algunos servidores aceptan ntlmssp pero rechazan ntlmv2 (o al revés). En contextos AD, puede esperarse Kerberos en su lugar.

Decisión: Si ntlmssp no funciona y la política dice “solo Kerberos”, deja de forzar NTLM y pasa a configurar Kerberos.

Task 12: Verifica que el montaje está usando realmente las opciones que crees

cr0x@server:~$ mount | grep /mnt/finance
//filesrv01.example.com/Finance on /mnt/finance type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=jdoe,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,soft,nounix,serverino,mapposix,nofail)

Significado: El montaje en ejecución muestra los ajustes negociados. Esto detecta el clásico problema donde editaste /etc/fstab pero no remonteaste, o estás mirando el punto de montaje equivocado.

Decisión: Si el vers o sec mostrados no son lo que pretendías, no estás probando lo correcto.

Task 13: Confirma que las operaciones sobre archivos realmente funcionan (el montaje exitoso aún puede ocultar problemas de permisos)

cr0x@server:~$ touch /mnt/finance/.cifs-write-test
touch: cannot touch '/mnt/finance/.cifs-write-test': Permission denied

Significado: Montaste el share, pero no tienes permiso para escribir. Eso es un problema de autorización/ACL, no de negociación del montaje.

Decisión: Valida permisos del share y ACLs NTFS para el usuario. No sigas cambiando sec y vers; ya accediste.

Task 14: Inspecciona comportamiento tipo ACL desde Linux (detecta confusión de mapeo)

cr0x@server:~$ ls -ld /mnt/finance
drwxrwx--- 2 cr0x cr0x 0 Dec 29 10:20 /mnt/finance
cr0x@server:~$ ls -l /mnt/finance | head
total 0
drwxrwx--- 2 cr0x cr0x 0 Dec  9 12:01 budgets

Significado: La propiedad/modos locales son una presentación del cliente, no necesariamente la realidad NTFS del servidor (a menos que uses extensiones POSIX SMB de extremo a extremo).

Decisión: Si las apps Linux dependen de semántica POSIX, decide si necesitas Samba en el servidor con un mapeo POSIX adecuado, o si SMB es solo un transporte para acceso “tonto” a archivos.

Casos de Active Directory / Kerberos (donde “permiso denegado” miente)

Si tu organización usa AD, es probable que alguien haya aplicado “NTLM: disabled” o “SMB signing required” mediante políticas. Eso no es un bug. Es una restricción operativa. El cliente CIFS debe coincidir con los ajustes de autenticación e integridad que exige el servidor.

Prerequisitos Kerberos que no puedes desear fuera

Sincronización de tiempo debe ser sensata. Kerberos es alérgico a la deriva de reloj.
DNS debe ser correcto. Kerberos usa SPN que dependen de los nombres.
Cache de tickets debe existir para el usuario que hace el montaje (o debes usar un keytab y el modo de montaje correcto).

Task 15: Comprueba la sincronización de tiempo (Kerberos lo exige, mucho)

cr0x@server:~$ timedatectl
               Local time: Mon 2025-12-29 10:22:11 UTC
           Universal time: Mon 2025-12-29 10:22:11 UTC
                 RTC time: Mon 2025-12-29 10:22:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: El tiempo está sincronizado. Si no lo está, Kerberos puede fallar como “permission denied” porque nunca te autenticaste correctamente.

Decisión: Si no está sincronizado, arregla NTP/chrony antes de cualquier ajuste CIFS.

Task 16: Verifica que tienes tickets Kerberos (comprobación en espacio de usuario)

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

Valid starting     Expires            Service principal
12/29/25 10:00:01  12/29/25 20:00:01  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Significado: Tienes un TGT. Si no lo tienes, un montaje con sec=krb5 fallará.

Decisión: Obtén un ticket con kinit, o usa un enfoque con keytab de sistema si debe ser no interactivo.

Task 17: Prueba montaje Kerberos con cruid explícito (evita caché equivocada)

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Engineering /mnt/eng \
  -o vers=3.0,sec=krb5,cruid=1000,sign,seal

Significado: Si esto funciona pero el mismo comando sin cruid falla, estabas usando la caché de credenciales equivocada (común al usar sudo).

Decisión: Estandariza montajes Kerberos con cruid y unidades systemd automount, no con sesiones sudo ad-hoc.

Broma #2: Kerberos es como el portero de un club nocturno: seguridad impecable y absolutamente sin paciencia si tu reloj se adelanta cinco minutos.

UID/GID mapping y por qué tus archivos “funcionan” pero tus apps no

Este es el modo de fallo más silencioso. El montaje tiene éxito. Listados de directorio funcionan. Luego tu aplicación falla al crear archivos de bloqueo, o tu trabajo CI no puede chmod, o tu contenedor no puede escribir.

Hay dos mundos amplios:

“Mapeo de presentación” donde fuerzas la propiedad con uid=, gid= y modos. Esto es común y a menudo suficiente.
Mapeo de identidad real donde los SIDs se mapean a IDs POSIX. Esto es más complejo y suele ser una elección empresarial, no un ajuste solo del cliente Linux.

Qué hacer en clientes Ubuntu (predeterminado pragmático)

A menos que tengas un diseño completo de identidad AD→POSIX, no finjas que lo tienes. Usa mapeo simple:

uid=, gid= para hacer la propiedad predecible para la cuenta de servicio consumidora.
file_mode=, dir_mode= para coincidir con lo que espera el proceso Linux.
Considera noperm si el servidor aplica ACLs y no quieres que el cliente Linux cuestione el acceso (esto puede ser útil, y puede ser peligroso).

Task 18: Detecta el escenario que necesita “noperm”

cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,uid=1000,gid=1000,dir_mode=0770,file_mode=0660
cr0x@server:~$ sudo -u '#1000' ls /mnt/finance
ls: cannot open directory '/mnt/finance': Permission denied

Significado: La comprobación de permisos en el cliente está denegando el acceso para el UID local, aunque el servidor podría permitirlo basándose en credenciales SMB.

Decisión: Prueba noperm solo si entiendes que el servidor es la fuente de la verdad y no dependes de los bits de modo locales para la aplicación de acceso.

cr0x@server:~$ sudo umount /mnt/finance
cr0x@server:~$ sudo mount -t cifs //filesrv01.example.com/Finance /mnt/finance \
  -o credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,noperm,uid=1000,gid=1000,dir_mode=0770,file_mode=0660

Firma, cifrado y el impuesto de seguridad corporativo

La firma SMB y el cifrado SMB son las dos palancas de política que más a menudo se convierten en “Permiso denegado” cuando los clientes no cumplen.

Firma SMB

Firma protege la integridad: evita la manipulación. Muchos entornos Windows la requieren, especialmente para shares relacionados con el dominio o servidores endurecidos.

En montajes CIFS de Linux, puedes forzarla con sign. Si el servidor exige firma y el cliente no la hace, el servidor puede rechazar la configuración de sesión o operaciones posteriores.

Cifrado SMB (seal)

Cifrado protege la confidencialidad. El cifrado SMB3 se negocia y puede requerirse por share en Windows. En Linux, seal habilita el cifrado.

El cifrado puede reducir el rendimiento e incrementar la CPU. A veces es aceptable. A veces es un incidente de rendimiento esperando pasar. El punto es: hazlo explícito y planifica capacidad.

Task 19: Detecta fallos relacionados con firma/cifrado en logs del kernel

cr0x@server:~$ sudo dmesg -T | grep -i cifs | tail -n 10
[Mon Dec 29 10:30:10 2025] CIFS: VFS: Server requires packet signing to be enabled
[Mon Dec 29 10:30:10 2025] CIFS: VFS: cifs_mount failed w/return code = -13

Significado: Te están negando porque no firmaste.

Decisión: Añade sign y reintenta. Si ya tienes sign y sigues viendo esto, puede que estés negociando un dialecto antiguo: fija vers=3.0 o superior.

Tres microhistorias corporativas desde el terreno

1) Incidente causado por una suposición equivocada: “Permiso denegado significa que la contraseña está mal”

Tenían una integración de nómina en una pequeña flota Ubuntu. Los shares vivían en Windows. Una actualización rutinaria de SO movió dos nodos de aplicación a Ubuntu 24.04. El montaje falló al arrancar. El equipo asumió que hubo una rotación de credenciales porque, bueno, eso es lo que siempre pasa cuando algo dice “permission denied”.

La respuesta inmediata fue predecible: reemitir contraseñas, revisar el gestor de secretos, regenerar cuentas de servicio. Pasaron horas. Nada cambió. Los nodos antiguos seguían montando bien. Los nuevos no. Eso debería haber sido la pista, pero los incidentes no premian la sutileza.

Finalmente alguien revisó dmesg y encontró que el servidor requería firma. Los nodos antiguos habían negociado implícitamente un dialecto y comportamiento de firma distinto; los nuevos no coincidían con la política. Añadir vers=3.0,sign lo solucionó al instante.

El postmortem no dijo “lee dmesg”. Eso sería demasiado fácil. La conclusión fue que las políticas SMB son un contrato de tres partes: configuración del servidor, política de dominio y valores por defecto del cliente. Cuando actualizas una parte, renegocias el contrato, te guste o no.

2) Optimización que salió mal: “Desactivemos cifrado por rendimiento”

Otra compañía almacenaba artefactos de build sobre SMB porque “es básicamente una unidad de red”. Activaron cifrado SMB3 después de una auditoría de seguridad. El rendimiento bajó. Los desarrolladores se quejaron. Liderazgo oyó “builds lentos” y exigió acción.

El equipo de infra quitó seal de las opciones de montaje para acelerar. Funcionó en un entorno. En otro, el mismo cambio en fstab causó que los montajes fallaran con “permission denied”. No en todos: solo en algunos shares.

La razón fue sutil pero lógica: el cifrado estaba requerido por share en algunos servidores. Los que alojaban artefactos sensibles lo imponían. Quitar seal fue una violación de acceso, no un ajuste de rendimiento.

Al final hicieron lo aburrido pero correcto: mantener seal, medir la sobrecarga de CPU y mover los builders más cargados a instancias con más CPU. La optimización salió mal porque optimizaron la capa equivocada: la política, no el throughput.

3) Práctica aburrida pero correcta que salvó el día: “systemd automount + nofail + opciones fijadas”

Una organización de salud (sí, ese tipo de presión de uptime) tenía una regla: los montajes de red no deben bloquear el arranque. Cada montaje CIFS usaba systemd automount, nofail y vers/sec explícitos fijados a lo que el equipo de servidores soportaba.

Una mañana, una ventana de mantenimiento de controladores de dominio creó problemas Kerberos transitorios. Varios hosts perdieron la capacidad de montar shares protegidos por AD al arrancar. Pero los hosts sí arrancaron, los servicios se iniciaron y la pila de monitorización siguió viva. Los montajes se reintentaron al acceder y se recuperaron cuando Kerberos se estabilizó.

Aún hubo impacto: algunos trabajos no pudieron leer su entrada por un rato. Pero la infraestructura no cayó en un bucle de arranque ni se quedó en modo de emergencia. Esa diferencia importa. Mucho.

Lo mejor: las notas del incidente fueron cortas porque el comportamiento ya era esperado. “Los montajes son on-demand; revisa tickets; comprueba la disponibilidad del DC; espera; verifica el remonte.” Aburrido. Correcto. Salvavidas.

Errores comunes: síntoma → causa raíz → arreglo

Esta sección es deliberadamente específica. CIFS falla en patrones repetitivos. Reconoce el patrón, aplica el arreglo, sigue adelante.

1) Síntoma: mount error(13) inmediatamente, smbclient funciona

Causa raíz: desajuste de firma/cifrado, o el montaje está usando valores por defecto diferentes a smbclient.

Arreglo: fija opciones: vers=3.0,sec=ntlmssp,sign; añade seal si el servidor requiere cifrado. Verifica con mount | grep y dmesg.

2) Síntoma: montaje funciona con IP, falla con hostname

Causa raíz: desajuste DNS/SPN (especialmente con Kerberos), o estás alcanzando un servidor distinto detrás de un nombre.

Arreglo: usa DNS correcto, confirma con getent hosts. Para Kerberos, asegura que el SPN coincida con el hostname que montas.

3) Síntoma: funciona en un host Ubuntu, falla en otro con el mismo comando

Causa raíz: diferentes valores por defecto de kernel/cliente, caché de credenciales distinta (Kerberos), DNS diferente o política cripto distinta.

Arreglo: compara uname -r, dpkg -l cifs-utils y la salida de mount -vvv más dmesg. Haz vers y sec explícitos.

4) Síntoma: montaje tiene éxito, pero escrituras fallan con “Permiso denegado”

Causa raíz: ACL del share / ACL NTFS deniega escritura; o el share es de solo lectura; o montaste con ro.

Arreglo: confirma con una prueba de escritura con smbclient; revisa permisos en el servidor. No toques vers/sec; la autenticación ya está bien.

5) Síntoma: “Permiso denegado” solo cuando se ejecuta bajo systemd en el arranque

Causa raíz: red no lista, DNS no listo, ticket Kerberos no disponible, o el montaje se ejecuta antes de dependencias.

Arreglo: usa x-systemd.automount, nofail y considera _netdev. Para Kerberos, asegura que el ticket exista antes del acceso o usa una estrategia basada en keytab.

6) Síntoma: “Permiso denegado” después de rotación de contraseña, pero el archivo de credenciales parece correcto

Causa raíz: finales de línea CRLF, problemas de comillas o caracteres ocultos en la contraseña.

Arreglo: inspecciona con cat -A; convierte a LF; reescribe cuidadosamente; evita copiar mediante herramientas de texto enriquecido.

7) Síntoma: “mount error(13)” solo para algunos shares en el mismo servidor

Causa raíz: política por share (cifrado requerido, modelo ACL distinto) o permisos del share diferentes.

Arreglo: prueba cada share con smbclient //server/share. Añade seal para shares sensibles si es necesario.

Listas de comprobación / plan paso a paso (aburrido a propósito)

Usa esto cuando quieras que tu yo futuro te envíe una nota de agradecimiento.

Checklist 1: Configuración de host una vez (cliente CIFS Ubuntu 24.04)

Instala herramientas: cifs-utils, smbclient y herramientas Kerberos si se necesitan.
Crea un archivo de credenciales bajo /etc/cifs/ con permisos 0600 propiedad de root.
Crea el punto de montaje con la propiedad y permisos correctos para la cuenta de servicio consumidora.
Decide el modelo de autenticación: NTLMSSP vs Kerberos. No “pruebes ambos” en configuraciones de producción.
Fija vers y sec. Añade sign. Añade seal si es requerido o deseado.

Checklist 2: Entrada de fstab en producción que no arruinará tu arranque

Una línea fstab sensata para auth basada en contraseña:

cr0x@server:~$ sudo bash -lc "cat >> /etc/fstab <<'EOF'
//filesrv01.example.com/Finance  /mnt/finance  cifs  credentials=/etc/cifs/finance.cred,vers=3.0,sec=ntlmssp,sign,seal,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,nofail,_netdev,x-systemd.automount,x-systemd.idle-timeout=600  0  0
EOF"

Luego valida sin reiniciar:

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo mount -a

Decisión: Si mount -a falla, lee dmesg. No reinicies esperando que “se arregle”. Eso no es estrategia; es superstición con más pasos.

Checklist 3: Secuencia de respuesta a incidentes (15 minutos, disciplinado)

Comprueba conectividad al puerto 445 (nc -vz host 445).
Comprueba el mapeo DNS (getent hosts).
Valida credenciales con smbclient -L y acceso al share con smbclient //host/share.
Monta con vers y sec explícitos (comienza con vers=3.0,sec=ntlmssp o sec=krb5).
Añade sign; añade seal si los logs sugieren cifrado requerido.
Lee dmesg por mensajes CIFS después de cada intento.
Una vez montado, haz una prueba de escritura (touch) para distinguir auth vs ACL.

Datos interesantes y contexto (porque SMB arrastra equipaje)

SMB nació en IBM en los años 80 antes de que Microsoft lo popularizara. La edad del protocolo aparece hoy como raras “compatibilidades”.
“CIFS” es esencialmente la marca de la era SMB1. Linux sigue usando terminología “cifs” por razones históricas, incluso cuando montas SMB3.
Deshabilitar SMB1 ya es lo normal. Muchos servidores lo rechazan; los clientes que asumen retroceso a SMB1 encuentran errores confusos.
NTLM lleva años en la lista de “por favor dejen de usarlo”. Muchas empresas están eliminando NTLM a favor de Kerberos.
La firma SMB solía ser opcional y ahora a menudo es obligatoria. Esto invierte valores por defecto antiguos en entornos endurecidos.
SMB3 introdujo cifrado, que se negocia y puede requerirse por share. Por eso “algunos shares funcionan” es un síntoma real.
El comportamiento del cliente CIFS en Linux está dividido entre espacio de usuario y kernel. mount.cifs pasa opciones; el kernel hace la mayor parte del trabajo real y registra los errores auténticos.
Los fallos Kerberos a menudo parecen fallos de permiso porque el servidor no siempre distingue “plomería de tickets mala” de “sin acceso” en un mensaje amigable al cliente.
UID/GID en CIFS es mayormente una ilusión del cliente a menos que despliegues un mapeo de identidad completo y/o extensiones POSIX de manera consistente.

Preguntas frecuentes

1) ¿Por qué Ubuntu 24.04 muestra “Permiso denegado” pero Ubuntu 22.04 funcionó?

Porque cambiaste el comportamiento del cliente al actualizar: código CIFS del kernel más reciente, negociación por defecto distinta y expectativas de seguridad más estrictas. Fija vers y sec para dejar de depender de valores por defecto.

2) ¿Cuál es la mejor opción de “primera solución”?

vers=3.0. Elimina una gran clase de ambigüedad en la negociación. Combínalo con sec=ntlmssp para auth por contraseña o sec=krb5 para Kerberos AD.

3) ¿Debo usar `sec=ntlm` o `vers=1.0` para que funcione?

Sólo si tratas con infraestructura verdaderamente legacy y aceptas el riesgo de seguridad. Si lo necesitas temporalmente, aísla, documenta y planifica una salida. Trátalo como ejecutar telnet en producción: posible, pero no un estilo de vida.

4) ¿Cuál es la diferencia entre `sign` y `seal`?

sign aplica integridad (los mensajes no pueden ser manipulados sin detectarlo). seal habilita cifrado SMB (confidencialidad). Los servidores pueden requerir uno o ambos.

5) smbclient funciona, el montaje falla. ¿Cómo es posible?

smbclient y el montaje CIFS del kernel pueden negociar de forma ligeramente distinta y usar valores por defecto diferentes. Además, el montaje puede ser rechazado por requisitos de firma/cifrado que tu prueba con smbclient no activó de la misma manera. Usa los logs del kernel (dmesg) para ver por qué se rechaza el montaje.

6) ¿Dónde debo poner credenciales y cómo protegerlas?

Usa un archivo de credenciales como /etc/cifs/share.cred propiedad de root con permisos 0600. No incrustes contraseñas en /etc/fstab. No lo dejes legible por usuarios de servicio “para comodidad”.

7) Mi montaje funciona de forma interactiva pero falla al arrancar. ¿Cuál es la solución?

Usa nofail,_netdev,x-systemd.automount para que el sistema arranque independientemente del timing de la red, y el montaje ocurra al primer acceso. Para Kerberos, asegúrate de que los tickets estén disponibles en el contexto que accede, o usa un diseño basado en keytab.

8) ¿Debería usar `noperm`?

A veces. Puede resolver desajustes de comprobación de permisos local cuando el servidor es el verdadero aplicador. Pero también elimina una capa de protección local. Úsalo de forma intencionada, no por superstición.

9) ¿Por qué veo propiedades raras como todo propietario root o nobody?

Porque SMB no mapea inherentemente identidades Windows a UIDs/GIDs Linux sin mecanismos adicionales. Configura uid=, gid= y modos para comportamiento Linux predecible, o implementa mapeo de identidades si tu entorno lo requiere.

10) ¿Es buena idea montar CIFS dentro de contenedores?

No por defecto. Monta CIFS en el host y haz bind-mounts en los contenedores, salvo que comprendas completamente capacidades del kernel, manejo de credenciales y cómo tu orquestador trata montajes.

Conclusión: siguientes pasos que funcionan

Si Ubuntu 24.04 dice “Permiso denegado” en un montaje CIFS, asume que hay un desajuste entre lo que pides y lo que la política del servidor requiere. Luego pruébalo con la evidencia correcta.

Haz esto a continuación:

Ejecuta pruebas con smbclient para separar problemas de credenciales/ACL de problemas de negociación del montaje.
Fija vers=3.0 y el valor correcto de sec=. Añade sign. Añade seal si es requerido.
Lee dmesg tras cada intento fallido; trata el texto de error de mount como un resumen, no como diagnóstico.
Pon la configuración que funcione en /etc/fstab utilizando nofail y x-systemd.automount para que el próximo reinicio no sea tu próximo incidente.