Proxmox CIFS « Permission denied » : corriger les identifiants, le dialecte SMB et les options de montage

décembre 24, 2025 • février 3, 2026 • Lecture : 11 min • Views: 8

Cet article vous a aidé ?

Vous avez le bon nom d’utilisateur. Vous avez le bon mot de passe. Vous avez essayé vers=3.0, vers=2.1, peut-être même l’option nucléaire. Et Proxmox affiche toujours : Permission denied.

C’est le moment où CIFS enseigne l’humilité. « Permission denied » peut signifier « mauvais mot de passe »… ou « votre NAS déteste votre dialecte SMB », « votre mappage UID est absurdité », « le partage est en lecture seule », ou « vous vous êtes authentifié mais l’autorisation a échoué ». Même erreur. Scène de crime différente.

Méthode de diagnostic rapide

Si vous voulez le chemin le plus court de « Permission denied » à un montage fonctionnel, faites ceci dans l’ordre. N’improvisez pas. CIFS punit la créativité.

1) Confirmez que l’erreur est d’authentification, pas réseau ou résolution de noms

Pouvez-vous résoudre le nom du serveur depuis le nœud Proxmox ?
Pouvez-vous atteindre le TCP/445 ?
Pouvez-vous négocier un dialecte SMB du tout ?

Si le DNS ou le routage est erroné, vous verrez généralement des timeouts ou des erreurs « No route », pas « Permission denied ». En général.

2) Validez les identifiants avec `smbclient` (pas avec votre mémoire)

Si smbclient ne peut pas lister le partage, le montage non plus. S’il peut, vous avez prouvé l’authentification et l’accès basique au partage, et vous pouvez vous concentrer sur les options de montage, le mappage UID/GID et l’usage par Proxmox.

3) Forcez un dialecte SMB explicite et un mode de sécurité

Définissez vers=3.0 (ou 3.1.1 si pris en charge), et définissez explicitement sec=ntlmssp ou sec=krb5 selon votre environnement. Les incompatibilités de dialecte se manifestent souvent comme des échecs d’authentification parce que la poignée de main ne va jamais jusqu’à la partie où votre mot de passe compte.

4) Séparez « le montage fonctionne » de « Proxmox peut l’utiliser »

Vous pouvez monter un partage et quand même échouer lorsque Proxmox tente de créer des répertoires, verrouiller des fichiers ou définir des permissions. Les plugins de stockage Proxmox ont des attentes (propriété, accès en écriture, modes de fichier cohérents). Testez avec le même utilisateur/contexte que Proxmox utilisera effectivement.

5) Lisez les logs du noyau

dmesg indiquera souvent ce que CIFS a refusé, quel mode de sécurité a été tenté et quel code d’état est revenu. Les erreurs GUI de Proxmox sont fameusement minimalistes. Le noyau ne l’est pas.

Ce que « Permission denied » signifie réellement en CIFS

Sur Linux, CIFS est implémenté par le module noyau et piloté par mount.cifs. Quand quelque chose échoue, vous pouvez voir :

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

L’erreur 13 est « EACCES ». C’est un seau qui attrape plusieurs modes d’échec :

Mauvaises identifiants : mauvais nom d’utilisateur/mot de passe, mauvais domaine, mot de passe expiré, compte verrouillé.
Mauvais mécanisme d’auth : le serveur exige Kerberos, le client tente NTLM ; le serveur exige le signing, le client ne peut pas ; le serveur rejette l’accès invité.
Refus au niveau du partage : l’utilisateur peut s’authentifier mais n’est pas autorisé à accéder au partage.
Refus au niveau du système de fichiers : le partage est accessible, mais NTFS/ACL refuse la création de dossiers ou les écritures.
Incompatibilité de protocole : SMB1 désactivé ; le client tente SMB1 ; certains systèmes répondent par des erreurs d’authentification déroutantes.
Incompatibilité politique chiffrement/signing : le serveur l’exige, le client ne s’y conforme pas (ou inversement), et l’échec se manifeste comme un accès refusé.

Un petit réconfort sec : CIFS a exactement un talent — faire paraître différents problèmes identiques.

