ZFS acltype : ACL POSIX vs NFSv4 sans confusion

décembre 16, 2025 • février 3, 2026 • Lecture : 29 min • Views: 8

Cet article vous a aidé ?

Si vous avez exploité ZFS en production suffisamment longtemps, vous avez vu les permissions devenir une expérience sociale : un administrateur « corrige » l’accès avec chmod -R, un utilisateur Windows modifie une ACL dans Explorer, un client NFS met quelque chose en cache « utilement », et soudainement le support fond tandis que l’équipe stockage affirme « ZFS fonctionne ». ZFS est souvent correct. C’est notre modèle mental qui est cassé.

Cet article reconstruit ce modèle mental pour les personnes qui mettent des systèmes en production : ce que acltype signifie réellement, en quoi les ACL POSIX diffèrent des ACL NFSv4 sur des points importants, comment SMB et NFS se comportent, quoi définir sur de nouveaux datasets, et comment dépanner un inévitable « Permission denied » en minutes plutôt qu’en heures.

La décision que vous prenez vraiment

Sur ZFS, acltype n’est pas une préférence cosmétique. C’est une déclaration du langage de permissions que le dataset parlera nativement et des sémantiques que ZFS préservera lorsque vous faites des opérations comme chmod, chown, ou créez de nouveaux fichiers dans des répertoires avec des ACL héritées.

En termes simples :

ACL POSIX étendent les bits de mode UNIX classiques et les utilisateurs/groupes avec un modèle familier. Elles sont excellentes pour les flux Linux/Unix, l’automatisation, et pour « ce que vous voyez dans ls -l est essentiellement l’histoire ». Mais le mask, les ACL par défaut et les règles d’héritage limitées surprennent régulièrement les gens.
ACL NFSv4 sont plus riches, plus proches des sémantiques Windows, et possèdent des flags d’héritage explicites. Elles se mappent mieux à SMB, aux environnements mixtes, et aux attentes d’un « vrai serveur de fichiers d’entreprise ». Elles offrent aussi plus de façons de se tromper — plus d’expressivité signifie plus de mauvaises combinaisons possibles.

La meilleure façon de choisir n’est pas « qu’est-ce que j’aime ? » mais « quel écosystème client doit être la source de vérité ? » Si SMB/Windows est votre plan de contrôle, les ACL NFSv4 réduisent le décalage. Si l’automatisation Linux et la simplicité des bits de mode sont votre plan de contrôle, les ACL POSIX garderont votre vie d’astreinte plus calme.

Une blague, parce qu’on l’a méritée : les ACL POSIX sont comme un couteau suisse — simples, pratiques, et vous finirez par vous couper si vous oubliez que le mask existe.

Faits et historique qui expliquent le bazar actuel

Les permissions sont de l’histoire politique encodée dans les noyaux. Quelques points de contexte aident à expliquer pourquoi ZFS finit par sembler « mystique » ici.

Les permissions UNIX classiques précèdent les réseaux. Les bits owner/group/other ont été conçus pour le partage multi-utilisateur dans le temps, pas pour l’identité cross-domain ou les éditeurs ACL en GUI.
Les ACL POSIX sont un correctif pragmatique. Elles ont étendu le modèle des bits de mode sans le remplacer, d’où l’existence du mask : il préserve l’idée que les bits de mode comptent toujours.
Les ACL NFSv4 ont été conçues pour les systèmes de fichiers en réseau. Elles incluent des utilisateurs/groupes nommés, des sémantiques allow/deny plus riches et des flags d’héritage qui se comportent davantage comme Windows.
Les ACL Windows ont influencé la conception des ACL NFSv4. Pas identiques, mais suffisamment similaires pour que le mapping soit faisable — important pour les serveurs SMB reposant sur ZFS.
Les ACE « deny » ne sont pas une tradition UNIX. En NFSv4, les entrées deny peuvent court-circuiter les règles allow selon l’ordre et le modèle d’évaluation ; en POSIX ACLs, il n’y a pas vraiment d’équivalent.
SMB a toujours tenu à la fidélité des ACL. Les clients Windows attendent l’héritage, les flags explicites vs hérités, et des sémantiques stables lors de la modification des permissions via l’interface graphique.
ZFS ciblait à l’origine les charges Solaris d’entreprise. L’attente était des clients mixtes, un stockage centralisé, et des fonctions métadonnées avancées — y compris le support des ACL qui n’était pas une réflexion après coup.
Les outils Linux ont évolué autour des ACL POSIX. getfacl/setfacl sont omniprésents, et les opérateurs s’attendent à ce qu’ils fonctionnent partout, même lorsque le système de fichiers sous-jacent parle des ACL NFSv4.
Le mappage d’identité est une autre guerre. Les ACL peuvent être parfaites ; si votre mappage UID/GID/SID est incorrect, les permissions échoueront quand même. Beaucoup de « bugs ACL ZFS » sont en réalité des bugs des services d’annuaire.

Propriétés ZFS qui contrôlent la réalité des ACL

