Proxmox CIFS «Permiso denegado»: reparar credenciales, dialecto SMB y opciones de montaje

diciembre 24, 2025 • febrero 3, 2026 • Lectura: 10 min • Views: 8

¿Te fue útil?

Tienes el nombre de usuario correcto. Tienes la contraseña correcta. Probaste vers=3.0, vers=2.1, quizá incluso la opción nuclear. Y Proxmox aún dice: Permiso denegado.

Este es el momento en que CIFS/SMB enseña humildad. “Permiso denegado” puede significar “contraseña incorrecta”… o puede significar “tu NAS odia tu dialecto SMB”, “tu mapeo de UID es un desastre”, “el recurso permite solo lectura” o “te autenticaste bien pero fallaste en la autorización”. Mismo error. Escena del crimen distinta.

Guía de diagnóstico rápido

Si quieres el camino más corto desde “Permiso denegado” hasta un montaje funcional, haz esto en orden. No improvises. CIFS castiga la creatividad.

1) Confirma que el error es de autenticación, no de red o resolución de nombres

¿Puedes resolver el nombre del servidor desde el nodo Proxmox?
¿Puedes alcanzar TCP/445?
¿Puedes negociar algún dialecto SMB?

Si el DNS o el enrutamiento están mal, normalmente verás timeouts o errores de “No route”, no “Permiso denegado”. Normalmente.

2) Valida las credenciales con `smbclient` (no con la memoria)

Si smbclient no puede listar el recurso, el montaje tampoco lo hará. Si puede, has probado la autenticación y el acceso básico al recurso, y puedes centrarte en las opciones de montaje, el mapeo UID/GID y el uso que hace Proxmox.

3) Fuerza un dialecto SMB y un modo de seguridad explícitos

Establece vers=3.0 (o 3.1.1 si está soportado), y fija explícitamente sec=ntlmssp o sec=krb5 según tu entorno. Los desajustes de dialecto suelen mostrarse como fallos de autenticación porque el handshake nunca llega a la parte donde la contraseña importa.

4) Separa “el montaje funciona” de “Proxmox puede usarlo”

Puedes montar un recurso y aún fallar cuando Proxmox intenta crear directorios, bloquear archivos o establecer permisos. Los plugins de almacenamiento de Proxmox tienen expectativas (propiedad, acceso de escritura, modos de archivo consistentes). Prueba con el mismo usuario/contexto que Proxmox efectivamente usará.

5) Lee los registros del kernel

dmesg a menudo dirá qué rechazó CIFS, qué modo de seguridad se intentó y qué código de estado volvió. Los errores de la GUI de Proxmox son notoriamente minimalistas. El kernel no lo es.

Qué significa realmente “Permiso denegado” en CIFS

En Linux, CIFS está implementado por el módulo del kernel y gestionado por mount.cifs. Cuando algo falla, podrías ver:

mount error(13): Permission denied
CIFS: VFS: cifs_mount failed w/return code = -13

El error 13 es “EACCES”. Es un cubo que atrapa varios modos de fallo:

Credenciales incorrectas: nombre de usuario/contraseña equivocados, dominio incorrecto, contraseña caducada, cuenta bloqueada.
Mecanismo de autenticación incorrecto: el servidor requiere Kerberos y el cliente intenta NTLM; el servidor exige firmado y el cliente no puede; el servidor rechaza acceso de invitado.
Denegación a nivel de recurso: el usuario puede autenticarse pero no tiene permiso para acceder al recurso.
Denegación a nivel de sistema de archivos: el recurso es accesible, pero NTFS/ACL niega la creación de carpetas o escrituras.
Desajuste de protocolo: SMB1 deshabilitado; el cliente intenta SMB1; algunos sistemas responden con errores confusos relacionados con la autenticación.
Política de cifrado/firmado: el servidor lo impone y el cliente no cumple (o viceversa), y el fallo se presenta como acceso denegado.

Un consuelo seco: CIFS tiene exactamente un talento—hacer que problemas distintos parezcan idénticos.

Datos e historia que explican el dolor actual