Faits et histoire intéressants expliquant la douleur d’aujourd’hui

SMB a commencé dans les années 1980 chez IBM et a été popularisé par Microsoft ; il est plus ancien que beaucoup des piles de stockage « modernes » qu’il hante désormais.
« CIFS » est essentiellement SMB1 tel que promu par Microsoft dans les années 1990. Les gens Linux disent encore « mount CIFS » même lorsqu’ils négocient SMB3.
SMB1 est pratiquement mort pour des raisons de sécurité ; de nombreux serveurs le désactivent par défaut. Les clients essayant SMB1 peuvent recevoir des échecs trompeurs.
SMB2 est arrivé avec Windows Vista/Server 2008 et a corrigé de gros problèmes de performance (moins d’allers-retours, pipelining, meilleur caching).
SMB3 (ère Windows 8/Server 2012) a introduit le chiffrement, multichannel et une meilleure résilience — des fonctionnalités qui changent la façon dont « permission denied » apparaît sous des politiques strictes.
NTLM est un cheval de bataille de compatibilité et un risque de sécurité ; les entreprises forcent de plus en plus Kerberos ou désactivent NTLM, ce qui casse des scripts « ça marchait l’an dernier ».
Les sémantiques de mode de fichier CIFS sous Linux sont synthétiques : file_mode/dir_mode ne réécrivent pas les ACLs du serveur ; ce sont des présentations côté client sauf si les extensions Unix / le mapping POSIX sont utilisés.
Les attributs étendus comptent : le mappage des ACLs Windows vers permissions Linux utilise les xattrs ; les désactiver peut transformer « ça marche dans l’Explorateur » en « permission denied » sur Linux.
Le signing SMB était autrefois un « peut-être » ; maintenant il est souvent obligatoire dans les environnements durcis. Lorsqu’il est mismatched, l’erreur est rarement conviviale.

Contexte Proxmox : où vivent les montages CIFS et comment PVE les utilise

Proxmox VE (PVE) est basé sur Debian. Quand vous ajoutez un stockage CIFS dans l’interface, Proxmox :

Stocke la config dans /etc/pve/storage.cfg (système de fichiers de cluster).
Monte le partage sous /mnt/pve/<storageid>.
Utilise pvesm pour activer le stockage, et des unités systemd de montage peuvent être impliquées selon la version et la configuration.

Proxmox n’est pas spécial ici. C’est Linux. Mais Proxmox est prescriptif sur le comportement du stockage :

Les tâches de sauvegarde ont besoin d’un accès en écriture fiable et de la sémantique de verrouillage de fichier stable.
Les stores ISO/modèles sont majoritairement en lecture, mais nécessitent quand même la création de répertoires lors des uploads.
Certaines fonctionnalités se comportent mal sur des partages SMB instables (surtout quand le NAS a des politiques d’oplocks « utiles »).

Règle : Faites d’abord fonctionner le montage en CLI. Ensuite, faites en sorte que Proxmox soit content. Si vous procédez dans l’ordre inverse, vous accuserez l’interface graphique d’un problème du noyau.

Tâches pratiques : commandes, sorties et décisions (12+)

Chaque tâche ci-dessous contient : une commande, une sortie réaliste, ce que cela signifie et la décision à prendre ensuite. Exécutez-les sur le nœud Proxmox qui échoue.

Task 1: Confirm the hostname resolves the way you think

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

Sens : Le nœud résout nas01 en 192.168.50.20. S’il résout vers une ancienne IP, vous vous authentifierez contre le mauvais hôte et perdrez des heures.

Décision : Si la résolution est erronée, corrigez le DNS ou utilisez l’adresse IP dans la définition du stockage Proxmox temporairement pour éliminer l’ambiguïté.

Task 2: Verify TCP/445 is reachable (no guessing)

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

Sens : Le chemin réseau et le pare-feu autorisent SMB. Si ceci échoue, « Permission denied » pourrait être une fausse piste à cause d’un middlebox ou d’un chemin de repli.