acltype n’est qu’un bouton. La combinaison des propriétés d’ACL détermine comment ZFS stocke les ACL, comment il traite chmod/chown, et comment l’héritage est appliqué.

acltype

Qu’est-ce que c’est : Le modèle d’ACL utilisé pour le dataset. Les valeurs courantes dépendent de la plateforme :

POSIX : souvent représenté comme posixacl sur les implémentations ZFS Linux.
NFSv4 : souvent représenté comme nfsv4.

Ce que ça change : La façon dont les ACL sont interprétées et quels outils/sémantiques se comportent nativement. Cela affecte aussi la manière dont les serveurs SMB peuvent présenter et stocker les ACL.

aclmode

Qu’est-ce que c’est : Ce que ZFS fait lorsque vous lancez chmod sur un fichier qui possède une ACL. C’est la source numéro un des « chmod n’a pas fait ce que je pensais ».

Comportements typiques (les noms varient selon la plateforme, mais les sémantiques tiennent) :

discard : jeter les entrées ACL qui ne correspondent pas au nouveau mode. Dangereux pour des environnements ACL riches.
groupmask : maintenir les ACL mais traiter les permissions du groupe de manière conservative selon les bits de mode (défaut courant dans certains environnements).
passthrough : laisser chmod ajuster les bits de mode sans essayer de « corriger » les ACL. Souvent préférable si vous gérez explicitement les ACL et ne voulez pas que chmod les réécrive.
restricted : empêcher chmod de rendre les ACL plus permissives qu’elles ne l’étaient. Bon pour la sécurité ; surprenant pour les moments « je suis root, pourquoi je ne peux pas ? ».

aclinherit

Qu’est-ce que c’est : Comment les ACL sur les répertoires sont héritées par les nouveaux fichiers/répertoires créés à l’intérieur.

C’est là que les ACL NFSv4 brillent : elles ont des flags d’héritage explicites, donc vous pouvez obtenir des résultats prévisibles « ce dossier se comporte comme un partage Windows ». POSIX peut le faire avec des ACL par défaut, mais c’est moins expressif et facile à mal appliquer.

xattr et sa

Les ACL vivent généralement dans les attributs étendus. ZFS peut stocker les xattrs dans des « system attributes » (SA) pour les performances (xattr=sa sur de nombreux systèmes). C’est un vrai gain de performance pour les charges lourdes en métadonnées — mais ça ne simplifie pas les permissions, et ça peut affecter la réplication et la compatibilité.

sensibilité à la casse et normalisation

Ce n’est pas une propriété d’ACL, mais si vous mélangez des clients Windows et Unix, casesensitivity et la normalisation Unicode peuvent déclencher des confusions d’accès qui ressemblent à des problèmes de permissions. Vous jurerez qu’un utilisateur « a accès » mais qu’il atteint un chemin différent de celui que vous avez audité.

ACL POSIX vs NFSv4 : différences pratiques

Modèle mental : ce que « permission » signifie

ACL POSIX répondent : « Étant donné un utilisateur propriétaire, un groupe propriétaire, des bits de mode, et des entrées utilisateur/groupe optionnelles, cette opération est-elle autorisée ? » Le mask POSIX limite effectivement les permissions des utilisateurs/groupes nommés et de la classe groupe. Si vous oubliez le mask, vous auditez mal l’accès.

ACL NFSv4 répondent : « Étant donné une liste ordonnée d’entrées de contrôle d’accès (ACE) avec allow/deny et des droits riches, plus des règles d’héritage, cette opération est-elle autorisée ? » C’est plus comme un jeu de règles de pare-feu pour les fichiers. L’ordre a davantage d’importance. Le « deny » existe. L’héritage est natif.

Héritage : ACL par défaut vs flags explicites

POSIX utilise des « default ACLs » sur les répertoires. Quand un nouveau fichier est créé, ces entrées par défaut peuvent devenir des entrées d’accès sur l’enfant, soumises au umask et au comportement du mask. Ça marche, mais ce n’est pas aussi expressif que l’héritage de type Windows.

NFSv4 a des flags d’héritage directement sur les ACE : appliquer aux fichiers, aux répertoires, seulement aux enfants, etc. C’est pourquoi les installations Windows-sur-ZFS préfèrent généralement les ACL NFSv4 : le modèle mental correspond à ce qu’Explorer fait.

Expressivité : granularité des droits

POSIX a des permissions grossières : lecture/écriture/exécution plus quelques bits spéciaux. Les ACL POSIX reflètent largement cela : elles étendent « qui » mais pas « quoi ».

NFSv4 découpe le « quoi » en plusieurs droits distincts : read data, write data, append, delete, read attributes, write attributes, read ACL, write ACL, take ownership, et plus encore. C’est puissant et dangereux : vous pouvez créer un fichier que quelqu’un peut écrire mais pas supprimer, ou lire sans pouvoir lister le répertoire, selon les droits assignés.

Outils : ce que vos admins utiliseront réellement

POSIX gagne pour les outils CLI quotidiens. La plupart des admins Linux raisonne avec chmod, chown, getfacl, setfacl. Le piège est qu’ils utiliseront ces outils sur un dataset où ils ne devraient pas, et les choses marcheront à moitié.

