Ubuntu 24.04 : montage CIFS « Permission denied » — les options exactes qui résolvent le problème

novembre 27, 2025 • février 3, 2026 • Lecture : 28 min • Views: 7

Cet article vous a aidé ?

Vous avez tapé la commande mount que vous avez tapée cent fois. Elle fonctionnait sur Ubuntu 22.04. Elle fonctionnait sur cet ancien jump host que personne n’ose patcher. Maintenant, sur Ubuntu 24.04, vous obtenez la punchline classique et inutile : « Permission denied ».

C’est l’un de ces échecs où le serveur dit techniquement la vérité, mais le client parle le mauvais dialecte. La correction tient généralement à une seule option de montage. La difficulté est de savoir laquelle et de le prouver avant de « corriger » et d’empirer le problème.

Playbook de diagnostic rapide (vérifiez ceci en premier)

Si vous êtes d’astreinte, vous n’avez pas le temps de devenir historien SMB à temps partiel. Voici le chemin le plus rapide vers le goulot probable, dans le bon ordre.

1) Confirmez que le serveur parle la version SMB que vous lui demandez

La plupart des tickets « Permission denied » sur Ubuntu 24.04 sont en réalité des « négociation de protocole et attentes d’auth ont changé ». Commencez par le dialecte SMB.

Si le serveur est ancien ou verrouillé : définissez explicitement vers=3.0 ou vers=2.1.
Si c’est du matériel NAS archaïque : vous pourriez avoir besoin de vers=1.0 (et dans ce cas prévoyez son remplacement).

2) Confirmez que le mécanisme d’auth (sec=) correspond à la politique serveur

Windows et beaucoup d’appliances NAS rejettent de plus en plus les variantes NTLM. Certains environnements exigent Kerberos. Certaines boîtes « durcies » exigent NTLMv2 uniquement. Rendre sec= explicite et arrêter de deviner.

3) Vérifiez le log du kernel pour la vraie raison (ne faites pas confiance à la ligne unique de mount)

mount.cifs aime tout résumer par « Permission denied ». Le client CIFS du kernel vous dira si c’est un mauvais mot de passe, un SPN incorrect, une clé manquante, un décalage horaire ou un échec de signature.

4) Prouvez que vos identifiants sont bien ceux que vous pensez

Nom de domaine erroné, format d’utilisateur incorrect, caractères spéciaux dans les mots de passe, ou un fichier d’identifiants avec des fins de ligne Windows peuvent tous se traduire par « permission denied ». Oui, même en 2025.

5) Ensuite seulement, examinez les permissions du système de fichiers et les ACL

Les permissions POSIX ne sont souvent pas le premier problème. Sur SMB, vous pouvez vous authentifier avec succès et être quand même refusé par les permissions du partage ou les ACL NTFS. Mais si vous ne pouvez pas vous authentifier, les contrôles de permissions sont hors sujet.

Règle opérationnelle : ne changez pas trois variables en même temps. Dialecte, auth et mappage d’identité sont trois réglages séparés. Tournez-les un par un et observez.

Ce que « Permission denied » signifie vraiment pour CIFS sur Ubuntu 24.04

Sur Linux, « Permission denied » sur un montage CIFS se traduit généralement par EACCES (erreur 13). Cette erreur est levée pour plusieurs situations distinctes :

Échec d’authentification (mauvais user/pass, domaine erroné, méthode d’auth incorrecte).
Échec d’autorisation (vous vous êtes authentifié, mais le partage refuse l’accès).
Inadéquation de négociation (dialecte SMB ou signature/chiffrement incompatible, parfois exposé comme accès refusé).
Échec de plomberie Kerberos (pas de ticket, SPN incorrect, dérive d’horloge, keytab mal configuré).
Inadéquation de politique machine (le serveur rejette l’invité, rejette NTLM, exige la signature, exige le chiffrement).
Confusion côté client pour le mappage (le montage réussit mais les opérations échouent ; les applis rapportent « permission denied » plus tard).