Décision : Si cela échoue, arrêtez. Corrigez le routage/pare-feu/VLAN/ACLs avant de toucher aux identifiants.

Task 3: See what SMB dialects the server advertises

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

Sens : Nous pouvons nous authentifier et lister les partages en SMB3. La ligne « SMB1 disabled » est une bonne nouvelle.

Décision : Si la liste des partages échoue avec des erreurs NT_STATUS, corrigez l’auth/domain/dialect d’abord. Ne touchez pas encore aux options de montage.

Task 4: Test access to the specific share (list a directory)

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

Sens : L’authentification et l’autorisation au niveau du partage sont correctes. Si le montage échoue encore, suspectez les options de dialecte/sécurité, le formatage des identifiants ou les bizarreries du CIFS noyau.

Décision : Si ceci fonctionne mais que le montage échoue, lisez dmesg après une tentative de montage et comparez la négociation de sécurité/dialect.

Task 5: Try a manual mount with explicit, boring options

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)

Sens : Le montage fonctionne. Cela vous indique déjà beaucoup : le CIFS noyau est OK, le réseau est OK, l’auth est OK. Maintenant le problème vient probablement de la config Proxmox, du stockage des identifiants, ou d’options différentes utilisées.

Décision : Différenciez vos options réussies par rapport à celles de Proxmox. Faites en sorte que Proxmox se comporte comme votre montage manuel.

Task 6: If the mount fails, immediately read kernel logs

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

Sens : La configuration de la session d’authentification a échoué, pas la résolution du chemin. Quand c’est « SessSetup », c’est presque toujours les identifiants, le domaine, le mode de sécurité, ou la politique serveur (signing/restrictions NTLM).

Décision : Forcez vers et sec. Si vous utilisez AD, envisagez Kerberos (sec=krb5) et vérifiez la synchronisation temporelle.

Task 7: Inspect what Proxmox thinks the storage is

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

Sens : Proxmox stocke la définition ici. Si options manque, Proxmox peut utiliser des valeurs par défaut que vous n’aimerez pas.

Décision : Ajoutez des options explicites. Si un mot de passe est stocké ailleurs, assurez-vous qu’il correspond et n’est pas tronqué ou mal échappé.

Task 8: Activate the storage and watch the exact error

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)

Sens : Proxmox échoue à monter même si votre test manuel a fonctionné (ou si vous n’avez pas encore testé manuellement).

Décision : Si le montage manuel réussit mais que pvesm échoue, Proxmox ne passe pas les mêmes options ou utilise un traitement d’identifiants différent. Capturez la commande de montage exécutée (voir tâche suivante).