NFSv4 a des outils variables. Certains environnements utilisent nfs4_getfacl/nfs4_setfacl. Les environnements SMB gèrent souvent les ACL via les outils Windows. C’est bien — jusqu’à ce qu’un admin Linux bien intentionné lance chmod -R et « nettoie » l’ordre soigneusement conçu des ACE.

Blague #2 (et c’est tout ce que vous aurez)

Les ACL NFSv4 sont comme un thermostat programmable : incroyablement capables, et pourtant le bureau gèle parce qu’une personne a découvert « les overrides d’horaire ».

SMB, NFS et « ça marchait sur mon client »

La plupart des incidents d’ACL se produisent à la frontière du protocole. ZFS stocke quelque chose ; SMB et NFS présentent quelque chose ; vos admins changent quelque chose ; et la logique de mapping fait de son mieux.

SMB sur ZFS : où les ACL NFSv4 ont généralement du sens

Si votre dataset alimente un partage SMB et que des utilisateurs Windows gèrent les permissions, vous voulez des sémantiques d’ACL qui ressemblent à Windows. Les ACL NFSv4 se mappent généralement plus proprement à l’héritage et aux droits de type Windows. Vous avez toujours besoin d’un mappage d’identité cohérent (SIDs vers IDs Unix, selon votre stack), mais la « forme » de l’ACL correspondra aux attentes du client.

Ce qui casse habituellement n’est pas « les ACL ne fonctionnent pas », mais « les ACL fonctionnent différemment des bits de mode ». Les admins Windows s’attendent à ce que la suppression de « Write » supprime la capacité de créer des fichiers, modifier des attributs, supprimer, etc. Si votre mapping écrase plusieurs droits en un seul bit, vous pouvez créer des cas limites étranges : peut écrire mais ne peut pas renommer ; peut créer mais ne peut pas supprimer ; peut traverser mais ne peut pas lister.

NFS sur ZFS : choisissez les sémantiques que vos clients comprennent

Les clients NFSv3 vivent essentiellement dans un univers de bits de mode. Les clients NFSv4 peuvent gérer les ACL NFSv4, mais si vos outils clients et vos pratiques d’administration le font est une autre question. Si vous exécutez NFS pour des serveurs applicatifs Linux, les ACL POSIX sont souvent l’option la moins surprenante — à condition de régler aclmode et aclinherit pour correspondre à votre réalité opérationnelle.

Mix SMB + NFS : décidez qui est l’autorité

La configuration mixte la plus propre est celle où un seul système est autoritaire pour les éditions d’ACL. Patterns courants :

Windows autoritaire : ACL NFSv4, éditions via SMB, clients NFS principalement consommateurs. Les admins Linux sont formés à ne pas « corriger » avec chmod.
Unix autoritaire : ACL POSIX, éditions via CLI et gestion de configuration, SMB (si présent) est traité comme une vue de compatibilité avec des attentes limitées.

Si vous laissez les deux côtés modifier librement les permissions, vous ne construisez pas un serveur de fichiers — vous construisez une machine à remonter le temps qui revisite aléatoirement d’anciennes états d’ACL.

Trois mini-histoires du monde de l’entreprise

Mini-histoire 1 : un incident causé par une mauvaise hypothèse

La configuration semblait standard : dataset ZFS supportant un partage SMB pour une équipe finance, plus des montages NFS pour un job batch qui générait des rapports nocturnes. Quelqu’un a créé un nouveau dossier « Reports », copié la structure de l’année précédente, et tout semblait correct. Puis, juste après la clôture de fin de mois, le job batch a commencé à échouer avec « Permission denied » lors de l’écriture des fichiers — uniquement dans un sous-dossier.

L’admin de garde a fait ce que beaucoup d’entre nous feraient à 2h du matin : chmod -R g+rwX sur l’arbre de dossiers. Ça a « marché » pour le job Linux, mais le lendemain matin les utilisateurs Windows ont signalé qu’ils ne pouvaient plus changer les permissions, et certaines permissions héritées avaient disparu. L’incident avait désormais un second acte.

La mauvaise hypothèse était que les bits de mode étaient la source de vérité. Le dataset utilisait des ACL NFSv4 réglées pour l’héritage Windows. chmod ne changeait pas seulement le mode — il déclenchait le comportement défini par aclmode qui réécrivait en fait des parties des ACL pour correspondre au nouveau mode. Le job Linux a été sauvé par accident ; la structure ACL Windows a été dommages collatéraux.

La réparation a été ennuyeuse et chirurgicale : restaurer les ACL depuis un snapshot pour le sous-arbre affecté, définir un principal de service dédié pour le job batch, et accorder des droits explicites via le modèle ACL NFSv4 (ou via SMB avec un mappage d’identité cohérent). La correction à long terme a été culturelle : « chmod n’est pas un éditeur d’ACL » est devenu une règle de runbook sur ce stockage.

Mini-histoire 2 : une optimisation qui s’est retournée