Ubuntu 24.04 ne « casse pas CIFS » pour le plaisir. Il embarque des kernels plus récents, des outils Samba client plus récents et des paramètres par défaut plus stricts dans des écosystèmes qui essaient d’éliminer les configurations SMB/NTLM peu sûres. C’est une bonne chose pour la sécurité. C’est juste mauvais pour votre sommeil.

Idée paraphrasée (attribuée) : Werner Vogels a soutenu qu’il faut construire des systèmes en supposant que l’échec est normal, puis concevoir la récupération. Le montage CIFS en est un parfait exemple : supposez que la négociation et l’authentification vont échouer de façons nouvelles et créatives, et construisez un parcours de diagnostic répétable.

Les options de montage exactes qui règlent le problème (copier/coller, puis adapter)

Ci‑dessous les ensembles d’options de montage qui transforment le plus souvent un « Permission denied » sur Ubuntu 24.04 en un montage propre. Commencez par celui qui correspond à votre environnement. Ne freestylez pas.

Cas A : serveur Windows / Samba moderne, identifiants locaux (le plus courant)

Si vous montez un partage avec un nom d’utilisateur/mot de passe (pas Kerberos), et que vous ne voulez pas de surprises :

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

Pourquoi cela fonctionne :

vers=3.0 : rend la négociation explicite ; évite les comportements de repli « utiles » qui varient selon le serveur.
sec=ntlmssp : courant pour Windows quand Kerberos n’est pas utilisé.
sign : satisfait les serveurs exigeant la signature ; si le serveur ne l’exige pas, la signature est généralement acceptable.
seal : active le chiffrement SMB3 quand il est supporté ; si le serveur exige le chiffrement, ceci évite un refus.
uid/gid + file_mode/dir_mode : donnent une propriété/mode cohérents pour les processus Linux.
x-systemd.automount : évite les blocages au démarrage et rend les montages résilients.

Cas B : le serveur Windows exige la signature SMB, mais le chiffrement n’est pas activé

Si seal pose problème (serveur ancien, enjeux de performance, ou politique serveur ne le supporte pas), supprimez-le mais gardez la signature :

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

Cas C : NAS ancien ou Samba ancien qui ne fait pas SMB3

C’est souvent là que « Permission denied » masque un refus de dialecte. Essayez SMB2.1 d’abord :

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 l’appareil est vraiment antique, vers=1.0 peut être la seule réponse. C’est aussi une bonne raison d’ouvrir une demande de remplacement avec un objet très calme.

Cas D : Active Directory avec Kerberos (le « ça marche sur un hôte » spécial)

Pour les environnements intégrés AD, Kerberos est le choix correct à long terme. Il échoue aussi de façons plus intéressantes.

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

Remarques : cruid= lie le cache d’identifiants du montage à l’utilisateur local approprié. multiuser permet d’utiliser les creds Kerberos de plusieurs utilisateurs sur un seul montage (utile sur des hôtes partagés, dangereux si vous ne maîtrisez pas).

Cas E : utilisateur de domaine avec NTLMSSP, mais le format du domaine pose problème

Ici « permission denied » signifie que votre nom d’utilisateur n’est pas parsé comme vous le pensez. Utilisez une de ces formes :

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

Cas F : le partage autorise l’invité, mais Ubuntu ne devine plus « guest »

L’accès invité est de plus en plus bloqué (pour de bonnes raisons). Mais si vous avez réellement un partage public en lecture seule :

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

Soyez explicite. Si le serveur rejette l’accès invité, ceci échouera quand même — mais maintenant vous savez que vous n’envoyez pas par accident un nom d’utilisateur non désiré.

Blague n°1 : SMB est le seul protocole qui peut être à la fois « rétrocompatible » et « ne supporte plus la chose que vous avez utilisée pendant 12 ans ».

Tâches pratiques : commandes, sorties et décision à prendre (12+)

C’est la partie que vous utilisez pendant les incidents. Chaque tâche contient : la commande, ce que signifie la sortie, et la décision suivante.

Task 1: Confirm the kernel and cifs-utils version (baseline matters)

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

