Mappage des ACL ZFS pour SMB : éviter les cauchemars de permissions

Un modèle mental pour arrêter l’hémorragie

Vous jonglez avec trois langages de permissions différents :
les ACL Windows (clients SMB), l’interprétation de Samba, et le modèle d’ACL sur disque de ZFS. S’ils ne sont pas d’accord, les utilisateurs n’obtiennent pas un avertissement poli ; ils obtiennent
Access denied et votre file de tickets ressemble à une scène de crime.

Voici le modèle mental sensé :

• ZFS stocke des ACL de type NFSv4 (aussi appelées « NFS4 ACLs ») quand acltype=nfsv4. Celles-ci peuvent représenter des ACE à la Windows :
  allow/deny, drapeaux d’héritage, et permissions fines. C’est le meilleur rapprochement pour SMB.
• Les bits de mode POSIX existent toujours (rwxrwxrwx), mais selon des propriétés comme aclmode et aclinherit,
  ils sont soit une barrière significative soit un simple autocollant décoratif.
• Samba mappe les SID aux ID UNIX. Si ce mappage change, les entrées ACL continuent de pointer vers l’ancienne identité. L’ACL n’a pas « cassé » ;
  votre couche d’identités l’a fait.
• « Permissions de partage » vs « permissions de fichier » : Samba a des restrictions au niveau du partage et des ACL au niveau du système de fichiers. La permission effective est
  l’intersection. Vous pouvez être généreux d’un côté et strict de l’autre, mais si vous êtes strict sur les deux vous inventerez de nouvelles formes de souffrance.

Traitez votre environnement d’abord comme un système d’identité, ensuite comme un système d’ACL, et enfin comme un système de stockage. Cet ordre n’est pas philosophique — c’est
la séquence des défaillances que vous verrez en production.

Une idée paraphrasée de W. Edwards Deming s’applique : idée paraphrasée : un mauvais système vaincra des bonnes personnes à chaque fois. Dans le travail sur les permissions,
le « système » est votre couche de mappage et votre stratégie d’héritage.

Faits intéressants et contexte historique

Un peu de contexte aide, car la moitié des douleurs d’aujourd’hui sont les compromis d’hier.

1. Windows NT a introduit les ACL au début des années 1990 avec une sémantique allow/deny et l’héritage. Le modèle précède de plusieurs décennies les
   déploiements Samba modernes, d’où les fortes attentes des clients Windows.
2. Les bits de mode POSIX sont plus anciens et plus simples : user/group/other avec rwx. Ils ne peuvent pas exprimer le « deny », ne peuvent pas exprimer des exceptions par utilisateur,
   et l’héritage n’est pas natif.
3. Les ACL NFSv4 ont été conçues pour être plus riches que POSIX et plus proches de la sémantique Windows, ce qui explique pourquoi ZFS s’appuie sur elles pour des ACL compatibles SMB.
4. Samba utilise depuis longtemps des modules VFS modulables ; ceux orientés ZFS existent parce que la gestion générique des ACL POSIX ne peut pas capturer complètement la sémantique
   des ACL NFSv4 de ZFS sans traduction.
5. ZFS de l’ère Solaris traitait les ACL NFSv4 comme une fonctionnalité de première classe. Ce choix de conception se retrouve dans OpenZFS aujourd’hui : le modèle d’ACL n’est pas un ajout.
6. Les « ACL riches » ont un coût : elles augmentent le travail métadonnée, et des opérations comme la correction récursive d’héritage peuvent être coûteuses. Quand les problèmes de permissions
   surviennent à grande échelle, rarement c’est un seul fichier — c’est l’arbre à un million de fichiers derrière.
7. Le mappage d’identités est la dépendance cachée : SMB parle SID ; UNIX parle UID/GID. La couche SID→UID est là où naît le « ça marchait hier ».
8. ZFS a des propriétés qui influencent le comportement des ACL (aclmode, aclinherit, xattr). Ce ne sont pas des boutons cosmétiques.
   Elles changent ce que fait chmod et si l’héritage se comporte comme Windows l’attend.

Comment les ACL ZFS se mappent vers SMB (et où ça casse)

1) Les deux grands choix de compatibilité : ACL POSIX vs ACL NFSv4

Si vous servez du SMB à des clients Windows et que vous voulez un édition des ACL à la Windows, vous voulez acltype=nfsv4 sur le dataset. Cela donne à ZFS un vocabulaire d’ACL
qui peut représenter des concepts Windows : drapeaux d’héritage, entrées « deny », et permissions fines.

Les ACL POSIX (acltype=posixacl) peuvent fonctionner dans des environnements majoritairement Linux, mais la traduction vers la sémantique Windows devient « approximative ». Approximatif est
un mot poli. C’est comme mesurer un data center avec un ruban imprimé de mémoire.

2) Le rôle de Samba : traduire les descripteurs de sécurité Windows en ACL du système de fichiers