SMB empezó en los años 80 en IBM y fue popularizado por Microsoft; es anterior a muchas de las pilas de almacenamiento “modernas” que ahora atormenta.
“CIFS” es básicamente SMB1 como lo marcó Microsoft en los 90. Los usuarios de Linux aún dicen “mount CIFS” incluso cuando negocian SMB3.
SMB1 está efectivamente muerto por razones de seguridad; muchos servidores lo deshabilitan por defecto. Los clientes que intentan SMB1 pueden obtener fallos engañosos.
SMB2 llegó con Windows Vista/Server 2008 y solucionó problemas de rendimiento (menos viajes de ida y vuelta, pipelining, mejor cache).
SMB3 (era Windows 8/Server 2012) introdujo cifrado, multichannel y mayor resiliencia—características que cambian cómo aparece “permiso denegado” bajo políticas estrictas.
NTLM es una solución de compatibilidad y una responsabilidad de seguridad; las empresas obligan cada vez más Kerberos o deshabilitan NTLM, lo que rompe scripts que “funcionaban el año pasado”.
La semántica de modos de archivo en Linux para CIFS es sintética: file_mode/dir_mode no reescriben ACLs del servidor; son una presentación en el cliente a menos que se usen extensiones Unix / mapeo POSIX.
Los atributos extendidos importan: mapear ACLs de Windows a permisos de Linux usa xattrs; desactivarlos puede convertir “funciona en Explorer” en “permiso denegado” en Linux.
El firmado SMB solía ser “opcional”; ahora a menudo es obligatorio en entornos endurecidos. Cuando hay desajuste, el error rara vez es amigable.

Contexto Proxmox: dónde viven los montajes CIFS y cómo los usa PVE

Proxmox VE (PVE) está basado en Debian. Cuando añades un almacenamiento CIFS en la GUI, Proxmox generalmente:

Almacena la configuración en /etc/pve/storage.cfg (sistema de archivos en clúster).
Monta el recurso bajo /mnt/pve/<storageid>.
Usa pvesm para activar el almacenamiento, y unidades de montaje de systemd pueden participar según la versión y cómo esté configurado.

Proxmox no es especial aquí. Es Linux. Pero Proxmox es dogmático respecto al comportamiento de almacenamiento:

Los trabajos de backup necesitan acceso de escritura fiable y semánticas de bloqueo de archivos estables.
Los almacenes de ISO/plantillas son mayormente de lectura pero aún requieren creación de directorios durante las subidas.
Algunas funciones se comportan mal en recursos SMB poco fiables (especialmente cuando el NAS tiene políticas “útiles” de opportunistic locking).

Regla: Primero haz que el montaje funcione en la CLI. Luego haz feliz a Proxmox. Si lo haces al revés, culparás a la GUI por un problema del kernel.

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

Cada tarea abajo tiene: un comando, una salida realista, lo que significa y qué decisión tomar a continuación. Ejecuta estas en el nodo Proxmox que está fallando.

Tarea 1: Confirma que el hostname se resuelve como piensas

cr0x@server:~$ getent hosts nas01
192.168.50.20   nas01.lab.local nas01

Significado: El nodo resuelve nas01 a 192.168.50.20. Si se resuelve a una IP antigua, “te autenticarás” contra el host equivocado y perderás horas.

Decisión: Si la resolución es incorrecta, arregla el DNS o usa la dirección IP en la definición de almacenamiento de Proxmox temporalmente para eliminar ambigüedad.

Tarea 2: Verifica que TCP/445 sea accesible (sin adivinanzas)

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

Significado: El camino de red y el firewall permiten SMB. Si esto falla, “Permiso denegado” puede ser un señuelo de un middlebox o una ruta de fallback.

Decisión: Si falla, para. Arregla enrutamiento/firewall/VLAN/ACLs antes de tocar credenciales.

Tarea 3: Ve qué dialectos SMB anuncia el servidor

cr0x@server:~$ smbclient -L //nas01 -m SMB3 -U 'LAB\backupuser'
Password for [LAB\backupuser]:
        Sharename       Type      Comment
        ---------       ----      -------
        backups         Disk      Proxmox Backups
        isos            Disk      ISO Library
        IPC$            IPC       IPC Service (NAS)
SMB1 disabled -- no workgroup available

Significado: Podemos autenticarnos y listar recursos usando SMB3. La línea “SMB1 disabled” es buena noticia.

Decisión: Si listar recursos falla con errores NT_STATUS, arregla autenticación/dominio/dialectos primero. No toques las opciones de montaje todavía.

Tarea 4: Prueba el acceso al recurso específico (lista un directorio)

cr0x@server:~$ smbclient //nas01/backups -m SMB3 -U 'LAB\backupuser' -c 'ls'
Password for [LAB\backupuser]:
  .                                   D        0  Wed Dec 25 10:21:11 2025
  ..                                  D        0  Wed Dec 25 10:21:11 2025
  pve01                               D        0  Tue Dec 24 18:02:44 2025

                52403200 blocks of size 1024. 39122432 blocks available