Une équipe plateforme voulait des opérations métadonnées plus rapides sur un pool de répertoires personnels très actif : beaucoup de petits fichiers, vérifications ACL constantes, et des utilisateurs se plaignant des listes de répertoires lentes. Quelqu’un a proposé d’activer les xattrs basés SA (le classique « stocker les xattrs plus efficacement ») et de rendre les ACL « plus compatibles » en changeant la gestion des ACL et les défauts d’héritage pour correspondre au côté SMB.

Les performances se sont améliorées — brièvement. Le vrai retour de bâton est arrivé quelques semaines plus tard lors d’un test de réplication et d’un exercice de restauration. Un sous-ensemble de datasets restaurés montrait un comportement d’ACL subtilement différent : certains répertoires héritaient les permissions différemment qu’avant, et une poignée de comptes de service ont perdu la capacité de traverser des chemins qu’ils utilisaient quotidiennement. Personne ne l’avait remarqué en staging parce que les données de test n’incluaient pas les cas limites étranges : des arbres profonds avec des ACE explicites et héritées mélangées.

La cause racine n’était pas que SA était « mauvais ». C’était que l’équipe avait combiné plusieurs changements (stockage des xattr, comportement d’héritage des ACL, et workflows d’administration) et n’avait validé que « rapide » et « semble accessible ». En d’autres termes : ils ont optimisé la métrique facile et sauté la plus difficile — l’équivalence sémantique.

La récupération a été simple mais douloureuse : revenir d’abord sur les changements de comportement ACL, retester la réplication avec une vérification des ACL (pas seulement le comptage de fichiers), puis réintroduire les optimisations de performance un bouton à la fois. La leçon : optimiser les performances est facile ; prouver que vous n’avez pas changé le sens est le vrai travail d’ingénierie.

Mini-histoire 3 : une pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe stockage exploitait une plateforme ZFS multi-tenant pour des apps internes : NFS pour des services Linux, SMB pour quelques équipes legacy. Ils avaient une règle peu glamour : chaque dataset avait une « étiquette d’intention » documentée dans les propriétés du dataset et reflétée dans le nom — quelque chose comme apps-posix vs shares-nfsv4. Ils avaient aussi une vérification CI dans l’infrastructure-as-code qui refusait de créer un dataset sans acltype, aclmode, et aclinherit explicites.

Un vendredi, un projet a demandé « juste un partage rapide » pour un dropbox fournisseur. Un ingénieur bien intentionné a cloné un dataset existant et l’a exporté via SMB. Les fournisseurs pouvaient uploader, mais les utilisateurs internes ne pouvaient pas lire les fichiers ensuite. L’odeur était celle d’un mappage d’identité, mais l’équipe n’a pas poursuivi des fantômes.

Ils ont vérifié l’étiquette d’intention du dataset en premier. C’était un dataset orienté POSIX cloné depuis un export d’application. Le partage SMB était une erreur au niveau architecture, pas un tweak de permissions. Ils ont créé un nouveau dataset orienté NFSv4 pour le dropbox, déplacé les données, et arrêté d’essayer de faire tenir des sémantiques conflictuelles dans un seul dataset.

Pas d’héroïsme, pas d’archéologie ACL sur le weekend. La pratique « ennuyeuse » — intention explicite et propriétés imposées — a transformé une panne potentielle en un petit changement réversible.

Tâches pratiques (commandes + interprétation)

Les commandes ci-dessous supposent un système Linux avec les utilitaires ZFS installés. Certains environnements diffèrent légèrement dans les noms de propriétés et les outils disponibles, mais la logique opérationnelle reste valable. Chaque tâche inclut ce que vous cherchez et comment l’interpréter.

Task 1: Identify dataset ACL model and related properties

cr0x@server:~$ sudo zfs get -r acltype,aclmode,aclinherit,xattr pool/share
NAME        PROPERTY    VALUE        SOURCE
pool/share  acltype     nfsv4        local
pool/share  aclmode     restricted   local
pool/share  aclinherit  passthrough  local
pool/share  xattr       sa           local

Interprétation : Ce dataset est natif NFSv4 ACL. aclmode=restricted signifie que chmod sera contraint ; aclinherit=passthrough suggère que le comportement d’héritage est conçu pour préserver l’intention des ACE. xattr=sa signifie que les xattrs (souvent incluant les ACL) sont stockés efficacement dans SA, ce qui peut aider les charges lourdes en métadonnées.

Task 2: Confirm whether files have ACLs beyond mode bits

cr0x@server:~$ ls -l /pool/share/project
total 4
drwxrwx---+  5 root finance 5 Dec 24 09:10 Reports
-rw-r-----+  1 root finance 0 Dec 24 09:10 readme.txt

Interprétation : Le + indique qu’une ACL existe. Les bits de mode seuls ne raconteront pas toute l’histoire.

Task 3: Read POSIX ACLs with getfacl (POSIX datasets)

cr0x@server:~$ getfacl -p /pool/posixdata/team
# file: /pool/posixdata/team
# owner: root
# group: team
user::rwx
group::r-x
other::---
default:user::rwx
default:group::r-x
default:other::---