Un client Windows envoie un descripteur de sécurité (quelque chose de proche du SDDL en coulisses). Samba évalue si le client est autorisé à le définir, puis le traduit en
entrées ACL du système de fichiers. Avec les ACL NFSv4 de ZFS, cette traduction peut être quasi directe.

Quand la traduction est avec perte — parce que le système de fichiers ne peut pas représenter certains drapeaux Windows — Samba fait de son mieux et vous obtenez un « ça marche pour la plupart » jusqu’à
ce que vous touchiez des cas limites : des denies hérités, la sémantique CREATOR OWNER, ou des évaluations de membership de groupe étranges.

3) Propriétés ZFS qui décident si vous vous réveillez la nuit

• aclmode : contrôle comment chmod interagit avec les ACL. Dans les environnements SMB, vous voulez souvent que chmod n’écrase pas l’intention des ACL.
• aclinherit : contrôle comment les ACL sont héritées et si elles sont réécrites. Si cela n’aligne pas avec les attentes Windows,
  vous verrez « les nouveaux fichiers ne correspondent pas aux permissions du dossier ».
• xattr : contrôle comment les attributs étendus sont stockés (on, sa). Cela peut affecter la performance et le comportement pour
  les charges de travail lourdes en ACL car les ACL et les métadonnées SMB utilisent des xattrs.
• casesensitivity : Windows est insensible à la casse par défaut. Les discordances ici causent des « doublons fantômes » ou des contrôles d’accès confus.

4) La couche d’identité : SIDs, UIDs, et l’art de ne pas les changer

Windows utilise des SIDs. ZFS sur un système de type UNIX applique finalement l’accès en utilisant des UIDs/GIDs. Samba fait le pont via idmap. Si votre configuration idmap change
(ou votre relation de confiance de domaine change), le même SID utilisateur peut se mapper à un UID différent, ou ne plus se mapper du tout. Vos entrées ACL référencent toujours des identités, mais
elles ne correspondent plus à l’utilisateur sur le réseau.

C’est là que naît le « les permissions ont changé aléatoirement ». Rien d’aléatoire ne s’est produit. Vous avez déplacé la règle.

Blague n°1 : Les bugs de permissions sont comme le paillettes — une fois entrés dans l’organisation, vous en trouverez partout où personne ne se souvient avoir touché.

5) Entrées « deny » et ordre : pourquoi les admins Windows peuvent briquer l’accès instantanément

L’évaluation des ACL Windows inclut une sémantique explicite de deny. Les ACL NFSv4 peuvent aussi exprimer des entrées deny. Mais il faut toujours être prudent avec les denies hérités
et la règle « qui possède le fichier ». Si un dossier a un deny sur un groupe large, l’héritage peut propager ce deny aux fichiers d’une manière qui surprend les gens habitués à « on va juste ajouter un allow ».

Expliquez à vos administrateurs : évitez le deny sauf si vous bloquez activement quelque chose et pouvez expliquer l’ordre d’évaluation. La plupart des denies sont de la politique exprimée comme
du sabotage.

Choisissez votre stratégie de permissions (et engagez-vous)

Stratégie A : Windows-first (recommandé pour environnements fortement SMB)

Utilisez ZFS acltype=nfsv4. Gérez les permissions depuis Windows (Explorateur, icacls) et laissez Samba écrire les ACL. Éloignez les chmod/chown côté Linux des
datasets « possédés par Windows », ou au moins contraignez-les à des automatisations contrôlées qui respectent les propriétés ACL.

Vous avez toujours besoin d’un propriétaire/groupe UNIX pour la compatibilité POSIX, mais considérez les bits de mode comme une vue de compatibilité, pas comme la source de vérité.

Stratégie B : UNIX-first avec accès SMB (fonctionne, mais vous traduirez)

Si l’administration se fait majoritairement sur Linux et que les clients Windows sont des consommateurs, les ACL POSIX peuvent convenir. Mais vous devez accepter : les éditions via l’UI Windows ne
se comporteront pas toujours de façon intuitive. Vous gérerez plus de conversations « pourquoi je ne peux pas définir cette permission ».

Stratégie C : administration mixte des deux côtés (à éviter)

C’est ainsi que vous obtenez la dérive des permissions. Un administrateur Windows définit une ACL héritée complexe. Un administrateur Linux lance un chmod récursif parce que « ça avait l’air faux ».
Résultat : un dataset plein d’intentions à moitié préservées et beaucoup de nouveaux tickets.

Playbook de diagnostic rapide

Quand quelqu’un signale « permission SMB refusée » ou « accès changé », ne commencez pas par cliquer dans l’Explorateur. Commencez par une courte séquence qui isole
où la défaillance se situe : identité, restrictions de partage, ACL du système de fichiers, ou dérive d’héritage.

Première étape : identité et mappage (la plus courante, la plus catastrophique)