Signification : Vous êtes sur la pile cliente CIFS plus récente ; les valeurs par défaut et les capacités de sécurité diffèrent des hôtes plus anciens.

Décision : Arrêtez de comparer le comportement à Ubuntu 20.04/22.04 sauf si vous comparez aussi sec, vers et les exigences de signature/chiffrement.

Task 2: Verify name resolution (permission errors can mask “wrong server”)

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

Signification : DNS résout en une IP. Si elle correspond à une IP inattendue (VIP déplacé, DNS split, /etc/hosts obsolète), vous pouvez vous authentifier sur la mauvaise machine.

Décision : Si l’IP est inattendue, corrigez DNS/hosts avant de toucher aux options de montage.

Task 3: Confirm the TCP port is reachable (firewalls lie quietly)

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

Signification : Le port 445 est joignable. Si ça échoue, vous n’avez pas un problème d’auth — vous avez un problème réseau.

Décision : Si bloqué, stoppez. Escaladez vers réseau/sécurité ; ne « corrigez » pas les options CIFS.

Task 4: List shares with smbclient (auth sanity check)

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

Signification : Les identifiants sont acceptés et la négociation SMB fonctionne. C’est la moitié de la bataille.

Décision : Si smbclient échoue avec NT_STATUS_ACCESS_DENIED, concentrez-vous sur username/password/domain/sec. S’il réussit mais que le montage échoue, concentrez-vous sur les options de montage (signature/chiffrement, vers, Kerberos, idmap).

Task 5: Test access to the specific share (share ACL vs mount failure)

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

Signification : Vous pouvez vous authentifier et accéder au contenu du partage. Si le montage indique encore « permission denied », le problème est presque certainement lié à la négociation/sécurité, pas aux ACL NTFS/partage.

Décision : Essayez vers= et sec= explicites, puis signature/chiffrement.

Task 6: Run the mount with verbose output (user-space hints)

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

Signification : Toujours ambigu. C’est pourquoi on vérifie ensuite les logs du kernel.

Décision : Allez voir dmesg et cherchez les messages CIFS qui donnent la vraie cause.

Task 7: Read kernel messages for CIFS (the truth lives here)

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

Signification : Session setup échouée (auth/négociation). Parfois vous verrez des lignes plus spécifiques comme « Server requires packet signing » ou « Krb5 authentication failed ».

Décision : Si les logs mentionnent signature/chiffrement, ajoutez sign et/ou seal. S’ils mentionnent Kerberos, passez au diagnostic Kerberos.

Task 8: Confirm what security modes the client thinks it can use

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

Signification : Le module CIFS du kernel est présent et moderne. Vous ne « réparerez » pas cela en réinstallant cifs-utils.

Décision : Concentrez-vous sur la configuration et la discordance de politique serveur, pas sur des changements de paquet.