Task 9: Trace the mount attempt (yes, with 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

Sens : Proxmox appelle mount.cifs sans votre jeu complet d’options. L’absence de nounix, iocharset, UID/GID, etc. Parfois ces omissions importent ; parfois elles changent juste la façon dont les permissions sont présentées après montage.

Décision : Mettez les options manquantes dans la définition de stockage Proxmox. Ne comptez pas sur les valeurs par défaut lors des mises à jour du noyau.

Task 10: Use a credentials file (and fix its permissions)

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

Sens : Cela évite les problèmes d’échappement shell et évite de divulguer des secrets dans la liste des processus. Les permissions comptent ; un fichier d’identifiants trop ouvert peut être rejeté ou simplement causer des ennuis.

Décision : Préférez un fichier d’identifiants pour Proxmox aussi (selon votre modèle opérationnel). Au minimum, arrêtez d’insérer des mots de passe dans des commandes ad hoc.

Task 11: Check clock skew (Kerberos environments will punish you)

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

Sens : L’heure est synchronisée. Si vous utilisez sec=krb5 et que l’horloge est décalée, l’auth peut échouer de façons ressemblant à « permission denied ».

Décision : Si non synchronisée, corrigez NTP avant de déboguer quoi que ce soit en Kerberos.

Task 12: Inspect server-side policy expectations (signing/encryption)

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

Sens : Vous utilisez le client SMB intégré au noyau. Les changements de version du noyau peuvent changer les valeurs par défaut autour du signing et de la sélection de dialecte.

Décision : Si un montage « marchait avant » et échoue après des mises à jour, traitez-le comme un problème de changements de valeurs par défaut. Épinglez des options explicites.

Task 13: Verify you can write and create directories (Proxmox needs this)

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

Sens : Les identifiants montés peuvent écrire et créer des répertoires. Si les sauvegardes Proxmox échouent ensuite, vous perdrez moins de temps à chasser des fantômes ACL.

Décision : Si vous obtenez « Permission denied » ici, votre problème est d’autorisation (ACL de partage / ACL système de fichiers), pas mécanique du montage.

Task 14: Observe the effective mount options in reality

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

Sens : C’est la vérité terrain de ce que le noyau a accepté. Si vous définissez une option et qu’elle n’apparaît pas ici, elle n’a pas été prise en compte.

Décision : Utilisez la sortie de findmnt pour guider la configuration Proxmox et documenter les attentes opérationnelles.

Task 15: If the share is on Samba, confirm server sees your user (server-side validation)

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

Sens : Le serveur voit votre session. Si le serveur ne la voit jamais, l’échec se produit avant la fin de l’authentification (dialect/sécurité, pare-feu, etc.).

Décision : Si le serveur voit la connexion mais refuse l’accès au chemin du partage, corrigez les définitions de partage et les ACL du système de fichiers.

Options de montage importantes (et celles qui vous trompent)

Les options de montage CIFS sont l’endroit où les bonnes intentions se font auditer. L’astuce est de choisir un petit ensemble d’options explicites et de les traiter comme un contrat d’API.

The “make it explicit” baseline

Pour la plupart des configurations Proxmox-vers-NAS utilisant des utilisateurs locaux ou AD avec NTLMSSP, commencez ici :

vers=3.0 (ou 3.1.1 si vous savez que les deux côtés le supportent de manière cohérente)
sec=ntlmssp (ou sec=krb5 pour les environnements Kerberos)
iocharset=utf8
nounix (réduit souvent les bizarreries de permission/propriété sauf si vous utilisez vraiment les extensions Unix)
uid=0,gid=0 (ou un compte de service sur l’hôte Proxmox si vous voulez une présentation en dehors de root)
file_mode=0640,dir_mode=0750 (couche de présentation ; toujours utile)

Pourquoi nounix si souvent ? Parce que les « extensions Unix » SMB et le mapping POSIX peuvent être un champ de mines de compatibilité entre fournisseurs de NAS et versions de Samba. Si votre NAS annonce des sémantiques POSIX à moitié finies, Linux y croira et vous obtiendrez un comportement de permissions qui vous fera remettre en question votre carrière.

Dialect selection: `vers=` is not optional in production

Oui, le client peut négocier automatiquement. Non, vous ne devriez pas compter dessus pour un stockage Proxmox.

Symptôme : « Permission denied » après une mise à jour ou après avoir changé une politique de sécurité NAS.
Cause racine : la préférence de dialecte par défaut a changé, le fallback SMB1 est désactivé, ou la politique de signing SMB3 a été modifiée.
Correction : épinglez vers=3.0 (ou 3.1.1) et passez à autre chose.

Security mode: `sec=` is where enterprise policy hides

Options communes :

sec=ntlmssp : très compatible, encore courant, souvent autorisé mais parfois restreint.
sec=krb5 : Kerberos, meilleur choix en environnements AD si vous pouvez gérer les keytabs et la synchronisation temporelle.

Si votre organisation désactive NTLM, des montages qui marchaient pendant des années commenceront à échouer avec « Permission denied ». Le mot de passe n’a pas changé. La politique a changé.

Signing and encryption: policy mismatch can look like auth failure

Selon le noyau et le serveur, vous pourriez avoir besoin d’options comme :

seal (chiffrement SMB)
sign (signing activé) ou enforcement côté serveur

Ce ne sont pas toujours nécessaires. Ils sont fréquemment exigés par la politique quand le partage contient des sauvegardes sensibles.

UID/GID mapping: mounts can succeed and still be “permission denied” later

C’est le piège classique : le montage réussit, mais quand Proxmox essaie d’écrire, vous voyez des erreurs de permission dans les tâches de sauvegarde.

SMB n’est pas naturellement « Linux ». La propriété et les modes sont mappés. Si le serveur expose des ACLs qui ne se traduisent pas proprement, le client affichera des permissions qui ne reflètent pas la réalité. Ou inversement.

Conseils avisés :

Si vous utilisez un NAS comme cible de sauvegarde basique, préférez nounix et gérez les permissions au niveau du partage/ACL.
Si vous avez vraiment besoin de sémantiques POSIX (répertoires personnels partagés, flux multi-utilisateurs), utilisez Samba avec les extensions Unix correctement configurées et testez soigneusement. Ne supposez pas que votre fournisseur NAS l’a bien fait.

One short joke (1 of 2)

SMB « Permission denied » est comme une invitation calendrier d’entreprise : elle ne vous dit pas ce qui ne va pas, juste que votre après-midi est partie.

Identifiants vs autorisation : ACL de partage, ACL NTFS et bizarreries NAS

« Identifiants corrects » n’est pas équivalent à « vous êtes autorisé à faire l’action ». SMB sépare proprement :

Authentification : prouver qui vous êtes (mot de passe/Kerberos/NTLM).
Autorisation : déterminer ce que vous pouvez accéder (permissions de partage + permissions/ACL du système de fichiers).

Share permissions vs filesystem permissions

Beaucoup de systèmes NAS implémentent deux couches :

Accès au niveau du partage : qui peut se connecter à //server/share.
ACL au niveau du système de fichiers : ce que vous pouvez faire à l’intérieur (créer, supprimer, renommer).

Vous pouvez franchir la couche un et échouer à la couche deux. Le client signalera toujours « permission denied », et vous jurerez que le mot de passe est faux parce que c’est le seul levier que vous avez manipulé.

Domain formatting: `DOMAIN\user` vs `user@domain`

Les piles SMB diffèrent. Certains aiment LAB\backupuser. D’autres préfèrent backupuser@lab.local. mount.cifs préfère typiquement username= et domain= (ou imbriquer le domaine dans le nom d’utilisateur).

Règle pratique : utilisez le même format qui a réussi avec smbclient, puis traduisez-le en options de montage.

Guest access and “map to guest” behavior

Certaines configurations Samba/NAS autorisent l’accès invité, d’autres l’interdisent. Si votre client tente accidentellement l’auth invité ou anonyme (nom d’utilisateur vide, mauvais mappage de domaine), vous pouvez obtenir :

connexion réussie mais accès en lecture seule, ou
immediate permission denied.

Épinglez les identifiants explicitement. Évitez la pensée « il utilisera simplement mon utilisateur connecté » sur un nœud Proxmox.

Kerberos in Proxmox environments

Si vous montez depuis un hôte Linux joint au domaine avec un keytab, Kerberos est un bon choix. Mais c’est strict en exploitation :

La synchronisation temporelle doit être correcte.
Le DNS doit être correct.
Les SPN doivent exister et correspondre au nom de serveur que vous utilisez.

Les échecs Kerberos peuvent dégénérer en messages d’accès refusé. Si vous utilisez sec=krb5, engagez-vous sur les prérequis.

Trois mini-histoires d’entreprise (parce que vous les vivrez)

Mini-story 1: The incident caused by a wrong assumption

L’équipe avait un cluster Proxmox sauvegardant vers un NAS central via SMB. Le stockage avait été ajouté dans l’interface, il montait, et les sauvegardes fonctionnaient pendant des mois. Tout le monde se sentait à l’aise.

Puis le groupe sécurité a déployé une politique AD pour désactiver NTLM par phases. Ils ont envoyé un e-mail. Il a atterri là où atterrissent les mails de politique : le même endroit que « formation obligatoire » et « activité d’équipe fun ».

Un mardi matin, les sauvegardes ont commencé à échouer avec mount error(13): Permission denied. L’ingénieur on-call a fait la danse attendue : réinitialiser le mot de passe, retaper le mot de passe, essayer un autre compte. Même échec. Proxmox a été blâmé. Le NAS a été blâmé. Le réseau a été blâmé. Le temps a été brièvement blâmé, parce que le temps est toujours suspect dans les systèmes distribués.

Il s’est avéré que les identifiants étaient corrects. L’authentification était rejetée parce que NTLM n’était plus autorisé pour cette classe de comptes. Le montage nécessitait Kerberos : sec=krb5, un keytab, et un DNS stable.

La mauvaise hypothèse n’était pas « le mot de passe est faux ». La mauvaise hypothèse était « les politiques d’auth ne changent pas sous les systèmes en production ». Elles changent. Silencieusement. Selon un calendrier.

Mini-story 2: The optimization that backfired

Un ingénieur stockage voulait des sauvegardes plus rapides. Raisonnable. Ils ont optimisé les options de montage pour le débit, y compris un caching agressif et de plus grandes tailles de lecture/écriture. Les sauvegardes ont été plus rapides en petits tests.

Puis le jour de la restauration est arrivé. Une restauration de VM a échoué de façon intermittente avec des symptômes de corruption : morceaux manquants, checksums incohérents au niveau applicatif, et un comportement ressemblant à « stale file handle » par moments. Le partage SMB ne perdait pas de données ; le comportement côté client retournait des lectures incohérentes lors d’une charge d’écriture concurrente.

L’« optimisation » était un cocktail d’options qui avaient du sens isolément mais pas ensemble pour une charge de sauvegarde qui attend une forte cohérence. L’équipe avait transformé leur cible de sauvegarde en un cache enthousiaste avec des opinions.

Ils sont revenus à des sémantiques de cache plus strictes et des options plus simples. Les performances ont chuté. La fiabilité est revenue. La leçon était douloureuse et prévisible : pour les sauvegardes, la cohérence bat l’ingéniosité. Toujours.

Mini-story 3: The boring but correct practice that saved the day

Dans une autre entreprise, l’équipe SRE avait une politique : chaque montage de système de fichiers distant doit être reproductible avec une seule commande CLI documentée, et chaque montage doit épingler un dialecte SMB explicite et un mode de sécurité. Pas d’exception. C’était un peu pénible. Les gens se plaignaient. La politique est restée.

Pendant un cycle de mise à jour Proxmox, un sous-ensemble de nœuds a commencé à échouer les montages CIFS. L’erreur GUI était, comme prévu, « Permission denied ». La différence était que l’équipe disposait déjà de commandes « known good » et de sorties findmnt capturées avant la mise à jour.

Ils ont comparé les options utilisées avant/après le changement et ont trouvé qu’un nœud avait dérivé : il s’appuyait sur des valeurs par défaut et a négocié un dialecte différent à cause d’un ajustement côté NAS. Ils ont corrigé la config de stockage en épinglant vers=3.0 et le mode de sécurité explicitement, puis ont relancé le test CLI documenté. Fait.

Pratique ennuyeuse. Récupération rapide. Tout le monde est retourné faire semblant d’aimer les fenêtres de changement.

Erreurs courantes : symptôme → cause racine → correction

Cette section est directe parce que la production l’est.

1) Symptom: “Permission denied” but `smbclient -L` works