1. Confirmez que le SID de l’utilisateur se mappe au UID/GID attendu sur le serveur.
2. Confirmez que l’appartenance aux groupes est visible par Samba (le token contient les bons groupes).
3. Confirmez que le backend idmap et les plages n’ont pas changé.

Deuxième étape : restrictions au niveau SMB

1. Vérifiez la configuration du partage : valid users, read only, write list, inherit permissions, fichiers veto, etc.
2. Vérifiez si le client se connecte avec le compte attendu (les identifiants mis en cache sont classiques).

Troisième étape : ACL du système de fichiers + propriétés ZFS

1. Inspectez les propriétés du dataset ZFS : acltype, aclmode, aclinherit, xattr, casesensitivity.
2. Inspectez l’ACL du fichier/répertoire depuis le serveur, pas seulement depuis Windows.
3. Vérifiez les entrées deny explicites et les drapeaux d’héritage cassés.

Quatrième étape : l’enquête « quelqu’un a lancé chmod »

1. Recherchez des changements récents : diffs de snapshot, journaux d’audit si activés, snapshots ZFS, ou motifs de mtime.
2. Identifiez si les ACL ont été supprimées ou réécrites par chmod/chown ou par un outil de migration.

Tâches pratiques : commandes, sorties, décisions

Voici les tâches que j’exécute réellement lors du débogage du mappage ZFS + SMB ACL. Chaque tâche inclut une commande réaliste, un exemple de ce qui ressemble à « bon » ou « mauvais »
et la décision suivante à prendre.

Task 1: Identify dataset and mountpoint

cr0x@server:~$ zfs list -o name,mountpoint,acltype,aclmode,aclinherit,xattr,casesensitivity tank/share
NAME        MOUNTPOINT    ACLTYPE  ACLMODE    ACLINHERIT  XATTR  CASESENSITIVITY
tank/share  /tank/share   nfsv4    restricted passthrough sa     insensitive

Ce que cela signifie : Vous êtes sur des ACL NFSv4, chmod est restreint pour ne pas écraser les ACL, l’héritage passe à travers, xattrs stockés en SA, comportement insensible à la casse comme Windows.

Décision : Ce dataset est vraisemblablement configuré pour des ACL orientées SMB. Passez aux vérifications d’identité et d’ACL effectives plutôt que de changer les propriétés.

Task 2: Confirm Samba share definition actually points here

cr0x@server:~$ testparm -s | sed -n '/^\[share\]/,/^\[/{p}'
[share]
	path = /tank/share
	read only = No
	vfs objects = zfsacl streams_xattr
	inherit acls = Yes
	store dos attributes = Yes

Ce que cela signifie : Le chemin du partage correspond au point de montage du dataset. Le module VFS conscient des ACL ZFS est activé. Les attributs DOS sont stockés comme xattrs.

Décision : Si vfs objects n’inclut pas zfsacl (ou l’équivalent de votre plateforme), le mappage peut être dégradé. Corrigez la config Samba avant de toucher aux ACL.

Task 3: See what user Samba thinks you are (and your groups)

cr0x@server:~$ wbinfo --user-sid 'EXAMPLE\alice'
S-1-5-21-111111111-222222222-333333333-1107

Ce que cela signifie : L’utilisateur de domaine se résout en un SID. Si cela échoue, vous n’avez pas un problème d’ACL — vous avez un problème de services d’annuaire.

Décision : Si cela échoue, arrêtez et corrigez le join de domaine / winbind / trust avant toute autre chose.

Task 4: Map SID to UNIX ID and verify it is stable

cr0x@server:~$ wbinfo --sid-to-uid S-1-5-21-111111111-222222222-333333333-1107
2001107

Ce que cela signifie : Samba mappe le SID vers l’UID 2001107. Cet UID est ce que l’application de l’ACL sur le système de fichiers considère en fin de compte.

Décision : Si le mappage a changé récemment, les entrées ACL référencant l’ancien UID ne correspondront plus. Enquêtez sur le backend/ranges idmap et si un autre serveur émet des mappages différents.

Task 5: Check idmap configuration from Samba’s perspective

cr0x@server:~$ testparm -s | grep -E '^idmap config|^security|^realm'
security = ADS
realm = EXAMPLE.COM
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config EXAMPLE : backend = rid
idmap config EXAMPLE : range = 2000000-2999999

Ce que cela signifie : Le domaine EXAMPLE utilise le mapping RID dans une plage UID spécifique. Cela tend à être stable si vous gardez la plage cohérente entre serveurs.

Décision : Assurez-vous que chaque serveur SMB accédant au même dataset ZFS utilise le même backend idmap et les mêmes plages. Sinon, vous êtes assuré d’obtenir des discordances dans les identités stockées sur disque.

Task 6: Validate the user token includes expected groups