Interprétation : Des ACL par défaut existent, donc les nouveaux enfants héritent de ces entrées comme point de départ. S’il y a une entrée mask::, souvenez-vous qu’elle plafonne les permissions effectives pour les utilisateurs/groupes nommés et la classe groupe.

Task 4: Show the mask effect (classic POSIX ACL surprise)

cr0x@server:~$ setfacl -m u:alice:rwx /pool/posixdata/team
cr0x@server:~$ getfacl -p /pool/posixdata/team | sed -n '1,12p'
# file: /pool/posixdata/team
# owner: root
# group: team
user::rwx
user:alice:rwx
group::r-x
mask::r-x
other::---

Interprétation : Alice a rwx dans l’entrée ACL, mais les permissions effectives sont plafonnées par mask::r-x. Si Alice ne peut pas écrire, le mask est le premier suspect.

Task 5: Fix the mask intentionally (not by accident)

cr0x@server:~$ setfacl -m m::rwx /pool/posixdata/team
cr0x@server:~$ getfacl -p /pool/posixdata/team | grep -E 'user:alice|mask::'
user:alice:rwx
mask::rwx

Interprétation : Vous avez élargi le plafond des permissions effectives. Faites-le en connaissance de cause ; les masks existent pour préserver les contraintes de style bits de mode.

Task 6: Inspect NFSv4 ACLs (NFSv4 datasets)

cr0x@server:~$ nfs4_getfacl /pool/share/project/Reports
A::OWNER@:rwatTnNcCy
A::GROUP@:rxtncy
A::EVERYONE@:tncy

Interprétation : Vous regardez des ACE. Les lettres représentent des droits ; les ensembles exacts varient. Faites attention à si les permissions sont accordées à OWNER@, GROUP@ ou des principaux nommés, et s’il y a des entrées deny (qui seraient affichées avec D dans beaucoup de sorties).

Task 7: Check whether ACL inheritance is configured at the dataset level

cr0x@server:~$ sudo zfs get aclinherit pool/share
NAME       PROPERTY    VALUE        SOURCE
pool/share aclinherit  passthrough  local

Interprétation : passthrough signifie généralement que ZFS essaiera de ne pas « simplifier » les ACE héritées. Si vous voyez l’héritage supprimé ou modifié, cette propriété fait partie de l’explication.

Task 8: See what chmod does on an ACL-bearing file (and why it surprises)

cr0x@server:~$ sudo zfs get aclmode pool/share
NAME       PROPERTY  VALUE       SOURCE
pool/share aclmode   restricted  local

cr0x@server:~$ chmod 777 /pool/share/project/readme.txt
chmod: changing permissions of '/pool/share/project/readme.txt': Operation not permitted

Interprétation : Avec aclmode=restricted, chmod peut être empêché de rendre le fichier plus permissif que ce que son ACL autorise. C’est une fonctionnalité de sécurité, mais c’est aussi un indice de dépannage : si chmod échoue ou « ne fait rien », vérifiez aclmode et l’ACL elle-même.

Task 9: Confirm who ZFS thinks owns the file and group (identity sanity)

cr0x@server:~$ stat -c '%n owner=%U(%u) group=%G(%g) mode=%a' /pool/share/project/Reports
/pool/share/project/Reports owner=root(0) group=finance(10025) mode=770

Interprétation : Si vous voyez des IDs numériques là où vous attendiez des noms (ou des noms erronés), vous avez probablement un problème de mappage d’identité, pas un problème d’ACL. Corrigez l’identité d’abord ou vous appliquerez des ACL aux mauvais principaux.

Task 10: Trace an access failure from the client’s perspective

cr0x@server:~$ sudo -u alice bash -lc 'cd /pool/share/project/Reports && touch testfile'
touch: cannot touch 'testfile': Permission denied

Interprétation : Reproduire en tant qu’utilisateur supprime les hypothèses. Si Alice ne peut pas créer, vous dépannez les droits d’écriture/création du répertoire (pas les droits du fichier). Avec les ACL NFSv4, vous pouvez avoir besoin de droits spécifiques comme « add file » ; avec POSIX, vous avez besoin de write+execute sur le répertoire.

Task 11: Snapshot before ACL surgery (cheap insurance)

cr0x@server:~$ sudo zfs snapshot pool/share@before-acl-fix
cr0x@server:~$ sudo zfs list -t snapshot -o name,creation | grep 'pool/share@before-acl-fix'
pool/share@before-acl-fix  Wed Dec 24 09:35 2025

Interprétation : Le travail sur les ACL est réversible si vous snapshottez d’abord. C’est la différence entre « on va réparer vite » et « on restera toute la nuit ».

Task 12: Compare ACLs across two directories to spot drift

cr0x@server:~$ getfacl -p /pool/posixdata/team > /tmp/team.acl
cr0x@server:~$ getfacl -p /pool/posixdata/team-archive > /tmp/team-archive.acl
cr0x@server:~$ diff -u /tmp/team.acl /tmp/team-archive.acl | sed -n '1,80p'
--- /tmp/team.acl
+++ /tmp/team-archive.acl
@@
 group::r-x