Significado: La autenticación y la autorización al nivel del recurso están bien. Si el montaje aún falla, sospecha de dialecto/seguridad, formato de credenciales o peculiaridades del CIFS del kernel.

Decisión: Si esto funciona pero el montaje falla, lee dmesg después de intentar montar y compara la negociación de seguridad/dialectos.

Tarea 5: Intenta un montaje manual con opciones explícitas y aburridas

cr0x@server:~$ sudo mkdir -p /mnt/test-backups
cr0x@server:~$ sudo mount -t cifs //nas01/backups /mnt/test-backups -o username=backupuser,domain=LAB,vers=3.0,sec=ntlmssp,iocharset=utf8,nounix,uid=0,gid=0,file_mode=0640,dir_mode=0750
cr0x@server:~$ mount | grep test-backups
//nas01/backups on /mnt/test-backups type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=backupuser,domain=LAB,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.50.20,file_mode=0640,dir_mode=0750,nounix,serverino,mapposix,acl,rsize=1048576,wsize=1048576,actimeo=1)

Significado: El montaje funciona. Eso ya te dice el mundo: el CIFS del kernel está bien, la red está bien, la autenticación está bien. Ahora el problema probablemente sea la configuración de Proxmox, el almacenamiento de credenciales o opciones distintas que se usan.

Decisión: Compara tus opciones exitosas con las opciones de Proxmox. Haz que Proxmox se comporte como tu montaje manual.

Tarea 6: Si el montaje falla, lee inmediatamente los registros del kernel

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Thu Dec 26 09:11:07 2025] CIFS: Attempting to mount //nas01/backups
[Thu Dec 26 09:11:07 2025] CIFS: VFS: \\nas01 Send error in SessSetup = -13
[Thu Dec 26 09:11:07 2025] CIFS: VFS: cifs_mount failed w/return code = -13

Significado: La configuración de la sesión falló, no la resolución de la ruta. Cuando es “SessSetup”, casi siempre son credenciales, dominio, modo de seguridad o política del servidor (firmado/restricciones NTLM).

Decisión: Fuerza vers y sec. Si usas AD, considera Kerberos (sec=krb5) y verifica la sincronización horaria.

Tarea 7: Inspecciona qué piensa Proxmox que es el almacenamiento

cr0x@server:~$ cat /etc/pve/storage.cfg
cifs: smb-backups
        path /mnt/pve/smb-backups
        server nas01
        share backups
        username backupuser
        domain LAB
        content backup
        options vers=3.0,sec=ntlmssp,iocharset=utf8,nounix

Significado: Proxmox guarda la definición aquí. Si options falta, Proxmox puede usar valores por defecto que no te gustarán.

Decisión: Añade opciones explícitas. Si la contraseña se guarda en otro sitio, asegúrate de que coincida y no esté truncada o mal escapada.

Tarea 8: Activa el almacenamiento y observa el error exacto

cr0x@server:~$ sudo pvesm status
Name         Type     Status           Total            Used       Available        %
local        dir      active       24545689600      7512332288     17033357312   30.60%
smb-backups  cifs     inactive              0               0               0    0.00%
cr0x@server:~$ sudo pvesm activate smb-backups
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Significado: Proxmox está fallando al montar incluso si tu prueba manual funcionó (o aún no la probaste).

Decisión: Si el montaje manual tiene éxito pero pvesm falla, Proxmox no está pasando las mismas opciones o usa un manejo distinto de credenciales. Captura el comando de montaje que se está ejecutando (ver tarea siguiente).

Tarea 9: Rastrea el intento de montaje (sí, con strace)

cr0x@server:~$ sudo strace -f -o /tmp/pvesm.strace pvesm activate smb-backups
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
cr0x@server:~$ tail -n 30 /tmp/pvesm.strace
execve("/usr/sbin/mount.cifs", ["mount.cifs", "//nas01/backups", "/mnt/pve/smb-backups", "-o", "username=backupuser,domain=LAB,vers=3.0,sec=ntlmssp"], 0x7ffd0a1c2c90 /* 18 vars */) = 0
...
write(2, "mount error(13): Permission de"..., 39) = 39

Significado: Proxmox está llamando a mount.cifs sin tu conjunto completo de opciones. Faltan nounix, iocharset, UID/GID, etc. A veces esas omisiones importan; otras veces solo cambian cómo se presentan los permisos tras el montaje.

Decisión: Pon las opciones faltantes en la definición de almacenamiento de Proxmox. No confíes en los valores por defecto entre actualizaciones del kernel.