cr0x@server:~$ wbinfo --user-groups 'EXAMPLE\alice' | head
S-1-5-21-111111111-222222222-333333333-513
S-1-5-21-111111111-222222222-333333333-2201
S-1-5-21-111111111-222222222-333333333-2209

Ce que cela signifie : Ce sont des SIDs de groupes dans la liste d’appartenance de l’utilisateur.

Décision : Si une permission devrait provenir d’un groupe mais que le SID du groupe n’est pas présent, vous regardez du côté de l’appartenance au répertoire, du rafraîchissement du token, de la visibilité des groupes imbriqués, ou du cache winbind — pas ZFS.

Task 7: Inspect ACL on a directory from the server (NFSv4 style)

cr0x@server:~$ ls -V /tank/share/Projects
drwxrwx---+  15 root  domain_users  15 Dec 26 10:12 /tank/share/Projects
                owner@:rwxpDdaARWcCos:fd-----:allow
                group@:rwxpDdaARWcCos:fd-----:allow
             everyone@:------a-R-c--s:fd-----:allow

Ce que cela signifie : Le + indique une ACL au-delà des bits de mode. Les drapeaux d’héritage (f, d) sont présents pour fichiers/répertoires. Cela ressemble à une base contrôlée.

Décision : Si vous ne voyez pas les drapeaux d’héritage sur des répertoires où vous les attendez, vous avez probablement un problème de configuration d’héritage ou une réinitialisation d’ACL a été effectuée.

Task 8: Confirm the Windows view matches (from Samba tooling)

cr0x@server:~$ smbcacls //localhost/share Projects -U 'EXAMPLE\alice'
REVISION:1
CONTROL:SR|DP
OWNER:EXAMPLE\Administrator
GROUP:EXAMPLE\Domain Users
ACL:EXAMPLE\Domain Admins:ALLOWED/0x0/FULL
ACL:EXAMPLE\Project Team:ALLOWED/0x0/CHANGE
ACL:EXAMPLE\Domain Users:ALLOWED/0x0/READ

Ce que cela signifie : Samba peut présenter une ACL Windows cohérente aux clients.

Décision : Si cela diffère fortement de ls -V, le mappage peut être dégradé, ou vous regardez des objets différents (mauvais chemin), ou votre module VFS n’est pas actif.

Task 9: Check effective access for a specific identity (server-side)

cr0x@server:~$ id EXAMPLE\\alice
uid=2001107(alice) gid=2000513(domain_users) groups=2000513(domain_users),2002201(project_team)

cr0x@server:~$ sudo -u '#2001107' test -w /tank/share/Projects && echo WRITABLE || echo NOT_WRITABLE
WRITABLE

Ce que cela signifie : Le serveur croit qu’Alice peut écrire. Cela isole le « le système de fichiers dit oui » du « SMB dit non ».

Décision : Si le système de fichiers dit WRITABLE mais que les clients SMB se voient refuser l’accès, examinez les restrictions au niveau du partage, la config Samba, les oplocks, les veto, ou les authentifications/identifiants mis en cache du client.

Task 10: Detect whether POSIX mode bits are being used as a gate

cr0x@server:~$ stat -c '%A %a %U %G %n' /tank/share/Projects
drwxrwx--- 770 root domain_users /tank/share/Projects

Ce que cela signifie : Les bits de mode sont 770. Si votre ACL prévoit un accès plus large mais que « other » est à 0, certains outils peuvent encore être contraints selon les réglages ACL et le chemin d’évaluation.

Décision : Si les utilisateurs Windows se voient refuser l’accès et que les bits de mode sont trop restrictifs, confirmez le comportement de aclmode et de aclinherit et assurez-vous que l’ACL inclut les entrées allow nécessaires. Ne faites pas aveuglément un chmod 777.

Task 11: Verify dataset ACL behavior knobs (the ones people forget exist)

cr0x@server:~$ zfs get -H -o property,value acltype,aclmode,aclinherit,xattr tank/share
acltype	nfsv4
aclmode	restricted
aclinherit	passthrough
xattr	sa

Ce que cela signifie : Cette combinaison préserve généralement l’intention Windows. restricted empêche chmod d’écraser les ACL. passthrough conserve les ACE telles quelles pour l’héritage.

Décision : Si vous voyez aclmode=discard ou aclinherit=discard sur un dataset SMB, c’est une bombe à retardement de permissions. Corrigez les propriétés, puis réparez les ACL.

Task 12: Find explicit deny entries that block everything

cr0x@server:~$ ls -V /tank/share/Projects/Quarterly
drwxrwx---+  10 root  domain_users  10 Dec 26 10:18 /tank/share/Projects/Quarterly
                owner@:rwxpDdaARWcCos:fd-----:allow
                group@:rwxpDdaARWcCos:fd-----:allow
        project_team@:------a-R-c--s:fd-----:deny

Ce que cela signifie : Il y a un deny explicite pour project_team@. Si vos rédacteurs sont dans ce groupe, ils sont bloqués indépendamment des autres allow.