-mask::rwx
+mask::r-x

Interprétation : Une seule différence de mask peut expliquer pourquoi « ça marche dans un dossier mais pas dans l’autre ». C’est une méthode rapide pour détecter les changements subtils qui surviennent après des « correctifs rapides ».

Task 13: Audit dataset mountpoint and ensure you’re editing the right path

cr0x@server:~$ sudo zfs get mountpoint pool/share
NAME       PROPERTY    VALUE         SOURCE
pool/share mountpoint  /pool/share   local

cr0x@server:~$ mount | grep '/pool/share'
pool/share on /pool/share type zfs (rw,xattr,noacl)

Interprétation : Confirmez que le dataset que vous pensez modifier est bien celui monté où vous le pensez. Modifier un chemin bind-monté ou un dataset différent est une auto-sabotage classique. (Remarque : les options de montage affichées varient selon la plateforme.)

Task 14: Verify that inheritance on a directory is doing what you think

cr0x@server:~$ mkdir -p /pool/posixdata/team/newdir
cr0x@server:~$ touch /pool/posixdata/team/newdir/newfile
cr0x@server:~$ getfacl -p /pool/posixdata/team/newdir | sed -n '1,25p'
# file: /pool/posixdata/team/newdir
# owner: root
# group: team
user::rwx
group::r-x
other::---
default:user::rwx
default:group::r-x
default:other::---

Interprétation : Si l’ACL par défaut n’est pas présente sur le nouveau répertoire, l’héritage n’est pas configuré comme vous le pensez, ou un processus de création l’écrase. Pour NFSv4, vous feriez l’équivalent en inspectant les ACE héritées sur les objets enfants.

Mode opératoire de diagnostic rapide

Voici le flux de triage que j’utilise quand « les permissions sont cassées » atterrit dans une file stockage/SRE. L’objectif est de trouver rapidement le vrai goulot : mismatch de sémantiques, mismatch d’identité, ou mismatch de propriétés/outils.

Première étape : confirmer le modèle de permissions

Vérifiez les propriétés du dataset : acltype, aclmode, aclinherit, xattr.
Confirmez que l’objet a une ACL (+ dans ls -l), et récupérez l’ACL avec le bon outil (getfacl pour POSIX ; nfs4_getfacl pour NFSv4 où applicable).

Si vous sautez cette étape et lancez directement chmod/chown, vous dépannez à l’aveugle.

Deuxième étape : reproduire en tant qu’utilisateur et identifier l’opération

Reproduisez avec sudo -u user localement (ou équivalent) pour confirmer que ce n’est pas un cache client ou un bug applicatif.
Déterminez l’opération qui échoue : traversée de répertoire, listing, création, renommage, suppression, lecture, écriture, changement d’attributs.

Différentes opérations correspondent à différents droits. « Peut écrire le fichier mais ne peut pas renommer » est un problème de permission de répertoire, pas de fichier.

Troisième étape : valider le mappage d’identité avant de réécrire les ACL

Vérifiez la propriété via stat et confirmez la résolution UID/GID attendue.
Dans les environnements mixtes, confirmez que l’utilisateur est représenté de façon cohérente entre SMB/NFS/Linux. Si « alice » est UID 1001 sur Linux mais mappe différemment via les services d’annuaire, vos edits ACL pourraient viser le mauvais principal.

Quatrième étape : vérifier si les propriétés du dataset réécrivent votre intention

Si chmod semble « échouer » ou « ne pas tenir », vérifiez aclmode.
Si les nouveaux fichiers n’héritent pas des permissions attendues, vérifiez aclinherit et si le répertoire parent a des ACL par défaut (POSIX) ou des ACE héritables (NFSv4).

Cinquième étape : seulement alors, changez les permissions — de façon minimale et réversible

Snapshottez d’abord.
Changez la plus petite portée qui corrige le problème.
Vérifiez depuis chaque type de client pertinent si vous êtes en environnement mixte.

Erreurs communes, symptômes, fixes

Mistake 1: Treating chmod as an ACL editor on NFSv4 datasets

Symptoms: Windows inheritance breaks; ACLs “simplify”; permissions drift after a Linux-side chmod; chmod errors out with “Operation not permitted.”

Fix: Stop using chmod for policy changes on NFSv4 datasets. Use NFSv4 ACL tooling or SMB/Windows ACL management consistently. Review aclmode; consider passthrough behavior if your environment requires chmod not to rewrite ACLs, but only if you understand the security implications.

Mistake 2: Forgetting the POSIX ACL mask exists

Symptoms: getfacl shows user:alice:rwx but Alice can’t write; “it looks like rwx but behaves like r-x.”

Fix: Check mask::. Adjust it deliberately with setfacl -m m::rwx (or the least permissive mask that meets requirements). Educate operators: the mask caps effective rights.

Mistake 3: Assuming “group write” means “can delete files”