Cause racine : le montage utilise un dialecte/sécurité différent de smbclient, ou Proxmox passe moins d’options que votre test.
Correction : forcez vers=3.0 et sec=ntlmssp (ou krb5) dans options du stockage Proxmox. Vérifiez avec strace et findmnt.

2) Symptom: manual mount works as root, but Proxmox backups fail with permission errors

Cause racine : autorisation à l’intérieur du partage : l’ACL système de fichiers refuse create/write/rename sur le chemin utilisé par Proxmox, ou le NAS impose des opérations « admin only ».
Correction : testez write/create/delete sur le chemin monté ; corrigez l’ACL du partage et l’ACL du système de fichiers sous-jacent. Ne camouflez pas avec file_mode seulement.

3) Symptom: it worked yesterday; today “Permission denied” after updates

Cause racine : la négociation de dialecte ou les options par défaut ont changé ; le serveur a désactivé les fallback SMB2/SMB1 ; la politique NTLM s’est durcie.
Correction : épinglez vers et sec. Si NTLM a été désactivé, migrez vers Kerberos ou réactivez NTLM (si votre équipe sécurité l’autorise — ce qui est un autre incident).

4) Symptom: “Permission denied” only when using a hostname, but IP works

Cause racine : SPN / DNS / politique basée sur le nom (Kerberos attend le hostname), ou vous résolvez vers le mauvais hôte.
Correction : corrigez le DNS, vérifiez getent hosts, et pour Kerberos utilisez le nom canonique correspondant au SPN du serveur.