Décision : Supprimez ou restreignez l’entrée deny. Dans la plupart des arborescences d’entreprise, les denies servent de « politique », et la politique appartient à l’appartenance aux groupes, pas à une grenade deny héritée.

Task 13: Prove inheritance is (or isn’t) happening for new files

cr0x@server:~$ sudo -u '#2001107' touch /tank/share/Projects/inheritance_test.txt

cr0x@server:~$ ls -V /tank/share/Projects/inheritance_test.txt
-rw-rw----+  1 alice  domain_users  0 Dec 26 10:20 /tank/share/Projects/inheritance_test.txt
                owner@:rw-p--aARWcCos:------:allow
                group@:rw-p--aARWcCos:------:allow
             everyone@:------a-R-c--s:------:allow

Ce que cela signifie : Le fichier a hérité d’un modèle d’ACL sensé. S’il ne l’avait pas fait, vous verriez des entrées manquantes ou des drapeaux différents.

Décision : Si les nouveaux fichiers ont des ACL « incorrectes », vérifiez aclinherit, inherit acls dans Samba, et si Windows applique un ACL parent différent de celui que vous pensez.

Task 14: Detect xattr storage mode and whether you’re paying metadata tax

cr0x@server:~$ zfs get -H -o property,value xattr tank/share
xattr	sa

Ce que cela signifie : xattr=sa stocke les petits xattrs dans la zone « system attributes » du dnode, réduisant les I/O séparés pour les charges SMB riches en métadonnées.

Décision : Si vous observez de mauvaises performances métadonnées et xattr=on, envisagez de passer à sa pour les nouveaux datasets (le changer sur des datasets existants peut avoir des implications ; planifiez soigneusement).

Task 15: Validate Samba sees the ZFS ACL module loaded

cr0x@server:~$ smbstatus -b | head -n 15
Samba version 4.19.5
PID     Username     Group        Machine
-------------------------------------------------------------------
4123    alice        domain_users  10.20.30.40 (ipv4:10.20.30.40:52514)

Service      pid     Machine       Connected at
-------------------------------------------------------
share        4123    10.20.30.40    Wed Dec 26 10:21:14 2025

Locked files:
No locked files

Ce que cela signifie : Une session SMB active existe ; vous pouvez corréler le comportement du client avec les logs serveur et les vérifications du système de fichiers.

Décision : S’il n’y a pas de sessions, votre problème peut être d’authentification/connectivité, pas de permissions de fichier. Ne « corrigez » pas les ACL pour un problème de connexion.

Task 16: Correlate a client denial with Samba logs (surgical logging)

cr0x@server:~$ sudo smbcontrol all debug 3

cr0x@server:~$ sudo tail -n 30 /var/log/samba/log.smbd
[2025/12/26 10:22:03.114820,  3] smbd/open.c:5963(open_file)
  open_file: unable to open file Projects/Quarterly/report.xlsx. Error was NT_STATUS_ACCESS_DENIED

Ce que cela signifie : Samba refuse à l’ouverture. Cela vous oriente vers l’évaluation des ACL du système de fichiers ou vers des restrictions de partage.

Décision : Si le refus est cohérent pour un chemin, inspectez l’ACL de ce chemin pour un deny explicite ou des problèmes de propriété, et confirmez les groupes du token utilisateur.

Trois mini-récits d’entreprise issus des tranchées des permissions

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a migré d’un serveur de fichiers Windows vers un cluster SMB sur ZFS tout neuf. Le plan semblait simple : copier les données, garder les permissions, basculer.
Le chef de projet a posé une question : « Les ACL Windows vont-elles juste se mapper ? » La réponse qu’ils ont obtenue était « Oui, en grande partie. »

Le jour de la bascule, le helpdesk a été submergé. Certaines équipes pouvaient lire mais pas écrire. D’autres pouvaient écrire mais pas renommer. Quelques responsables de service
ont découvert qu’ils étaient « propriétaire » sur des dossiers aléatoires qu’ils ne reconnaissaient pas, ce qui est un excellent moyen de rendre les gens nerveux pour un audit non sollicité.

La cause racine n’était pas que ZFS soit étrange. C’était l’hypothèse que le mappage d’identités était universel entre serveurs. L’ancien serveur Windows avait des SIDs stables.
La nouvelle configuration Samba utilisait un backend idmap différent sur un nœud par rapport aux autres. Même domaine, mêmes utilisateurs, assignations UID/GID différentes selon le nœud SMB qui traitait la requête.

Le pire : les ACL sur disque étaient « correctes » du point de vue du nœud qui les avait écrites. Elles étaient absurdes du point de vue de l’autre nœud.
Cela ressemblait à une défaillance aléatoire car cela dépendait du placement de la connexion.