Task 9: Inspect the credentials file for format problems (permissions and 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

Signification : Le fichier est lisible uniquement par root (bien). S’il est lisible par tous, vous avez inventé une fuite d’identifiants.

Décision : Si le fichier vient d’outils Windows, vérifiez les CRLF. CRLF peut rendre le mot de passe invalide d’une manière que vous ne verrez pas à l’œil nu.

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

Signification : $ en fin de ligne indique LF. Si vous voyez ^M$, convertissez-le (dos2unix) et retentez.

Décision : Corrigez les fins de ligne avant d’accuser le serveur.

Task 10: Try a different SMB dialect (fast, 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

Signification : Si 3.1.1 échoue mais 3.0 réussit, le serveur peut être pointilleux sur la négociation ou les fonctionnalités de sécurité liées aux dialectes plus récents.

Décision : Verrouillez le vers qui fonctionne explicitement dans /etc/fstab et documentez pourquoi.

Task 11: Try explicit security mode (sec=) rather than relying on defaults

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

Signification : Certains serveurs acceptent ntlmssp mais rejettent ntlmv2 (ou vice versa). En contexte AD, on peut vous demander d’utiliser Kerberos plutôt.

Décision : Si ntlmssp ne fonctionne pas et que la politique exige « Kerberos only », cessez de forcer NTLM et passez à la configuration Kerberos.

Task 12: Verify the mount is actually using the options you think it is

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)

Signification : Le montage en cours montre les paramètres négociés. Cela détecte le problème classique où vous avez édité /etc/fstab mais pas remounté, ou vous regardez le mauvais point de montage.

Décision : Si le vers ou le sec affiché n’est pas celui prévu, vous ne testez pas la bonne chose.

Task 13: Confirm file operations actually work (mount success can still hide permission issues)

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

Signification : Vous avez monté le partage, mais vous n’êtes pas autorisé à écrire. C’est un problème d’autorisation/ACL, pas de négociation de montage.

Décision : Validez les permissions du partage et les ACL NTFS pour l’utilisateur. Ne continuez pas à changer sec et vers ; vous êtes déjà connecté.

Task 14: Inspect ACL-ish behavior from Linux (spot mapping confusion)

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

Signification : La propriété/mode locaux sont une présentation côté client, pas nécessairement la réalité NTFS du serveur (sauf si vous utilisez des extensions POSIX SMB de bout en bout).

Décision : Si les applis Linux dépendent de la sémantique POSIX, décidez si vous avez besoin de Samba côté serveur avec un mappage POSIX approprié, ou si SMB n’est qu’un transport pour un accès « basique » aux fichiers.

Active Directory / Kerberos cases (where “permission denied” lies)

Si votre organisation a AD, il est probable que quelqu’un ait poussé « NTLM : disabled » ou « SMB signing required » via une stratégie. Ce n’est pas un bug. C’est une contrainte opérationnelle. Le client CIFS doit correspondre aux paramètres d’authentification et d’intégrité exigés par le serveur.

Kerberos prerequisites you can’t wish away

Synchronisation horaire doit être correcte. Kerberos est allergique à la dérive d’horloge.
DNS doit être correct. Kerberos utilise des SPN qui dépendent des noms.
Cache de tickets doit exister pour l’utilisateur effectuant le montage (ou vous devez utiliser un keytab et le bon mode de montage).

Task 15: Check time sync (Kerberos cares, a lot)

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

Signification : L’heure est synchronisée. Si ce n’est pas le cas, Kerberos peut échouer en signalant « permission denied » parce que vous ne vous êtes jamais authentifié avec succès.

Décision : Si non synchronisé, corrigez NTP/chrony avant toute retouche CIFS.

Task 16: Verify you have Kerberos tickets (user-space sanity check)

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

Signification : Vous avez un TGT. Si vous n’en avez pas, un montage sec=krb5 échouera.

Décision : Acquérez un ticket avec kinit, ou utilisez une stratégie keytab système si cela doit être non interactif.

Task 17: Try Kerberos mount with explicit cruid (avoid wrong cache)

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

Signification : Si cela fonctionne mais que la même commande sans cruid échoue, vous utilisiez le mauvais cache d’identifiants (fréquent quand on utilise sudo).

Décision : Standardisez les montages Kerberos avec cruid et des unités systemd automount, pas des sessions sudo ad hoc.

Blague n°2 : Kerberos, c’est comme un videur de boîte : sécurité impeccable, et absolument aucune patience pour une horloge à cinq minutes d’écart.

UID/GID mapping and why your files “work” but your apps don’t

C’est un mode d’échec plus discret. Le montage réussit. Les listings de répertoire fonctionnent. Puis votre application ne peut pas créer de fichiers de verrouillage, ou votre job CI ne peut pas chmod, ou votre conteneur ne peut pas écrire.

Il y a deux grands mondes :

Mappage de présentation où vous forcez la propriété avec uid=, gid= et les modes. C’est courant et souvent suffisant.
Mappage d’identité réel où les SIDs se mappent aux IDs POSIX. C’est plus complexe et généralement un choix d’entreprise, pas un simple réglage côté client Linux.

Que faire sur les clients Ubuntu (par défaut pragmatique)

Sauf si vous disposez d’un design AD→POSIX complet, ne faites pas semblant. Utilisez un mappage simple :

uid=, gid= pour rendre la propriété prévisible pour le compte de service consommateur.
file_mode=, dir_mode= pour correspondre à ce que le processus Linux attend.
Envisagez noperm si le serveur applique des ACLs et que vous ne voulez pas que le client Linux tente de rejuger l’accès (utile dans certains cas, mais dangereux).

Task 18: Detect the “noperm needed” scenario

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

Signification : Le contrôle de permission côté client refuse l’accès pour l’UID local, même si le serveur peut l’autoriser en se basant sur les identifiants SMB.

Décision : Essayez noperm seulement si vous comprenez que le serveur est la source de vérité et que vous ne comptez pas sur les bits de mode locaux pour l’application de l’accès.

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

Signing, encryption, and the corporate security tax

La signature SMB et le chiffrement SMB sont les deux leviers de politique qui se transforment le plus souvent en « Permission denied » quand les clients ne s’y conforment pas.

SMB signing

La signature protège l’intégrité : elle empêche les altérations. Beaucoup d’environnements Windows l’exigent, en particulier pour les partages liés au domaine ou les serveurs durcis.

Sur les montages CIFS Linux, vous pouvez l’imposer avec sign. Si le serveur exige la signature et que le client ne l’applique pas, le serveur peut refuser le setup de session ou les opérations ultérieures.

SMB encryption (seal)

Le chiffrement protège la confidentialité. Le chiffrement SMB3 est négocié et peut être exigé par partage sur Windows. Sur Linux, seal active le chiffrement.

Le chiffrement peut réduire le débit et augmenter l’utilisation CPU. Parfois c’est acceptable. Parfois c’est un incident de performance en attente. L’important : rendez-le explicite et planifiez la capacité.

Task 19: Spot signing/encryption-related failures in kernel logs

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

Signification : On vous refuse parce que vous n’avez pas signé.

Décision : Ajoutez sign et retentez. Si vous avez déjà sign et que vous voyez encore ce message, vous négociez peut-être un dialecte ancien — verrouillez vers=3.0 ou plus.

Trois mini-récits d’entreprise issus du terrain

1) Incident causé par une fausse hypothèse : « Permission denied signifie que le mot de passe est faux »