5) Symptom: Proxmox GUI storage add fails, but CLI mount works

Cause racine : config de stockage Proxmox manquante d’options requises, ou stockage des identifiants différent du test CLI.
Correction : ajoutez le stockage via CLI ou éditez /etc/pve/storage.cfg avec soin ; vérifiez avec pvesm activate et strace pour voir l’appel exact de montage.

6) Symptom: you can read but not write

Cause racine : le partage est en lecture seule pour cet utilisateur, ou l’ACL sous-jacente refuse write/create/delete.
Correction : utilisez smbclient pour tenter une écriture, et testez sur le montage avec touch/mkdir. Corrigez les permissions côté serveur, pas des cosmétiques côté client.

7) Symptom: “Permission denied” when password contains special characters

Cause racine : échappement shell ou parsing de la config Proxmox ; votre mot de passe n’est pas ce que vous pensez.
Correction : utilisez un fichier d’identifiants avec permissions strictes. Arrêtez de coller des secrets dans les commandes.

8) Symptom: intermittent permission issues under load

Cause racine : comportement de verrouillage/oplocks/leases, bugs NAS, ou options de caching inadaptées à la cohérence de la charge.
Correction : revenez à des options conservatrices ; assurez-vous que le NAS est supporté pour des écritures concurrentes lourdes ; envisagez NFS pour des charges Linux-centric si possible.