Ils ont corrigé le problème en standardisant le backend idmap et les plages sur le cluster, puis en réécrivant la propriété des ACL pour correspondre aux mappages stables. Le temps d’arrêt a été mesuré
en heures. Le nettoyage a pris des semaines parce que la confiance a été la vraie victime.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait une plainte de performance : l’affichage des répertoires via SMB était lent aux heures de pointe. Quelqu’un a regardé les graphiques, vu la pression métadonnée, et
décidé de « simplifier » les permissions. L’idée : réduire la complexité des ACL en les regroupant en groupes larges, supprimer le « bruit » d’héritage, et définir
aclinherit=discard pour éviter d’écrire des entrées héritées supplémentaires.

Pendant environ deux jours, tout le monde était ravi. Les nouveaux fichiers se créaient rapidement. Les listings de répertoires s’accéléraient. La personne à l’origine de la suggestion a reçu un hochement de tête tacite
de la direction, ce qui en milieu d’entreprise équivaut à un défilé.

Puis les équipes projet ont remarqué quelque chose : les nouveaux fichiers n’héritaent plus des accès attendus pour les groupes transverses. Les gens ont recommencé à s’envoyer des documents par mail
parce que « le partage est cassé ». C’est ainsi que vous savez que vous perdez : quand les utilisateurs inventent une solution de contournement qui pourrit aussi la gouvernance.

Le retour de bâton était subtil. En supprimant l’héritage, ils ont forcé les permissions à dépendre des modes par défaut et de ce que Samba choisissait au moment de la création. Le résultat
a été des ACL incohérentes selon l’application cliente et la façon dont elle créait les fichiers. Certaines applications créaient des fichiers temporaires avec des descripteurs de sécurité différents des fichiers finaux.
Sans héritage pour corriger, les bizarreries demeuraient.

La correction n’a rien d’ostentatoire : revenir à aclinherit=passthrough, établir une ACL de base propre sur les racines, et améliorer la performance en traitant correctement la métadonnée
(stratégie xattr, choix de recordsize, et ne pas faire de chirurgie ACL récursive à 9 h).

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise a exploité un service SMB sur ZFS pendant des années avec un minimum de drame. Leur secret n’était pas une configuration magique. C’était la discipline : un seul « root ACL »
par partage, des noms de groupes standardisés, et une règle que seuls les outils Windows définissent les ACL sur les partages de production. L’automatisation Linux pouvait créer des répertoires,
mais elle n’avait pas le droit de lancer un chmod récursif. Jamais.

Un jour, une restructuration de domaine a eu lieu. Nouveaux groupes, groupes retirés, changements d’appartenance imbriquée. C’est le genre de changement qui transforme habituellement les partages de fichiers
en art abstrait. Ils s’attendaient à des tickets.

Aucun ticket n’est arrivé. Pourquoi ? Ils avaient un job nocturne qui validait la cohérence du mappage d’identités et signalait les entrées « SID inconnu » avant que des humains ne s’en aperçoivent.
Ils snapshottaient aussi les datasets de manière agressive et pouvaient diffuer les changements d’ACL quand quelque chose sentait le roussi.

Pendant la restructuration, leur monitoring a signalé qu’un sous-ensemble de SIDs de groupe avait cessé de se résoudre sur un nœud SMB. Ils ont drainé les connexions de ce nœud,
réparé la connectivité winbind, et l’ont remis en ligne. La plupart des utilisateurs ne l’ont jamais senti.

C’était du travail ennuyeux. Le meilleur genre. Quand quelqu’un a demandé pourquoi ils s’embêtent avec des « contrôles de santé des permissions », la réponse était simple : parce que l’alternative
est d’apprendre les ACL pendant une panne, ce qui revient à apprendre à nager pendant une inondation.

Blague n°2 : La seule chose plus persistante qu’un mappage SID périmé est la personne qui insiste « les permissions sont faciles » parce qu’elle a déjà lancé chmod -R.

Erreurs courantes : symptômes → cause → correction

1) Symptôme : « Ça marche sur un nœud SMB, échoue sur un autre »

Cause racine : Backend idmap/plages incohérents entre nœuds ; SID→UID diffère par nœud.

Correction : Standardisez la config idmap partout. Validez avec wbinfo --sid-to-uid sur chaque nœud. Ensuite seulement, envisagez la réparation des ACL.

2) Symptôme : « Les nouveaux fichiers n’héritent pas des permissions du dossier »

Cause racine : aclinherit=discard/restricted mismatch, ou paramètres d’héritage Samba désactivés, ou ACL parent sans drapeaux d’héritage.

Correction : Utilisez aclinherit=passthrough (ou votre politique cohérente), assurez inherit acls = yes, et réinitialisez l’ACL parent pour inclure les drapeaux d’héritage appropriés.

3) Symptôme : « Un chmod Linux a réparé… puis tout a cassé ensuite »

Cause racine : chmod/chown a interagi avec les ACL via aclmode et a supprimé ou réécrit des entrées. Ou cela a changé la propriété et invalidé une ACE ciblée.