Tarea 10: Usa un archivo de credenciales (y corrige sus permisos)

cr0x@server:~$ sudo install -d -m 0700 /root/.cifs
cr0x@server:~$ sudo bash -c 'cat > /root/.cifs/nas01-backups.cred <

Significado: Esto elimina problemas de escape del shell y evita filtrar secretos en la lista de procesos. Los permisos importan; archivos de credenciales demasiado abiertos pueden ser rechazados o simplemente un desastre.

Decisión: Prefiere un archivo de credenciales también para Proxmox (según tu modelo operativo). Como mínimo, deja de incrustar contraseñas en comandos ad-hoc.

Tarea 11: Verifica la deriva del reloj (Kerberos te castigará)

cr0x@server:~$ timedatectl
               Local time: Thu 2025-12-26 09:25:41 UTC
           Universal time: Thu 2025-12-26 09:25:41 UTC
                 RTC time: Thu 2025-12-26 09:25:41
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: La hora está sincronizada. Si usas sec=krb5 y el reloj está desincronizado, la autenticación puede fallar de forma que parezca “permiso denegado”.

Decisión: Si no está sincronizado, arregla NTP antes de depurar cualquier otra cosa en el mundo Kerberos.

Tarea 12: Inspecciona las expectativas de política del servidor (firmado/cifrado)

cr0x@server:~$ sudo modinfo cifs | head
filename:       /lib/modules/6.2.16-3-pve/kernel/fs/smb/client/cifs.ko
license:        GPL
description:    VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
author:         Steve French

Significado: Estás usando el cliente SMB en kernel. Los cambios de versión del kernel pueden cambiar valores por defecto alrededor del firmado y la selección de dialecto.

Decisión: Si un montaje “solía funcionar” y ahora falla tras actualizaciones, trátalo como un problema de cambio de valores por defecto. Fija opciones explícitas.

Tarea 13: Verifica que puedas escribir y crear directorios (Proxmox lo necesita)

cr0x@server:~$ sudo touch /mnt/test-backups/.pve-write-test
cr0x@server:~$ echo $?
0
cr0x@server:~$ sudo mkdir -p /mnt/test-backups/.pve-mkdir-test
cr0x@server:~$ ls -ld /mnt/test-backups/.pve-mkdir-test
drwxr-x--- 2 root root 0 Dec 26 09:27 /mnt/test-backups/.pve-mkdir-test

Significado: Las credenciales montadas pueden escribir y crear directorios. Si luego fallan las copias de seguridad de Proxmox, es menos probable que persigas fantasmas de ACL.

Decisión: Si obtienes “Permiso denegado” aquí, tu problema es de autorización (ACL del recurso / ACL del sistema de archivos), no de mecánica de montaje.

Tarea 14: Observa las opciones de montaje efectivas en la realidad

cr0x@server:~$ sudo findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/test-backups
//nas01/backups /mnt/test-backups cifs rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=backupuser,domain=LAB,uid=0,gid=0,file_mode=0640,dir_mode=0750,nounix,serverino,mapposix,acl

Significado: Esta es la verdad terreno de lo que aceptó el kernel. Si pones una opción y no aparece aquí, no se aplicó.

Decisión: Usa la salida de findmnt para guiar la configuración de Proxmox y documentar las expectativas operativas.

Tarea 15: Si el recurso está en Samba, confirma que el servidor ve tu usuario (validación servidor-side)

cr0x@server:~$ ssh admin@nas01 'sudo smbstatus -b | head'
Samba version 4.17.12
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
----------------------------------------------------------------------------------------------------------------------------------
24188   backupuser   domain users  192.168.50.11 (ipv4:192.168.50.11:54132)  SMB3_11           -                    partial

Significado: El servidor ve tu sesión. Si el servidor nunca la ve, la falla ocurre antes de que termine la autenticación (dialecto/seguridad, firewall, etc.).

Decisión: Si el servidor ve el inicio de sesión pero niega acceso a la ruta del recurso, arregla las definiciones del recurso y las ACLs del sistema de archivos.

Opciones de montaje que importan (y las que engañan)

Las opciones de montaje CIFS son donde las buenas intenciones van a ser auditadas. El truco es escoger un conjunto pequeño de opciones explícitas y tratarlas como un contrato API.

La base “hazlo explícito”

Para la mayoría de las configuraciones Proxmox→NAS que usan usuarios locales o AD con NTLMSSP, comienza aquí:

vers=3.0 (o 3.1.1 si sabes que ambos extremos lo soportan de forma consistente)
sec=ntlmssp (o sec=krb5 para entornos Kerberos)
iocharset=utf8
nounix (reduce a menudo rarezas de permisos/propiedad a menos que realmente uses extensiones Unix)
uid=0,gid=0 (o una cuenta de servicio en el host Proxmox si prefieres presentación como no-root)
file_mode=0640,dir_mode=0750 (capa de presentación; aún útil)

¿Por qué nounix tan a menudo? Porque las “extensiones Unix” de SMB y el mapeo POSIX pueden ser un campo minado de compatibilidad entre proveedores de NAS y versiones de Samba. Si tu NAS anuncia semánticas POSIX a medias, Linux lo creerá y entonces obtendrás comportamientos de permisos que te harán cuestionar tu carrera.

Selección de dialecto: `vers=` no es opcional en producción

Sí, el cliente puede negociar automáticamente. No, no debes confiar en eso para el almacenamiento de Proxmox.

Síntoma: “Permiso denegado” tras una actualización o cambio de política del NAS.
Causa raíz: cambio en la preferencia de dialecto por defecto, SMB1 deshabilitado, o cambio en la política de firmado SMB3.
Solución: fija vers=3.0 (o 3.1.1) y sigue con tu día.

Modo de seguridad: `sec=` es donde se oculta la política empresarial

Opciones comunes que verás:

sec=ntlmssp: ampliamente compatible, aún común, a menudo permitido pero a veces restringido.
sec=krb5: Kerberos, mejor opción en entornos AD si puedes gestionar keytabs y sincronización horaria.

Si tu organización desactiva NTLM, montajes que funcionaron durante años empezarán a fallar con “Permiso denegado”. La contraseña no cambió. La política sí.

Firmado y cifrado: desajustes de política pueden parecer fallos de autenticación

Dependiendo del kernel y del servidor, podrías necesitar opciones como:

seal (cifrado SMB)
sign (firmado habilitado) o aplicación por parte del servidor

Estas no siempre son necesarias. Con frecuencia son requeridas por política cuando el recurso contiene copias de seguridad sensibles.

Mapeo UID/GID: los montajes pueden tener éxito y aun así ser “permiso denegado” después

Esta es la trampa clásica: el montaje se realiza, pero cuando Proxmox intenta escribir, ves errores de permiso en trabajos de backup.

SMB no es naturalmente “ser Linux”. La propiedad y los modos se mapean. Si el servidor expone ACLs que no se traducen bien, el cliente muestra permisos que no reflejan la realidad. O viceversa.

Guía opinada:

Si usas un NAS como destino tonto de backups, prefiere nounix y gestiona permisos a nivel de share/ACL.
Si realmente necesitas semántica POSIX (home directories compartidos, flujos multiusuario), usa Samba con extensiones Unix configuradas correctamente y prueba a fondo. No asumas que tu proveedor de NAS lo hizo bien.

Un chiste corto (1 de 2)

“Permission denied” de SMB es como una invitación de calendario corporativa: no te dice qué está mal, solo que tu tarde se ha ido.

Credenciales vs autorización: ACLs del recurso, ACLs NTFS y rarezas del NAS

“Credenciales correctas” no es lo mismo que “tienes permiso para hacer la acción”. SMB hace una separación clara:

Autenticación: demostrar quién eres (contraseña/Kerberos/NTLM).
Autorización: determinar qué puedes acceder (permisos del recurso + permisos/ACL del sistema de archivos).

Permisos del recurso vs permisos del sistema de archivos

Muchos sistemas NAS implementan dos capas:

Acceso a nivel de recurso: quién puede conectarse a //server/share.
ACL a nivel de sistema de archivos: qué puedes hacer dentro (crear, borrar, renombrar).

Puedes pasar la capa uno y fallar en la capa dos. El cliente aún puede reportar “permiso denegado”, y jurarás que la contraseña es incorrecta porque es la única palanca que has estado usando.

Formato del dominio: `DOMAIN\user` vs `user@domain`

Las pilas SMB difieren. A algunos les gusta LAB\backupuser. Otros prefieren backupuser@lab.local. Linux mount.cifs típicamente quiere username= y domain= (o incrustar el dominio en el username).

Regla práctica: usa el mismo formato que funcionó con smbclient, luego tradúcelo a las opciones de montaje.

Acceso de invitado y comportamiento “map to guest”

Algunas configuraciones de Samba/NAS permiten acceso de invitado, otras lo prohíben explícitamente. Si tu cliente intenta por accidente autenticación de invitado o anónima (usuario vacío, mapeo de dominio equivocado), puedes obtener:

conexión exitosa pero acceso de solo lectura, o
permiso denegado inmediato.

Fija las credenciales explícitamente. Evita pensar “usará mi usuario logueado” en un nodo Proxmox.

Kerberos en entornos Proxmox

Si montas desde un host Linux unido al dominio con un keytab, Kerberos es una buena opción. Pero es operativamente estricto:

La sincronización horaria debe ser correcta.
El DNS debe ser correcto.
Los SPN deben existir y coincidir con el nombre del servidor que usas.

Las fallas de Kerberos pueden degradarse a mensajes de acceso denegado. Si usas sec=krb5, comprométete con los prerrequisitos.

Tres micro-historias corporativas (porque vivirás esto)

Micro-historia 1: El incidente causado por una suposición errónea

El equipo tenía un clúster Proxmox haciendo backups a un NAS central por SMB. El almacenamiento se añadió en la GUI, se montó y las copias de seguridad funcionaron durante meses. Todos se acomodaron.

Luego el equipo de seguridad desplegó una política de AD para deshabilitar NTLM en fases. Mandaron un correo. Cayó donde caen los correos de política: el mismo lugar que “formación obligatoria” y “diversión de equipo virtual”.

Una mañana de martes, las copias de seguridad empezaron a fallar con mount error(13): Permission denied. El ingeniero on-call hizo el baile esperado: resetear la contraseña, reescribirla, probar otra cuenta. Mismo fallo. Se culpó a Proxmox. Se culpó al NAS. Se culpó a la red. Se culpó al tiempo, brevemente, porque el tiempo siempre es sospechoso en sistemas distribuidos.

Resultó que las credenciales eran correctas. La autenticación estaba siendo rechazada porque NTLM ya no estaba permitido para esa clase de cuenta. El montaje necesitaba Kerberos: sec=krb5, un keytab y DNS estable.

La suposición equivocada no fue “la contraseña está mal”. Fue asumir que “las políticas de autenticación no cambian debajo de sistemas que funcionan”. Cambian. En silencio. Programadas.

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

Un ingeniero de almacenamiento quería backups más rápidos. Razonable. Ajustó opciones de montaje para throughput, incluyendo cache agresiva y tamaños de lectura/escritura mayores. Las copias mejoraron en pruebas pequeñas.

Luego llegó el día de restaurar. Una restauración de VM falló intermitentemente con síntomas de corrupción: bloques faltantes, desajustes de checksum a nivel de aplicación y comportamiento tipo “stale file handle”. El recurso SMB no estaba perdiendo datos; el comportamiento del cliente devolvía lecturas inconsistentes durante una carga concurrente de escrituras.

La “optimización” fue un cóctel de opciones que tenían sentido en aislamiento pero no juntas para una carga de backup que espera consistencia fuerte. El equipo había convertido su destino de backup en una caché entusiasta con opiniones.

Revirtieron a semánticas de cache más estrictas y opciones más simples. El rendimiento bajó. La fiabilidad volvió. La lección fue dolorosa y predecible: para backups, la consistencia vence a la astucia. Siempre.

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

En otra empresa, el equipo SRE tenía una política: cada montaje de sistema de archivos remoto debe ser reproducible con un único comando CLI documentado, y cada montaje debe fijar un dialecto SMB y modo de seguridad explícitos. Era un poco molesto. La gente se quejaba. La política se mantuvo.

Durante un ciclo de actualización de Proxmox, un subconjunto de nodos empezó a fallar en montajes CIFS. El error de la GUI era, como se esperaba, “Permiso denegado”. La diferencia fue que el equipo ya tenía comandos “conocidos como buenos” y salidas de findmnt capturadas antes de la actualización.

Compararon las opciones usadas antes/después del cambio y encontraron que un nodo había derivado: dependía de valores por defecto y negoció un dialecto distinto debido a un ajuste de política del lado NAS. Arreglaron la configuración del almacenamiento fijando vers=3.0 y el modo de seguridad explícitamente, luego volvieron a ejecutar la prueba CLI documentada. Listo.

Práctica aburrida. Recuperación rápida. Todos volvieron a fingir que disfrutan las ventanas de cambio.

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

Esta sección es directa porque la producción es directa.

1) Síntoma: “Permiso denegado” pero `smbclient -L` funciona

Causa raíz: el montaje usa distinto dialecto/seguridad que smbclient, o Proxmox pasa menos opciones que tu prueba.
Solución: fuerza vers=3.0 y sec=ntlmssp (o krb5) en options del almacenamiento de Proxmox. Verifica con strace y findmnt.