Listes de contrôle / plan pas à pas

Checklist A: Get a reliable mount on the Proxmox node (CLI first)

Résoudre le nom du serveur : getent hosts nas01. Si faux, corrigez le DNS ou utilisez l’IP temporairement.
Vérifier la reachabilité : nc -vz nas01 445. Si bloqué, corrigez réseau/pare-feu.
Confirmer les identifiants et la visibilité du partage : smbclient -L //nas01 -m SMB3 -U 'LAB\backupuser'.
Confirmer l’accès au partage : smbclient //nas01/backups -m SMB3 -U 'LAB\backupuser' -c 'ls'.
Créer un fichier d’identifiants avec perms 0600.
Monter avec des options épinglées (vers, sec, nounix, iocharset, UID/GID et modes).
Tester write/create/delete sur le chemin monté.
Capturer la sortie findmnt comme référence « known good ».

Checklist B: Make Proxmox use the same mount behavior

Inspecter /etc/pve/storage.cfg pour l’entrée CIFS du stockage.
Définir des options explicites pour correspondre au montage CLI réussi : dialecte, mode de sécurité et flags de compatibilité.
Exécuter pvesm activate <storageid>.
Si échec, lancer dmesg -T | tail -n 50 immédiatement après.
Utiliser strace sur pvesm activate pour confirmer les options passées à mount.cifs.
Vérifier le montage sous /mnt/pve/<storageid> avec findmnt.
Déclencher une petite sauvegarde Proxmox pour valider le comportement réel (écriture + patterns de renommage).

Checklist C: Kerberos track (when NTLM is not allowed)

Confirmer la synchronisation temporelle : timedatectl montre synchronisé.
Confirmer la correction du DNS pour le nom SMB du serveur.
Obtenir et installer un keytab pour le principal de service (opérationnel : coordonner avec les services d’annuaire).
Monter avec sec=krb5 et utiliser le nom d’hôte serveur correct (celui qui correspond au SPN).
Valider avec les logs noyau si l’auth échoue ; les échecs Kerberos peuvent apparaître comme problèmes d’accès.