Symptoms: User can create files but can’t delete/rename, or vice versa, depending on directory permissions and sticky bit behavior; on NFSv4, rights don’t map cleanly to “write.”

Fix: Debug directory permissions separately from file permissions. On POSIX: directory needs write+execute for create/delete/rename; sticky bit changes delete semantics. On NFSv4: ensure the directory ACEs include rights appropriate for delete/rename/add-file operations.

Mistake 4: Mixing SMB-side ACL edits with Linux-side setfacl on the same dataset

Symptoms: Permissions oscillate; inherited ACE flags disappear; Windows shows “weird” entries; Linux shows ACLs that don’t correspond to Windows intent.

Fix: Decide an authoritative editor path. If SMB is authoritative, manage ACLs via SMB/Windows tools and keep Linux changes minimal and procedural. If Linux is authoritative, keep SMB expectations limited and document them.

Mistake 5: Applying recursive permission changes without snapshots

Symptoms: Broad outages; you “fixed” one service and broke ten others; rollback is hand-crafted and slow.

Fix: Snapshot before recursion. If you must do recursive changes, test on a small subtree, validate clients, then proceed.

Mistake 6: Debugging permissions before debugging identity

Symptoms: ACLs look correct but access is denied; names resolve inconsistently; files show numeric owners; SMB users appear as unexpected IDs on the server.

Fix: Validate UID/GID/SID mapping. Ensure consistent directory service configuration. ACL correctness is meaningless if principals don’t map to the intended identities.

Mistake 7: Confusing “traverse” with “list” on directories

Symptoms: User can access a known file path but can’t list the directory; or the inverse, can list but can’t enter.

Fix: On POSIX: execute on a directory is traverse; read is list. On NFSv4: ensure ACEs include appropriate rights for listing vs traversing.

Checklists / step-by-step plans

Checklist: choosing acltype for a new dataset

Identifier le protocole client principal : SMB-first ou NFS/Linux-first.
Décider de l’éditeur ACL autoritaire : outils Windows ou CLI Linux/IaC.
Sélectionner acltype : NFSv4 pour SMB-first ; POSIX pour Linux-first.
Définir aclmode intentionnellement : si vous voulez que chmod soit contraint, utilisez un comportement de type restricted ; si vous voulez que chmod évite de réécrire les ACL, choisissez un comportement de type passthrough (avec prudence).
Définir aclinherit intentionnellement : choisissez un mode qui préserve les sémantiques d’héritage que vous voulez réellement.
Décider du stockage xattr : considérez xattr=sa pour les charges lourdes en métadonnées ; validez la compatibilité dans votre environnement.
Documenter l’intention : incluez-la dans le nommage du dataset ou dans ses propriétés afin que les opérateurs sachent quelles règles s’appliquent.

Step-by-step: create a POSIX-ACL oriented dataset for Linux apps

cr0x@server:~$ sudo zfs create -o acltype=posixacl -o xattr=sa pool/apps
cr0x@server:~$ sudo zfs set aclmode=groupmask pool/apps
cr0x@server:~$ sudo zfs set aclinherit=passthrough pool/apps
cr0x@server:~$ sudo zfs get acltype,aclmode,aclinherit,xattr pool/apps
NAME      PROPERTY    VALUE        SOURCE
pool/apps acltype     posixacl     local
pool/apps aclmode     groupmask    local
pool/apps aclinherit  passthrough  local
pool/apps xattr       sa           local

Interprétation : C’est une base saine pour les environnements Linux qui utilisent les ACL POSIX. Vous pouvez choisir des aclmode/aclinherit différents selon la politique, mais l’important est : définissez-les explicitement, ne laissez pas hériter des valeurs par défaut aveuglément.

Step-by-step: create an NFSv4-ACL oriented dataset for SMB shares

cr0x@server:~$ sudo zfs create -o acltype=nfsv4 -o xattr=sa pool/shares
cr0x@server:~$ sudo zfs set aclmode=restricted pool/shares
cr0x@server:~$ sudo zfs set aclinherit=passthrough pool/shares
cr0x@server:~$ sudo zfs get acltype,aclmode,aclinherit,xattr pool/shares
NAME        PROPERTY    VALUE        SOURCE
pool/shares acltype     nfsv4        local
pool/shares aclmode     restricted   local
pool/shares aclinherit  passthrough  local
pool/shares xattr       sa           local

Interprétation : Cela s’aligne avec « SMB/Windows est autoritaire ». Cela réduit la probabilité qu’un chmod sur l’hôte élargisse accidentellement l’accès. Cela ne remplace pas la nécessité d’un mappage d’identité cohérent.

Step-by-step: permission incident response (safe procedure)

Snapshottez le dataset affecté ou au moins la plus petite limite de dataset qui contient le chemin impacté.
Capturez les ACL actuelles de quelques chemins représentatifs dans des fichiers texte.
Reproduisez l’échec en tant qu’utilisateur et déterminez l’opération qui échoue.
Corrigez d’abord les problèmes de mappage d’identité s’ils sont présents.
Appliquez des changements ACL minimaux en utilisant le modèle/outillage correct.
Vérifiez depuis chaque type de client pertinent (SMB et/ou NFS) et depuis le shell local.
Documentez ce qui a changé et pourquoi ; la dérive d’ACL sans documentation provoque des incidents répétés.