2) Síntoma: montaje manual funciona como root, pero los backups de Proxmox fallan por errores de permiso

Causa raíz: autorización dentro del recurso: ACL del sistema de archivos niega crear/escribir/renombrar en la ruta que Proxmox usa, o el NAS impone “solo admin” para ciertas operaciones.
Solución: prueba escribir/crear/borrar en la ruta montada; arregla ACL del recurso y ACL subyacentes del sistema de archivos. No lo tapes con file_mode solamente.

3) Síntoma: funcionó ayer; hoy “Permiso denegado” tras actualizaciones

Causa raíz: cambió un valor por defecto o la negociación de dialecto; el servidor deshabilitó SMB2/SMB1 fallback; la política NTLM se endureció.
Solución: fija vers y sec. Si NTLM fue deshabilitado, migra a Kerberos o re-habilita NTLM (si tu equipo de seguridad lo permite, lo cual es otro tipo de incidente).

4) Síntoma: “Permiso denegado” solo al usar un hostname, pero la IP funciona

Causa raíz: SPN / DNS / política basada en nombre (Kerberos espera el hostname), o estás resolviendo al host equivocado.
Solución: arregla DNS, verifica con getent hosts, y para Kerberos usa el hostname canónico que coincida con el SPN del servidor.

5) Síntoma: la adición de almacenamiento en la GUI de Proxmox falla, pero el montaje por CLI funciona

Causa raíz: configuración de almacenamiento de Proxmox carece de opciones requeridas, o almacena credenciales de forma distinta que tu prueba CLI.
Solución: añade el almacenamiento vía CLI o edita /etc/pve/storage.cfg cuidadosamente; verifica con pvesm activate y strace para ver la llamada exacta de montaje.

6) Síntoma: puedes leer pero no escribir

Causa raíz: el recurso es de solo lectura para ese usuario, o la ACL subyacente niega escribir/crear/borrar.
Solución: usa smbclient para intentar una escritura, y prueba en el montaje con touch/mkdir. Corrige permisos del lado servidor, no cosméticos del lado cliente.

7) Síntoma: “Permiso denegado” cuando la contraseña tiene caracteres especiales

Causa raíz: escape del shell o parseo en la configuración de Proxmox te traicionó; la contraseña no es la que crees.
Solución: usa un archivo de credenciales con permisos estrictos. Deja de pegar secretos en comandos.

8) Síntoma: problemas de permisos intermitentes bajo carga

Causa raíz: comportamiento de locking/oplocks/leases, bugs del NAS, o opciones de cache que no coinciden con las necesidades de consistencia de la carga.
Solución: revierte a opciones conservadoras; asegúrate de que el NAS esté soportado para escrituras concurrentes pesadas; considera NFS para cargas Linux-centradas si tu entorno lo permite.

Listas de verificación / plan paso a paso

Lista A: Obtener un montaje fiable en el nodo Proxmox (CLI primero)

Resuelve el nombre del servidor: getent hosts nas01. Si está mal, arregla DNS o usa IP temporalmente.
Verifica alcance: nc -vz nas01 445. Si está bloqueado, arregla la red/firewall.
Confirma credenciales y visibilidad del recurso: smbclient -L //nas01 -m SMB3 -U 'LAB\backupuser'.
Confirma que puedes acceder al recurso: smbclient //nas01/backups -m SMB3 -U 'LAB\backupuser' -c 'ls'.
Crea un archivo de credenciales con permisos 0600.
Monta con opciones fijadas (vers, sec, nounix, iocharset, UID/GID y modos).
Prueba escribir/crear/borrar en la ruta montada.
Captura la salida de findmnt como tu referencia “conocida buena”.

Lista B: Hacer que Proxmox use el mismo comportamiento de montaje

Inspecciona /etc/pve/storage.cfg para la entrada CIFS.
Establece options explícitas para que coincidan con el montaje CLI exitoso: dialecto, modo de seguridad y flags de compatibilidad.
Ejecuta pvesm activate <storageid>.
Si falla, ejecuta dmesg -T | tail -n 50 inmediatamente después.
Usa strace sobre pvesm activate para confirmar qué opciones se pasan a mount.cifs.
Verifica que el montaje esté presente bajo /mnt/pve/<storageid> con findmnt.
Dispara una pequeña copia de seguridad de Proxmox para validar el comportamiento real de la carga (escritura + patrones de rename).

Lista C: Pista Kerberos (cuando NTLM no está permitido)