Ils avaient une intégration paie sur une petite flotte Ubuntu. Les partages étaient sur Windows. Un rafraîchissement d’OS régulier a déplacé deux nœuds applicatifs vers Ubuntu 24.04. Le montage a échoué au démarrage. L’équipe a supposé une rotation d’identifiants parce que, bon, c’est toujours ce qui arrive quand quelque chose dit « permission denied ».

La réponse immédiate était prévisible : réémettre les mots de passe, reverifier le coffre de secrets, re-roll des comptes de service. Des heures ont passé. Rien n’a changé. Les anciens nœuds montaient toujours. Les nouveaux non. Cela aurait dû être l’indice, mais les incidents n’encouragent pas la subtilité.

Finalement quelqu’un a regardé dmesg et a trouvé que le serveur exigeait la signature. Les nœuds anciens négociaient implicitement un dialecte et un comportement de signature différents ; les nouveaux n’étaient pas compatibles avec la politique. Ajouter vers=3.0,sign a corrigé immédiatement.

Le postmortem n’a pas été « lisez dmesg ». C’est trop simple. Le takeaway a été que les politiques SMB sont un contrat à trois parties : config du serveur, politique de domaine et défauts client. Quand vous mettez à jour une des parties, vous renégociez le contrat même si vous ne le vouliez pas.

2) Optimisation qui s’est retournée contre eux : « Désactivons le chiffrement pour la perf »

Une autre entreprise stockait des artéfacts de build sur SMB parce que « c’est essentiellement un disque réseau ». Ils avaient activé le chiffrement SMB3 après un audit de sécurité. Les perfs ont chuté. Les devs se sont plaints. La direction a entendu « builds lents » et a demandé une action.