FAQ

1) What exactly does `acltype` change on ZFS?

Il sélectionne les sémantiques d’ACL que ZFS utilisera pour ce dataset : comportement ACL POSIX (mask, ACLs par défaut) versus comportement ACL NFSv4 (listes d’ACE avec flags d’héritage et droits plus riches). Il influence la façon dont les ACL sont stockées et comment les opérations modifiant les permissions interagissent avec les ACL existantes.

2) If I use NFSv4 ACLs, can I still use `chmod` and `chown`?

Vous le pouvez, mais vous devez comprendre aclmode. Dans beaucoup de configurations, chmod est contraint ou empêché de faire des changements qui entrent en conflit avec la politique ACL. Si votre organisation s’attend à « chmod règle tout », les datasets NFSv4 généreront des tickets à moins que vous ne reformatiez les workflows.

3) Why does `ls -l` show permissions that don’t match reality?

Parce que les bits de mode ne sont qu’une partie de l’histoire quand des ACL existent. Avec les ACL POSIX, le mask peut plafonner les permissions effectives. Avec les ACL NFSv4, les bits de mode sont souvent une vue sommaire et ne représentent pas des droits complets comme delete, rename, ou write-ACL.

4) Should I use POSIX ACLs for NFS shares?

Souvent oui pour les environnements NFSv3 majoritairement Linux, car le modèle opérationnel s’aligne. Pour des clients NFSv4 qui utilisent réellement les ACL NFSv4 de bout en bout, les ACL NFSv4 peuvent être un bon choix — mais seulement si vos outils clients et vos habitudes d’administration correspondent à ce monde.

5) Should I use NFSv4 ACLs for SMB shares?

Dans la plupart des environnements Windows mixtes, oui. Les ACL NFSv4 tendent à préserver mieux les sémantiques d’héritage de type Windows et éviter les mappings perdants. La réserve est le mappage d’identité : si vos users/groups ne se mappent pas de façon cohérente, le meilleur modèle ACL ne vous sauvera pas.

6) Can I switch `acltype` on an existing dataset safely?

« En toute sécurité » dépend de ce qui existe dans le dataset et de la façon dont les clients dépendent des sémantiques actuelles. Changer de modèle peut modifier la façon dont les ACL sont interprétées ou représentées. En production, traitez cela comme une migration : snapshottez, testez sur un clone, validez avec des charges réelles, et attendez-vous à des cas limites.

7) Why do some users have “write” but can’t delete files?

Sur POSIX, la suppression est contrôlée par les permissions du répertoire (et les règles du sticky bit), pas par le bit writable du fichier. Sur NFSv4, les droits delete/rename peuvent être séparés des droits d’écriture de données. Diagnosez les ACL/permissions du répertoire, pas seulement celles du fichier.

8) What’s the quickest way to debug “Permission denied”?

Confirmez acltype et récupérez l’ACL avec le bon outil, reproduisez en tant qu’utilisateur, identifiez si l’échec concerne traversée/listing/création/rename, puis validez le mappage d’identité. Ce n’est qu’après cela que vous devez modifier les ACL. Cela évite le classique « chmod a empiré les choses ».

9) Does `xattr=sa` change ACL behavior?

Ça change principalement l’endroit où les xattrs sont stockés pour les performances, pas les sémantiques. Mais les changements de performances peuvent exposer des problèmes latents (comme des applis faisant plus d’opérations métadonnées que vous ne le pensiez), et opérationnellement vous devez valider la réplication/restauration et la compatibilité des outils dans votre environnement.

10) If I must support both SMB and NFS, what’s the least painful strategy?

Choisissez un modèle de permissions autoritaire par dataset et appliquez-le. Utilisez des datasets séparés pour les workloads SMB-first et NFS-first. L’édition d’ACL à autorité mixte dans le même dataset est la cause des bizarreries de permissions à long terme.

Conclusion

acltype concerne moins les internals de ZFS que la vérité opérationnelle : qui définit la politique d’accès, et quelles sémantiques client vous vous engagez à préserver. Les ACL POSIX sont l’extension naturelle des bits de mode Unix et sont généralement la voie la plus calme pour des environnements Linux-first — à condition de respecter le mask et les règles d’ACL par défaut. Les ACL NFSv4 sont l’outil adapté quand les sémantiques et l’héritage Windows/SMB doivent rester intacts — à condition de cesser de considérer chmod comme un solvant universel.

Le vrai gain est la cohérence. Décidez de l’identité du dataset et de l’autorité des permissions en amont, définissez explicitement les propriétés, snapshottez avant des changements récursifs, et dépannez le mappage d’identité avant de réécrire les ACL. Faites cela, et les permissions ZFS cessent d’être une maison hantée et redeviennent un système que vous pouvez raisonnablement comprendre — en astreinte, sous pression, avec des attentes de disponibilité d’adulte.