Correction : Définissez aclmode=restricted pour les datasets orientés SMB. Arrêtez d’utiliser chmod récursif sur les partages de production. Réappliquez la baseline ACL depuis un modèle connu bon.

4) Symptôme : « Tout le monde a la lecture, mais les rédacteurs ne peuvent pas renommer/supprimer »

Cause racine : Permissions de répertoire manquantes comme delete/rename (ou leurs équivalents NFSv4). Sous Windows, la suppression implique des permissions sur le répertoire parent.

Correction : Assurez-vous que le groupe de rédaction a les droits de modification/changement sur le répertoire, pas seulement l’écriture de fichier. Validez en testant création, renommage, suppression depuis SMB et côté serveur.

5) Symptôme : « Le propriétaire apparaît comme un SID inconnu sous Windows »

Cause racine : Le SID ne se résout plus (groupe supprimé/renommé sans persistance de SID), ou le serveur ne peut pas contacter les contrôleurs de domaine, ou le cache idmap est périmé/cassé.

Correction : Rétablissez la connectivité des services d’annuaire, videz/rafraîchissez les caches winbind avec précaution, et évitez de réécrire les ACL tant que les identités ne se résolvent pas de nouveau.

6) Symptôme : « Un sous-ensemble d’utilisateurs obtient Access Denied après des changements de domaine »

Cause racine : Changements d’appartenance non reflétés à cause du cache de token, limites d’évaluation des groupes imbriqués, ou winbind ne voyant pas les mises à jour d’appartenance.

Correction : Validez les SIDs de groupes dans le token avec wbinfo --user-groups. Ajustez les paramètres de répertoire/Samba pour les groupes imbriqués si nécessaire ; demandez aux utilisateurs de se reconnecter/se déconnecter pour rafraîchir les tokens.

7) Symptôme : « Windows dit que j’ai le contrôle total mais c’est quand même refusé »

Cause racine : Restrictions au niveau du partage (valid users, write list), ou chemin du système de fichiers incorrect (symlinks, bind mounts), ou deny explicite plus haut dans l’arborescence.

Correction : Vérifiez la config du partage avec testparm. Confirmez le chemin exact. Inspectez les ACL des répertoires parents et cherchez des entrées deny.

8) Symptôme : « Après migration des données, les permissions semblent aplaties »

Cause racine : L’outil de migration n’a pas préservé les ACL (ou a traduit en bits de mode POSIX), ou a copié en tant que root sans préserver les xattrs/ACLs.

Correction : Re-migrez avec une méthode qui préserve les ACL adaptée à votre plateforme, ou restaurez depuis un snapshot. Puis verrouillez la stratégie pour que cela ne se reproduise pas.

Listes de contrôle / plan étape par étape

Checklist 1: Construire un nouveau partage SMB sur ZFS sans regrets futurs

1. Créez un dataset dédié par partage. Ne mettez pas tout dans un seul dataset en espérant que ça ira.
2. Définissez explicitement les propriétés du dataset : acltype=nfsv4, un aclmode délibéré, un aclinherit choisi, et un choix de sensibilité à la casse aligné avec les clients Windows.
3. Choisissez une stratégie idmap et standardisez-la sur tous les nœuds SMB qui touchent les données.
4. Configurez Samba avec les modules VFS conscients des ACL ZFS et activez le comportement d’héritage ACL que vous voulez réellement.
5. Définissez une ACL racine unique dans Windows, validez l’héritage en créant des fichiers de test depuis plusieurs applications clientes.
6. Faites un snapshot avant de le remettre aux vrais utilisateurs. Vous voulez une porte de sortie avant que la « permission créative » ne commence.

Checklist 2: Réponse à un incident de permissions (30–60 minutes)

1. Identifiez le chemin exact et un utilisateur affecté. Pas « plein de gens ». Une identité. Un objet.
2. Confirmez le mappage SID→UID de l’utilisateur sur le nœud SMB qui gère la session.
3. Vérifiez les restrictions au niveau du partage dans Samba et confirmez que l’utilisateur se connecte avec le compte attendu.
4. Inspectez l’ACL serveur sur le répertoire et le fichier ; cherchez des denies explicites et des drapeaux d’héritage manquants.
5. Testez l’écriture effective côté serveur avec sudo -u '#UID' test -w.
6. Si nécessaire, augmentez brièvement le debug Samba et corrélez un événement NT_STATUS_ACCESS_DENIED avec le chemin.
7. Réparez la plus petite chose qui restaure la correction (souvent le mappage d’identités ou une seule ACE fautive), puis désactivez le debug.

Checklist 3: Prévenir la dérive des permissions (continu)