L’équipe infra a retiré seal des options de montage pour accélérer. Ça a marché dans un environnement. Dans un autre, le même changement de fstab a provoqué des échecs de montage avec « permission denied ». Pas partout — seulement pour certains partages.

La raison était subtile mais logique : le chiffrement était exigé par partage sur certains serveurs. Ceux hébergeant des artéfacts sensibles l’imposaient. Supprimer seal était donc une violation d’accès, pas un tweak de performance.

Ils ont fini par faire l’ingénierie ennuyeuse : garder seal, mesurer l’impact CPU, et déplacer les builders les plus gourmands vers des instances avec plus de CPU. L’optimisation a échoué parce qu’ils avaient optimisé le mauvais niveau — la politique, pas le débit.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : « systemd automount + nofail + options verrouillées »

Une organisation de santé (oui, ce genre de pression d’uptime) avait une règle : les montages réseau ne doivent jamais bloquer le boot. Chaque montage CIFS utilisait systemd automount, nofail, et vers/sec explicites verrouillés sur ce que l’équipe serveur supportait.

Un matin, une fenêtre de maintenance du contrôleur de domaine a créé des problèmes Kerberos transitoires. Plusieurs hôtes ont perdu la capacité de monter des partages protégés AD au démarrage. Mais les hôtes sont quand même montés, les services ont démarré, et le monitoring est resté vivant. Les montages ont été relancés à l’accès et ont récupéré une fois Kerberos stabilisé.

Il y a eu tout de même un impact — certains jobs applicatifs n’ont pas pu lire leurs entrées pendant un moment. Mais l’infra n’est pas tombée en boucle de démarrage ou en mode emergency. Cette différence compte. Beaucoup.

Le meilleur : les notes d’incident étaient courtes parce que le comportement était déjà attendu. « Montages à la demande ; vérifier tickets ; vérifier reachabilité DC ; attendre ; vérifier remount. » Ennuyeux. Correct. Salvateur.

Erreurs courantes : symptôme → cause racine → fix

Cette section est volontairement spécifique. CIFS échoue selon des schémas répétitifs. Reconnaissez le motif, appliquez le correctif, passez à autre chose.

1) Symptom: mount error(13) immediately, smbclient works

Cause racine : inadéquation signature/chiffrement, ou mount utilise des valeurs par défaut différentes de smbclient.

Fix : pinnez les options : vers=3.0,sec=ntlmssp,sign ; ajoutez seal si le serveur exige le chiffrement. Vérifiez avec mount | grep et dmesg.

2) Symptom: mount works with IP, fails with hostname

Cause racine : mismatch DNS/SPN (surtout avec Kerberos), ou vous atteignez un serveur différent derrière le nom.

Fix : utilisez le DNS correct, confirmez avec getent hosts. Pour Kerberos, assurez-vous que le SPN correspond au nom que vous montez.

3) Symptom: works on one Ubuntu host, fails on another with same command

Cause racine : valeurs par défaut kernel/client différentes, cache d’identifiants Kerberos différent, DNS différent, ou politique crypto différente.

Fix : comparez uname -r, dpkg -l cifs-utils, et la sortie de mount -vvv plus dmesg. Rendre vers et sec explicites.

4) Symptom: mount succeeds, but writes fail with “Permission denied”

Cause racine : ACL de partage / ACL NTFS refusent l’écriture ; ou le partage est en lecture seule ; ou vous avez monté en ro.

Fix : confirmez avec un test d’écriture via smbclient ; vérifiez les permissions côté serveur. Ne touchez pas à vers/sec ; l’auth est déjà OK.

5) Symptom: “Permission denied” only when running under systemd at boot

Cause racine : réseau non prêt, DNS non prêt, ticket Kerberos non disponible, ou montage exécuté avant les dépendances.

Fix : utilisez x-systemd.automount, nofail, et envisagez _netdev. Pour Kerberos, assurez-vous que les tickets existent dans le contexte exécutant l’accès, ou utilisez une stratégie keytab.

6) Symptom: “Permission denied” after password rotation, but credentials file looks correct