Idée paraphrasée (citation fiabilité) : Le principe de Gene Kranz en contrôle de mission est essentiellement « être strict et compétent ». Cet état d’esprit s’applique parfaitement aux montages de stockage.

One short joke (2 of 2)

Rien ne dit « stockage d’entreprise » comme un protocole nommé « Simple » qui nécessite 14 options pour faire un montage basique.

FAQ

1) Why does Proxmox say “Permission denied” when the credentials are correct?

Parce que l’erreur reflète souvent l’autorisation (ACL de partage/NTFS), la politique (NTLM désactivé, signing requis), ou des échecs de négociation dialecte/sécurité, pas seulement la validité du mot de passe.

2) Should I always set `vers=3.0`?

En production, oui — définissez un dialecte explicite que vous savez supporté par le serveur. Si vous avez un NAS/Windows/Samba moderne, SMB3 est le bon baseline. Si le serveur supporte SMB3.1.1 de façon fiable, vous pouvez l’utiliser, mais la cohérence importe plus que les upgrades théoriques.

3) What’s the difference between `sec=ntlmssp` and `sec=krb5`?

ntlmssp utilise l’auth basée sur NTLM et est très compatible. krb5 utilise Kerberos et est typiquement préféré en environnements AD avec un contrôle de politique plus strict, mais il nécessite la synchronisation temporelle et un DNS/SPN corrects.

4) I can list the share but can’t create files. Why?

L’accès au niveau du partage permet de se connecter, mais les ACL du système de fichiers peuvent toujours bloquer les écritures. Testez avec touch sur le montage et corrigez les ACL côté serveur. file_mode côté client ne remplacera pas l’autorisation serveur.

5) Do `file_mode` and `dir_mode` fix permissions?

Ils affectent principalement la présentation des permissions sur le client Linux. Ils ne confèrent pas magiquement les droits d’écriture si le serveur les refuse.

6) Why does using a credentials file help?

Évite les problèmes d’échappement shell, empêche les secrets d’apparaître dans les listes de processus, et garde la commande de montage propre. Cela rend aussi plus difficile de coller accidentellement le mauvais mot de passe avec des caractères invisibles.

7) Proxmox mounts under `/mnt/pve`. Can I mount elsewhere?

Proxmox s’attend à gérer les storages sous /mnt/pve/<storageid>. Vous pouvez monter manuellement ailleurs pour des tests, mais la définition de stockage doit s’aligner sur les conventions Proxmox sauf si vous avez une forte raison de diverger.

8) Is CIFS a good choice for Proxmox backups?

Ça peut l’être. Mais traitez-le comme une dépendance réseau avec des changements de politique et des bizarreries de firmware NAS. Si vous contrôlez les deux côtés et que votre environnement est majoritairement Linux, NFS a souvent moins de surprises d’identité/ACL. Si vous êtes en environnement Windows/AD, SMB avec Kerberos est une voie d’entreprise solide.

9) What’s the single best troubleshooting signal?

dmesg immédiatement après l’échec. Il vous indique souvent si l’échec s’est produit pendant la session setup, le tree connect, ou des vérifications d’autorisation ultérieures.

Conclusion : étapes pratiques suivantes

Quand Proxmox CIFS affiche « Permission denied », arrêtez de débattre si le mot de passe est correct et commencez à collecter des preuves. Prouvez la reachabilité réseau, prouvez l’accès au partage avec smbclient, épinglez le dialecte SMB et le mode de sécurité, puis faites en sorte que Proxmox utilise exactement les mêmes options de montage qui ont fonctionné en CLI.

Étapes suivantes qui font réellement avancer :

Exécutez smbclient contre le partage exact et l’utilisateur que vous comptez monter.
Faites un montage manuel avec vers et sec explicites, puis vérifiez avec findmnt.
Testez les opérations d’écriture/création sur le chemin monté — ne supposez rien.
Faites correspondre Proxmox à votre jeu d’options connu-bon et validez avec pvesm activate plus dmesg.
Documentez l’ensemble final d’options de montage. Les valeurs par défaut changent. Votre vous futur ne se souviendra pas pourquoi cela fonctionnait.