Confirma sincronización horaria: timedatectl muestra sincronización.
Confirma DNS correcto para el nombre del servidor SMB.
Obtén e instala un keytab para el principal de servicio (operativamente: coordinar con servicios de directorio).
Monta con sec=krb5 y usa el nombre de servidor correcto (el que coincida con el SPN).
Valida con los registros del kernel si la autenticación falla; las fallas de Kerberos pueden aparecer como problemas de acceso.

Idea parafraseada (cita sobre fiabilidad): El principio bien conocido de Gene Kranz en control de misión es esencialmente “sé estricto y competente”. Esa mentalidad aplica perfectamente a los montajes de almacenamiento.

Un chiste corto (2 de 2)

Nada dice “almacenamiento empresarial” como un protocolo llamado “Simple” que necesita 14 opciones para hacer un montaje básico.

Preguntas frecuentes

1) ¿Por qué Proxmox dice “Permiso denegado” cuando las credenciales son correctas?

Porque el error frecuentemente refleja autorización (ACL del recurso/ACL NTFS), políticas (NTLM deshabilitado, firmado requerido) o fallos en la negociación de dialecto/seguridad, no solo la validez de la contraseña.

2) ¿Debo siempre establecer `vers=3.0`?

En producción, sí—fija un dialecto explícito que sepas que el servidor soporta. Si tienes un NAS/Windows/Samba moderno, SMB3 es la línea base correcta. Si el servidor soporta SMB3.1.1 de forma fiable, puedes usar eso, pero la consistencia importa más que mejoras teóricas.

3) ¿Cuál es la diferencia entre `sec=ntlmssp` y `sec=krb5`?

ntlmssp usa autenticación basada en NTLM y es muy compatible. krb5 usa Kerberos y típicamente es preferible en entornos AD con control de políticas más estricto, pero requiere sincronización horaria y configuración correcta de DNS/SPN.

4) Puedo listar el recurso pero no puedo crear archivos. ¿Por qué?

El acceso a nivel de recurso te permite conectarte, pero las ACLs del sistema de archivos aún pueden bloquear escrituras. Prueba con touch en el montaje y arregla ACL del servidor. file_mode del cliente no anulará la autorización del servidor.

5) ¿`file_mode` y `dir_mode` arreglan los permisos?

Mayormente afectan cómo se presentan los permisos en el cliente Linux. No otorgan mágicamente derechos de escritura si el servidor los niega.

6) ¿Por qué ayuda usar un archivo de credenciales?

Evita problemas de escape del shell, previene que secretos aparezcan en las listas de procesos y mantiene el comando de montaje limpio. También dificulta pegar la contraseña equivocada con caracteres invisibles.

7) Proxmox monta bajo `/mnt/pve`. ¿Puedo montar en otro sitio?

Proxmox espera gestionar almacenamientos bajo /mnt/pve/<storageid>. Puedes montar manualmente en otro lugar para pruebas, pero la definición de almacenamiento debería alinearse con las convenciones de Proxmox a menos que tengas una razón sólida para desviarte.

8) ¿Es CIFS una buena opción para backups de Proxmox?

Puede serlo. Pero trátalo como una dependencia de red con cambios de política y rarezas del firmware del NAS. Si controlas ambos extremos y tu entorno es mayormente Linux, NFS suele tener menos sorpresas en la traducción de identidad/ACL. Si estás en entorno Windows/AD, SMB con Kerberos es una ruta empresarial sólida.

9) ¿Cuál es la señal de troubleshooting más valiosa?

dmesg inmediatamente después del fallo. A menudo te dice si la falla ocurrió durante session setup, tree connect o comprobaciones de autorización posteriores.

Conclusión: pasos prácticos siguientes

Cuando Proxmox CIFS dice “Permiso denegado”, deja de debatir si la contraseña es correcta y empieza a recopilar evidencia. Prueba la conectividad de red, verifica el acceso al recurso con smbclient, fija el dialecto SMB y el modo de seguridad, y luego haz que Proxmox use exactamente las mismas opciones de montaje que funcionaron en la CLI.

Pasos siguientes que realmente avanzan:

Ejecuta smbclient contra el recurso y usuario exactos que piensas montar.
Haz un montaje manual con vers y sec explícitos, luego verifica con findmnt.
Prueba operaciones de escritura/creación en la ruta montada—no asumas.
Haz que Proxmox coincida con tu conjunto de opciones conocido-bueno y valida con pvesm activate más dmesg.
Documenta el conjunto final de opciones de montaje. Los valores por defecto cambian. Tu yo futuro no recordará por qué esto funcionó.