Cause racine : fins de ligne CRLF, problèmes de quoting, ou caractères invisibles dans le mot de passe.

Fix : inspectez avec cat -A ; convertissez en LF ; retapez soigneusement ; évitez de copier via des outils rich-text.

7) Symptom: “mount error(13)” only for some shares on the same server

Cause racine : politique par partage (chiffrement requis, modèle ACL différent) ou permissions du partage différentes.

Fix : testez chaque partage avec smbclient //server/share. Ajoutez seal pour les partages sensibles si requis.

Checklists / step-by-step plan (ennuyeux volontairement)

Utilisez ceci quand vous voulez que votre futur vous remercie.

Checklist 1: One-time host setup (Ubuntu 24.04 CIFS client)

Installez les outils : cifs-utils, smbclient, et outils Kerberos si besoin.
Créez un fichier d’identifiants sous /etc/cifs/ avec perms 0600 et appartenant à root.
Créez le point de montage avec la propriété et permissions correctes pour le service consommateur.
Décidez du modèle d’auth : NTLMSSP vs Kerberos. Ne « testez les deux » pas dans des configs de prod.
Pinnez vers et sec. Ajoutez sign. Ajoutez seal si requis ou souhaité.

Checklist 2: Production fstab entry that won’t ruin your boot

Une ligne fstab raisonnable pour l’auth par mot de passe :

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"

Puis validez sans redémarrer :

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

Décision : Si mount -a échoue, lisez dmesg. Ne redémarrez pas en espérant que ça « corrige ». Ce n’est pas une stratégie ; c’est de la superstition avec des étapes en plus.

Checklist 3: Incident response sequence (15 minutes, disciplined)

Vérifiez la connectivité au port 445 (nc -vz host 445).
Vérifiez le mapping DNS (getent hosts).
Validez les identifiants avec smbclient -L et l’accès au partage avec smbclient //host/share.
Montez avec vers et sec explicites (commencez par vers=3.0,sec=ntlmssp ou sec=krb5).
Ajoutez sign ; ajoutez seal si les logs suggèrent que le chiffrement est requis.
Lisez dmesg pour les messages CIFS après chaque tentative.
Une fois monté, faites un test d’écriture (touch) pour distinguer auth vs ACL.

Faits intéressants & contexte (parce que SMB traîne des bagages)

SMB a commencé chez IBM dans les années 1980 avant que Microsoft ne le rende célèbre. L’âge du protocole se traduit par des bizarreries de compatibilité aujourd’hui.
« CIFS » est essentiellement une marque de l’ère SMB1. Linux utilise encore la terminologie « cifs » pour des raisons historiques, même quand vous montez SMB3.
La désactivation de SMB1 est maintenant la norme. Beaucoup de serveurs le refusent carrément ; les clients qui supposent un repli sur SMB1 rencontrent des erreurs d’accès confuses.
NTLM est sur la liste « veuillez arrêter » depuis des années. Beaucoup d’entreprises retirent activement NTLM au profit de Kerberos.
La signature SMB était autrefois optionnelle et maintenant est souvent requise. Cela renverse des anciens comportements par défaut dans des environnements durcis.
SMB3 a introduit le chiffrement, qui est négocié et peut être exigé par partage. C’est pourquoi « certains partages fonctionnent » est un symptôme réel.
Le comportement du client CIFS Linux est partagé entre user-space et kernel. mount.cifs passe des options ; le kernel fait la majeure partie du travail réel et journalise les erreurs réelles.
Les échecs Kerberos ressemblent souvent à des échecs d’autorisation parce que le serveur ne peut pas toujours distinguer « mauvaise plomberie de ticket » de « pas d’accès » d’une façon conviviale pour le client.
UID/GID sur CIFS est principalement une illusion côté client sauf si vous déployez un mappage d’identité complet et/ou des extensions POSIX de façon cohérente.

FAQ

1) Pourquoi Ubuntu 24.04 affiche « Permission denied » alors qu’Ubuntu 22.04 fonctionnait ?