1. Déclarez une seule source de vérité pour les changements d’ACL (outils côté Windows pour les datasets SMB-first).
2. Interdisez le chmod récursif sur les partages de production ; faites respecter via des garde-fous d’automatisation et revue par les pairs.
3. Standardisez le backend idmap/plages sur tous les nœuds ; traitez les changements comme un projet de migration, pas comme un réglage.
4. Snapshottez régulièrement ; gardez au moins un snapshot « baseline ACL connue bonne » pour un rollback/diff rapide.
5. Surveillez les SIDs non mappés et les échecs de traduction SID→UID ; alertez tôt.

FAQ

1) Dois-je utiliser acltype=nfsv4 pour les partages SMB ?

Oui, pour les partages SMB centrés Windows. Cela correspond beaucoup mieux à la sémantique des ACL Windows que les ACL POSIX et réduit les « surprises de traduction ».

2) Pourquoi je vois des bits de mode (770) si les ACL sont le contrôle réel ?

Parce qu’UNIX a toujours un champ de mode, et de nombreux outils l’affichent. Selon aclmode, chmod peut ou non réécrire les ACL pour faire correspondre. Considérez les bits de mode
comme des métadonnées de compatibilité sauf si vous avez volontairement choisi une politique centrée sur les modes.

3) Quelle est la différence entre aclmode=restricted et aclmode=discard ?

restricted a tendance à préserver l’intention des ACL quand chmod est utilisé. discard peut supprimer les ACL quand les bits de mode changent. Pour les datasets SMB, discard
est la manière dont vous transformez accidentellement un modèle de permissions nuancé en décombres.

4) Pourquoi les permissions changent selon le serveur SMB contacté ?

Presque toujours une configuration idmap incohérente. Le même SID se mappe à des UIDs différents sur des nœuds différents, donc les entrées ACL sur disque correspondent sur un nœud et pas sur un autre.

5) Puis-je lancer chown -R en sécurité sur un dataset SMB ?

« En sécurité » demande beaucoup de contexte. Les changements de propriété récursifs peuvent invalider la sémantique des ACL (surtout owner@ et group@) et surprendre Windows.
Si vous devez le faire, snapshottez d’abord, testez sur un clone, et comprenez votre modèle d’ACL.

6) Ai-je besoin de vfs_zfsacl (ou équivalent) dans Samba ?

Si vous voulez un comportement correct des ACL NFSv4/ZFS exposé aux clients Windows, oui. Sans cela, Samba peut retomber sur une gestion ACL générique et vous verrez des drapeaux manquants,
un héritage cassé, ou des bizarreries dans l’UI Windows.

7) Pourquoi un utilisateur peut créer un fichier mais pas le supprimer ?

La suppression est souvent contrôlée par les permissions sur le répertoire parent (et la sémantique Windows de suppression est subtile). Assurez-vous que l’utilisateur/groupe a les droits de modification
sur le répertoire, pas seulement l’écriture de fichier.

8) Pourquoi je vois des entrées « SID inconnu » dans les ACL ?

Le serveur ne peut pas résoudre ce SID en nom, généralement à cause de problèmes de connectivité aux services d’annuaire, de principaux supprimés, de problèmes de trust, ou d’un cache idmap cassé.
Réparez la résolution d’identité avant de réécrire les ACL, sinon vous inscrirez des identités erronées dans les ACL.

9) xattr=sa est-il toujours mieux pour SMB ?

Souvent mieux pour les charges SMB riches en métadonnées car cela réduit les I/O séparés pour les xattrs. Mais c’est un choix de conception — validez sur votre plateforme, et soyez prudent en changeant cela
sur des datasets existants sans plan.

10) Quelle est la manière la plus simple de garder des permissions saines ?

Un dataset par partage, acltype=nfsv4, idmap cohérent partout, gérez les ACL depuis Windows, et éloignez le chmod Linux de l’arborescence. L’ennuyeux l’emporte.

Prochaines étapes réalisables cette semaine

Si vos permissions SMB sur ZFS vous semblent hantées, ne chassez pas des fantômes. Choisissez un modèle propre, puis faites-le respecter par la configuration et les habitudes.

1. Inventoriez vos datasets SMB : enregistrez acltype, aclmode, aclinherit, xattr, et la sensibilité à la casse. Corrigez d’abord les bombes à retardement évidentes.
2. Standardisez idmap sur chaque nœud SMB qui touche le même stockage. Traitez les changements comme des migrations. « Juste une petite modification » est la façon dont les ACL deviennent de la fiction historique.
3. Définissez une baseline ACL à la racine de chaque partage, validez l’héritage avec de vraies applications clientes, et snapshottez la baseline.
4. Mettez le playbook de diagnostic rapide quelque part que votre on-call peut trouver à 2 h du matin. Vous, futur, serez fatigué et pas disposé à réapprendre le mappage d’identités.

Les cauchemars de permissions ne sont pas causés par une seule mauvaise case cochée. Ils sont causés par une vision incohérente. Rendre cette vision cohérente — et soudain votre serveur de fichiers redevient ennuyeux.
C’est l’objectif.