Parce que vous avez changé le comportement client en mettant à jour : code CIFS du kernel plus récent, négociation par défaut différente et attentes de sécurité plus strictes. Pinnez vers et sec pour ne plus dépendre des valeurs par défaut.

2) Quelle est la meilleure option de « premier correctif » ?

vers=3.0. Cela élimine une grande classe d’ambiguïtés de négociation. Associez-le à sec=ntlmssp pour l’auth par mot de passe ou sec=krb5 pour Kerberos AD.

3) Dois‑je utiliser `sec=ntlm` ou `vers=1.0` pour que ça marche ?

Seulement si vous gérez une infrastructure vraiment legacy et que vous avez accepté le risque de sécurité. Si nécessaire temporairement, isolez‑le, documentez et planifiez une sortie. Traitez‑le comme exécuter telnet en production : possible, mais pas un mode de vie.

4) Quelle est la différence entre `sign` et `seal` ?

sign impose l’intégrité (les messages ne peuvent pas être altérés inaperçus). seal active le chiffrement SMB (confidentialité). Les serveurs peuvent en exiger un ou les deux.

5) smbclient fonctionne, le montage échoue. Comment est-ce possible ?

smbclient et le montage CIFS kernel peuvent négocier légèrement différemment et utiliser des valeurs par défaut différentes. De plus, le montage peut être rejeté à cause d’exigences de signature/chiffrement que votre test smbclient n’a pas déclenchées de la même façon. Utilisez les logs kernel (dmesg) pour voir pourquoi le montage est rejeté.

6) Où dois‑je mettre les identifiants, et comment les sécuriser ?

Utilisez un fichier d’identifiants comme /etc/cifs/share.cred possédé par root avec permissions 0600. N’insérez pas de mots de passe directement dans /etc/fstab. Ne le laissez pas lisible par des utilisateurs de service « pour plus de commodité ».

7) Mon montage fonctionne en interactif mais échoue au démarrage. Quelle est la solution ?

Utilisez nofail,_netdev,x-systemd.automount pour que le système démarre indépendamment du réseau, et que le montage se fasse au premier accès. Pour Kerberos, assurez‑vous que les tickets sont disponibles dans le contexte faisant l’accès, ou utilisez un design basé sur keytab.

8) Dois‑je utiliser `noperm` ?

Parfois. Cela peut résoudre des mismatches de vérification de permission locale quand le serveur est l’autorité. Mais cela supprime aussi une couche de protection locale. Utilisez‑le intentionnellement, pas par superstition.

9) Pourquoi je vois des propriétaires étranges comme root ou nobody ?

Parce que SMB ne mappe pas intrinsèquement les identités Windows aux UIDs/GIDs Linux sans mécanismes supplémentaires. Définissez uid=, gid= et les modes pour un comportement Linux prévisible, ou implémentez un mappage d’identité si votre environnement l’exige.

10) Monter CIFS dans des conteneurs est‑ce une bonne idée ?

Pas par défaut. Montez CIFS sur l’hôte et faites un bind‑mount dans les conteneurs, sauf si vous comprenez parfaitement les capacités du kernel, la gestion des identifiants et comment votre orchestrateur traite les montages.

Conclusion : prochaines étapes durables

Si Ubuntu 24.04 affiche « Permission denied » sur un montage CIFS, supposez qu’il y a une inadéquation entre ce que vous demandez et ce que la politique serveur exige. Puis prouvez‑le avec les preuves adéquates.

Faites ceci ensuite :

Exécutez des tests smbclient pour séparer les problèmes d’identifiants/ACL des problèmes de négociation de montage.
Pinnez vers=3.0 et la bonne valeur sec=. Ajoutez sign. Ajoutez seal si nécessaire.
Lisez dmesg après chaque tentative échouée ; considérez le texte d’erreur de mount comme un résumé, pas comme un diagnostic.
Mettez la configuration fonctionnelle dans /etc/fstab en utilisant nofail et x-systemd.automount afin que le prochain redémarrage ne devienne pas votre prochain incident.