ZFS sharenfs/sharesmb : commodité vs contrôle en production

Ce que font réellement sharenfs/sharesmb (et ce qu’ils ne font pas)

sharenfs en une phrase

sharenfs est une propriété de dataset ZFS qui peut indiquer à l’hôte d’exporter le dataset via NFS en utilisant le sous-système
de partage de la plateforme, généralement en générant dynamiquement des règles d’export et en appelant le mécanisme de partage de l’OS
(pas par magie).

sharesmb en une phrase

sharesmb est une propriété de dataset ZFS qui peut ordonner à l’hôte de publier le dataset comme partage SMB via l’intégration
du service SMB de la plateforme (historiquement sur illumos/Solaris ; sur Linux cela dépend de vos outils et de l’intégration de la
distribution).

Pourquoi c’est important : vous choisissez une couche d’orchestration

ZFS lui-même ne parle ni NFS ni SMB. Il délègue. Ces propriétés de dataset sont en fait un petit orchestrateur de partages lié aux
métadonnées du système de fichiers. C’est à la fois l’attrait et le risque : la définition du partage voyage avec le dataset, peut être
héritée, clonée et répliquée — puis vous surprend plus tard parce qu’elle est toujours là.

La vérité inconfortable : le comportement varie selon l’OS et la « saveur » de ZFS

Sur les systèmes dérivés d’illumos (et l’ancienne lignée Solaris), les propriétés de partage ZFS sont des citoyens de première classe :
zfs share, zfs unshare, intégration au sharetab, partage SMB via le gestionnaire de services de l’OS — tout le
paquet. Sur Linux avec OpenZFS, les propriétés existent, mais l’activation des partages peut être implémentée via des scripts d’aide,
des unités systemd, ou des choix d’emballage. Certains environnements traitent sharenfs comme « métadonnée consultable »
sans plus jusqu’à ce que vous installiez et activiez les services adéquats.

Question de contrôle : voulez-vous que les partages soient « déclarés » au niveau ZFS (propriétés de dataset) ou « déclarés » au niveau du
service (/etc/exports, la config Samba, ou un système de gestion de configuration) ? Si vous ne pouvez pas répondre de façon
nette, vous allez le découvrir à 3h du matin.

Ce que ces propriétés ne font pas

• Elles n’appliquent pas la sécurité au niveau réseau. Elles influencent seulement la configuration des partages/exports.
• Elles ne remplacent pas une conception correcte des identités et permissions (mapping UID/GID, ACL, identités SMB).
• Elles ne garantissent pas un comportement cohérent sur votre parc à moins que vos outils OS soient homogènes.
• Elles n’empêchent pas quelqu’un d’éditer /etc/exports ou la configuration Samba et de s’éloigner de l’intention ZFS.

Une propriété de partage, c’est comme écrire « livrer à la porte d’entrée » sur un colis. Ça aide. Ce n’est pas une serrure.

Commodité vs contrôle : étude de compromis en production

Quand les propriétés de partage sont un gain

Utilisez sharenfs/sharesmb quand vous voulez que le dataset soit auto-descriptif, notamment si vous :

• Provisionnez et déprovisionnez des datasets fréquemment (caches CI, espaces de travail pour projets, sandboxes analytiques éphémères).
• Clonez des datasets et voulez que l’intention de partage suive le clone (parfois c’est souhaitable, souvent non — gardez cela en tête).
• Utilisez la réplication ZFS et voulez que le côté récepteur sache « ce dataset est destiné à être exporté », même si vous ne l’exportez pas automatiquement.
• Avez besoin d’un état cohérent et consultable : « Quels datasets sont partagés ? » se trouve avec un simple zfs get.

Quand les propriétés de partage deviennent un passif

Évitez de vous reposer sur elles comme votre plan de contrôle principal quand vous :

• Avez besoin d’un contrôle de changement explicite pour les exports/partages (exigences d’audit, approbations de sécurité, séparation des tâches).
• Exécutez plusieurs piles NFS/SMB ou plusieurs sources de config (exports édités à la main plus auto-share ZFS plus un système d’orchestration).
• Utilisez la réplication de datasets entre environnements (prod ↔ staging) où les règles de partage ne devraient pas suivre.
• Avez un comportement OS mixte sur votre parc (certains nœuds respectent les propriétés ; d’autres les ignorent).

Le vrai compromis : localité de l’état vs gouvernance

Les propriétés de partage placent l’état du partage à côté des données. C’est élégant. C’est aussi un raccourci de gouvernance. Le mouvement
classique en ops est de garder la politique « qui est exporté vers qui » dans un seul endroit et de traiter le système de fichiers comme un
détail d’implémentation. Les propriétés de partage inversent cela : le système de fichiers devient le dépôt de politique.

Ma règle opinionnée : si vous avez plus d’un hôte de stockage, traitez les propriétés de partage comme des métadonnées déclaratives
et ayez un mécanisme séparé qui décide s’il faut les honorer. Vous pouvez toujours les utiliser — mais vous ne laissez pas une propriété de
dataset percer un trou dans votre réseau unilatéralement.

Blague #1 : « L’auto-partage, c’est comme les abonnements à renouvellement automatique : pratique jusqu’à ce que vous remarquiez qu’il a été renouvelé dans un autre pays. »

Le tranchant caché : l’héritage

Les propriétés ZFS s’héritent dans l’arborescence des datasets. C’est généralement une fonctionnalité. Pour le partage, c’est aussi un piège.
Mettre sharenfs=on sur un dataset parent peut entraîner l’export accidentel de datasets administratifs internes, de snapshots montés
ailleurs, ou de nouveaux enfants créés plus tard par l’automatisation. Les gens aiment l’héritage jusqu’au moment où il s’hérite dans la
mauvaise direction.

Un autre tranchant : réplication et « dérive de partage »

Quand vous répliquez des datasets, vous pouvez répliquer aussi les propriétés. Selon les flags et les outils, la destination peut recevoir
des valeurs sharenfs/sharesmb qui avaient du sens à la source mais sont dangereuses à la destination.
Le mode d’échec n’est pas toujours « il exporte immédiatement ». Parfois c’est pire : la configuration reste latente jusqu’à ce qu’une mise
à jour de paquet ou un redémarrage commence soudainement à honorer les propriétés. Félicitations, vous venez d’envoyer une bombe à retardement via la réplication.

Contrôle ne veut pas dire tout éditer à la main

L’alternative aux propriétés de partage n’est pas « éditez /etc/exports à la main et espérez ». Le contrôle peut s’obtenir avec :

• La gestion de configuration générant les exports et les partages Samba à partir d’un inventaire et d’une politique.
• Un wrapper qui lit les propriétés ZFS et génère des configs de service, mais applique une liste blanche et une revue.
• Séparation d’espace de noms : un parent unique où le partage est autorisé et tous les autres par défaut sur « off ».

Vous voulez un système où l’état par défaut est ennuyeux et sûr, et où les exceptions sont délibérées.

Une idée paraphrasée de Werner Vogels : « You build it, you run it. » En termes de stockage : si vous définissez la propriété,
vous assumez le rayon d’impact.

Faits & contexte historique qui importent vraiment

1. Le partage ZFS est né dans l’univers Solaris/illumos. L’intégration étroite avec les services de partage système n’est pas une bévue ; c’était l’expérience opérateur prévue.
2. La configuration d’export NFS prédate ZFS de plusieurs décennies. Les conventions de /etc/exports ont été conçues pour des systèmes de fichiers statiques, pas pour des basculements par dataset et l’héritage de propriétés.
3. Le SMB sur Solaris a pris une voie différente de Samba. illumos/Solaris a historiquement fourni un serveur SMB en noyau et des outils de service ; Linux repose typiquement sur Samba en espace utilisateur.
4. Les propriétés ZFS sont conçues pour l’héritage, le clonage et la réplication. C’est pourquoi le partage via propriétés paraît naturel — et pourquoi il peut répliquer des surprises avec les données.
5. Le style « sharetab » existait pour répondre rapidement à « qu’est-ce qui est exporté ? ». Les opérateurs voulaient une source de vérité unique pour les partages vivants avant l’ère de la découverte de services moderne.
6. NFSv4 a changé le modèle mental. Les pseudoracines et un point d’export unique peuvent masquer ou révéler les frontières de datasets d’une manière qui perturbe les équipes formées sur NFSv3.
7. Les sémantiques ACL divergent entre NFS et SMB. Même si les deux exposent le même dataset, la traduction du modèle de permissions n’est pas symétrique et peut créer des casse-têtes « fonctionne en SMB, échoue en NFS ».
8. L’idmapping a toujours été le tueur silencieux. Le partage peut être parfait ; les problèmes de mapping UID/GID ou SID feront quand même apparaître un service « down ».
9. Linux OpenZFS a conservé les propriétés pour compatibilité. Mais « la propriété existe » n’équivaut pas à « la distribution active l’auto-share par défaut ».

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

Task 1: List which datasets claim they are shared

cr0x@server:~$ zfs get -r -o name,property,value,source sharenfs,sharesmb tank
NAME                 PROPERTY  VALUE  SOURCE
tank                 sharenfs  off    default
tank                 sharesmb  off    default
tank/projects        sharenfs  on     local
tank/projects        sharesmb  off    inherited from tank
tank/projects/acme   sharenfs  on     inherited from tank/projects
tank/projects/acme   sharesmb  off    inherited from tank
tank/backups         sharenfs  off    local
tank/backups         sharesmb  off    default

Ce que cela signifie : Vous voyez la valeur et la SOURCE. L’héritage des partages est la première chose à craindre.
Décision : Si un dataset est partagé par héritage de façon non voulue, définissez-le explicitement :
zfs set sharenfs=off tank/projects/acme ou corrigez le parent.

Task 2: Verify what the OS thinks is currently exported over NFS

cr0x@server:~$ exportfs -v
/tank/projects  10.20.0.0/16(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash)
/tank/backups   10.30.5.42(sync,wdelay,hide,no_subtree_check,sec=sys,ro,root_squash)

Ce que cela signifie : Il s’agit de la table d’export NFS active (serveur NFS Linux). Elle peut correspondre ou non aux
propriétés ZFS.
Décision : Si zfs get sharenfs indique « on » mais que exportfs ne l’affiche pas, votre chemin
d’auto-share n’est pas actif. Si exportfs montre des exports non voulus, vous avez une dérive de configuration ou un générateur trop zélé.

Task 3: Confirm the share service is running (NFS)

cr0x@server:~$ systemctl status nfs-server --no-pager
● nfs-server.service - NFS server and services
     Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled)
     Active: active (exited) since Thu 2025-12-26 09:10:12 UTC; 3h 1min ago
       Docs: man:rpc.nfsd(8)

Ce que cela signifie : NFS est en place au niveau du service. Si les clients ne peuvent toujours pas monter, regardez les exports, le pare-feu et l’idmapping.
Décision : Si inactif, ne déboguez pas encore les propriétés ZFS — démarrez le service et confirmez les ports.

Task 4: Check whether ZFS auto-share tooling is enabled (Linux example)

cr0x@server:~$ systemctl status zfs-share --no-pager
● zfs-share.service - ZFS dataset share service
     Loaded: loaded (/lib/systemd/system/zfs-share.service; enabled)
     Active: active (exited) since Thu 2025-12-26 09:10:10 UTC; 3h 1min ago

Ce que cela signifie : Sur de nombreuses configurations Linux, cette unité tente d’honorer sharenfs/sharesmb.
Décision : Si désactivée ou absente, vos propriétés sont probablement une « configuration papier ». Décidez d’activer ou de migrer complètement vers des configs de service explicites.

Task 5: Force a re-share after property changes

cr0x@server:~$ sudo zfs share -a
cannot share 'tank/backups': property 'sharenfs' is off
tank/projects shared

Ce que cela signifie : La commande de partage applique l’état actuel des propriétés. Certaines plateformes font cela automatiquement lors du set ; d’autres requièrent un zfs share explicite ou un redémarrage du service.
Décision : Si le partage ne s’applique pas lors du changement de propriété, intégrez le « re-share » dans votre runbook et votre automatisation.

Task 6: Inspect the exact sharenfs option string (not just on/off)

cr0x@server:~$ zfs get -o name,property,value sharenfs tank/projects
NAME           PROPERTY  VALUE
tank/projects  sharenfs  rw=@10.20.0.0/16,root_squash,sec=sys

Ce que cela signifie : C’est là que la commodité devient configuration : les chaînes d’options peuvent exprimer une politique.
Décision : Si vous autorisez des chaînes d’options, standardisez-les. Sinon, les équipes inventeront leur propre dialecte et vous passerez vos weekends à traduire.

Task 7: Validate dataset mountpoints match what you think you are exporting

cr0x@server:~$ zfs get -o name,property,value mountpoint tank/projects tank/projects/acme
NAME                PROPERTY    VALUE
tank/projects       mountpoint  /tank/projects
tank/projects/acme  mountpoint  /tank/projects/acme

Ce que cela signifie : Les exports utilisent généralement des chemins. Si les mountpoints ont été modifiés, renommés ou montés en legacy, vous pouvez exporter le mauvais chemin.
Décision : Si les mountpoints ne correspondent pas à votre schéma d’export, corrigez les mountpoints ou exportez explicitement par conception.

Task 8: Confirm the dataset is actually mounted where you expect

cr0x@server:~$ mount | grep -E '^tank/projects'
tank/projects on /tank/projects type zfs (rw,xattr,posixacl)
tank/projects/acme on /tank/projects/acme type zfs (rw,xattr,posixacl)

Ce que cela signifie : S’il n’est pas monté, l’export NFS peut exister mais pointer vers un répertoire vide (ou échouer).
Décision : Si non monté, vérifiez canmount, mountpoint et l’ordre des services de montage ZFS.

Task 9: Check ZFS properties that often get confused with sharing

cr0x@server:~$ zfs get -o name,property,value -s local,inherited canmount,readonly,acltype,xattr tank/projects
NAME           PROPERTY  VALUE
tank/projects  canmount  on
tank/projects  readonly  off
tank/projects  acltype   posixacl
tank/projects  xattr     sa

Ce que cela signifie : Si readonly=on, les écritures échouent et les gens blâment NFS. Si les réglages ACL/xattr diffèrent, le comportement SMB/NFS diverge.
Décision : Alignez les attentes ACL/xattr avec les cas d’usage des protocoles. Ne « corrigez » pas les problèmes de partage en changeant au hasard acltype.

Task 10: From a client, confirm what the server is offering (NFS)

cr0x@server:~$ showmount -e nfs01
Export list for nfs01:
/tank/projects 10.20.0.0/16

Ce que cela signifie : Le client peut interroger la liste d’exports (outils hérités de l’époque NFSv3, mais toujours utiles).
Décision : Si showmount ne renvoie rien, suspectez le pare-feu/rpcbind/versions NFS ou un export côté serveur non appliqué.

Task 11: Confirm NFS version and mount options on the client

cr0x@server:~$ sudo mount -t nfs -o vers=4.1 nfs01:/tank/projects /mnt/projects
cr0x@server:~$ nfsstat -m | grep -A3 '/mnt/projects'
/mnt/projects from nfs01:/tank/projects
 Flags:	rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.4.18

Ce que cela signifie : Vous voyez la version NFS négociée et les tailles. Si le montage retombe silencieusement en v3 ou utilise UDP, c’est un indice.
Décision : Si la performance est mauvaise, confirmez que vous êtes en TCP et sur une version NFS moderne. Si les permissions sont étranges, vérifiez sec=.

Task 12: Confirm idmapping and “nobody:nogroup” problems early

cr0x@server:~$ getent passwd 1001
acmebuild:x:1001:1001:ACME Build User:/home/acmebuild:/usr/sbin/nologin
cr0x@server:~$ ls -ln /tank/projects/acme | head
total 3
drwxr-x---  5 1001 1001 5 Dec 26 09:11 build

Ce que cela signifie : La propriété numérique de possession correspond à une identité. Si les clients voient l’UID 1001 mais que le serveur ne le connaît pas, les permissions se bloquent.
Décision : Si getent ne résout pas les IDs sur un côté, corrigez les services d’annuaire/SSSD/LDAP avant de réécrire les exports.

Task 13: Check whether SMB shares exist at the service layer (Samba)

cr0x@server:~$ testparm -s | sed -n '1,120p'
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

[projects]
	path = /tank/projects
	read only = No
	browsable = Yes

Ce que cela signifie : Le partage SMB est contrôlé par la configuration Samba sur Linux. sharesmb de ZFS peut ne pas être relié.
Décision : Si vous attendiez que ZFS crée automatiquement des partages Samba mais qu’ils n’apparaissent pas ici, arrêtez d’assumer. Choisissez un plan de contrôle et branchez-le explicitement.

Task 14: Verify live SMB shares from Samba’s view

cr0x@server:~$ smbcontrol all reload-config
cr0x@server:~$ smbclient -L localhost -N | sed -n '1,80p'
	Sharename       Type      Comment
	---------       ----      -------
	projects        Disk
	IPC$            IPC       IPC Service (Samba Server)
SMB1 disabled -- no workgroup available

Ce que cela signifie : Vous voyez si le partage est réellement servi. « Configuré » et « en service » sont deux états différents.
Décision : S’il est absent, corrigez la configuration/le service Samba d’abord ; n’alternez pas sans cesse sharesmb en espérant que cela créera des stanzas Samba.

Task 15: Detect property replication surprises

cr0x@server:~$ zfs get -o name,property,value,source sharenfs,sharesmb -r tank/recv
NAME                 PROPERTY  VALUE  SOURCE
tank/recv            sharenfs  off    default
tank/recv            sharesmb  off    default
tank/recv/projects   sharenfs  on     received
tank/recv/projects   sharesmb  off    received

Ce que cela signifie : SOURCE=received est un néon : la réplication a livré cet état.
Décision : Si vous êtes sur un hôte non prod, définissez une politique : écraser les propriétés reçues à l’arrivée, ou ne jamais les honorer automatiquement.

Task 16: Confirm whether a dataset is being “shared” but not actually reachable (firewall/ports)

cr0x@server:~$ sudo ss -lntp | grep -E '(:2049|:111)\s'
LISTEN 0      64          0.0.0.0:2049      0.0.0.0:*    users:(("rpc.nfsd",pid=1432,fd=6))
LISTEN 0      128         0.0.0.0:111       0.0.0.0:*    users:(("rpcbind",pid=812,fd=4))

Ce que cela signifie : NFS et rpcbind écoutent. S’ils n’écoutent pas, un « exporté » n’a pas d’importance.
Décision : Si les ports n’écoutent pas, corrigez les services. S’ils écoutent mais que les clients ne peuvent pas se connecter, vérifiez les ACL réseau.

Guide de diagnostic rapide : ce qu’il faut vérifier en premier/deuxième/troisième

C’est la séquence « arrêter de deviner » quand quelqu’un dit « NFS est en panne » ou « le partage SMB a disparu » après un changement de propriété.
Le but est d’isoler si vous avez un décalage de plan de contrôle, un problème de plan de service, ou un
problème de données/permissions.

Premier : le dataset est-il censé être partagé ?

• Exécutez zfs get sharenfs,sharesmb -r pour l’arbre de datasets.
• Regardez la SOURCE : local vs inherited vs received.
• Confirmez mountpoint et canmount.

Si la propriété est héritée et que vous ne l’attendiez pas, c’est votre bogue. Corrigez la hiérarchie, pas le symptôme.

Second : l’OS l’exporte-t-il réellement / le sert-il ?

• NFS : exportfs -v et ss -lntp | grep 2049.
• SMB : testparm -s, puis smbclient -L localhost -N.
• Si vous dépendez de l’auto-share ZFS : vérifiez systemctl status zfs-share (ou équivalent selon la plateforme).

Si ZFS dit « partagé » mais la couche service n’est pas d’accord, vous avez un problème d’intégration, pas un problème de permissions.

Troisième : un client peut-il négocier et monter ?

• NFS : monter depuis le client avec vers=4.1 explicite et vérifier nfsstat -m.
• SMB : tenter d’abord une connexion en loopback locale, puis une distante, pour séparer l’authentification du réseau.

Si le local fonctionne mais le distant échoue, vous êtes en territoire pare-feu/routage/SELinux. Si le distant monte mais l’accès est refusé, vous êtes dans les identités/ACL/options d’export.

Quatrième : la plainte concerne la performance, pas la disponibilité ?

• Vérifiez les rsize/wsize NFS négociés et le protocole.
• Vérifiez la saturation CPU du serveur (le chiffrement/signature SMB peut être coûteux en CPU).
• Vérifiez la santé au niveau ZFS : état du pool et latence.

Ne « tunez NFS » que lorsque vous avez confirmé que ZFS ne s’étouffe pas déjà sur des écritures sync, un vdev dégradé, ou un ARC épuisé.

Trois mini-histoires d’entreprise depuis les tranchées des propriétés de partage

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

Une entreprise de taille moyenne avait deux nœuds de stockage : un pour la production et un pour les tests de reprise après sinistre. L’équipe
répliquait les datasets chaque nuit. Ils utilisaient fortement les propriétés ZFS parce que ça rendait le provisioning propre : créer le
dataset, définir le quota, définir sharenfs, terminé.

Lors d’un test DR de routine, un développeur a monté un partage de projet depuis le nœud DR « juste pour vérifier un artefact de build ». Ça a monté.
C’était la première surprise. La seconde surprise fut que l’accès en écriture fonctionnait aussi, parce que les options d’export avaient été héritées et étaient permissives.

Personne n’avait prévu que le nœud DR n’exporterait rien au-delà d’un sous-réseau administratif limité. Mais les datasets répliqués avaient sharenfs
défini en tant que propriété reçue. Et le nœud DR avait récemment été mis à jour, ce qui a activé une unité de partage qui a commencé à honorer ces propriétés au démarrage.
Personne n’a relié les points parce que le changement était au niveau OS, pas au niveau ZFS.

L’« incident » n’était pas une perte de données, mais c’était un échec de gouvernance : le DR était devenu une cible de partage parallèle à la production avec des hypothèses d’identité obsolètes et des contrôles réseau plus lâches. Le postmortem a identifié une conclusion banale : ils supposaient que « les propriétés se répliquent mais ne font rien ici ». Cette supposition était vraie jusqu’à ce qu’elle cesse de l’être.

La correction fut également ordinaire et efficace : ils ont ajouté une tâche au démarrage sur le nœud DR qui force sharenfs=off et
sharesmb=off pour tous les datasets reçus, puis applique une liste blanche pour les rares exports administratifs dont ils avaient réellement besoin.
Pas élégant. Correct.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait des « partages instantanés » pour une plateforme analytique interne. Leur automatisation créait des datasets par équipe à la demande.
Pour éviter de toucher /etc/exports pour chaque équipe, ils standardisèrent la définition de sharenfs lors de la création de dataset avec une règle basée sur le réseau, et activèrent le traitement automatique des partages.

Ça a bien fonctionné pendant des mois. Puis un nouveau dataset parent a été introduit : tank/analytics. Quelqu’un a mis
sharenfs=rw=@10.50.0.0/16 sur le parent pour réduire le boilerplate, en s’attendant à ce que les enfants soient plus restrictifs si nécessaire.
C’est l’optimisation : s’appuyer sur l’héritage.

Un trimestre plus tard, un audit de conformité a révélé qu’une poignée de datasets destinés à un sous-réseau restreint étaient exportables depuis des réseaux plus larges.
Pas parce que quelqu’un les avait mal configurés localement, mais parce que ces datasets enfants n’avaient jamais surchargé la propriété héritée.
Leurs créateurs supposaient qu’« aucune définition explicite de sharenfs signifie non partagé ». Dans ZFS, « pas explicite » signifie souvent « hérité ».

La remédiation fut pénible : auditer chaque dataset, définir explicitement sharenfs=off sur les arbres restreints, et refondre l’automatisation pour exiger une déclaration explicite de partage à la création (même si c’est « off »). La leçon n’était pas « l’héritage est mauvais ». La leçon était : l’héritage est un outil tranchant, et vous ne le confiez pas à tous les pipelines sans garde-fous.

Blague #2 : « L’héritage, c’est génial — jusqu’à ce que vos exports héritent du même enthousiasme que vos stagiaires. »

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

Une grande entreprise gérait des charges mixtes : NFS Linux pour des clusters compute, SMB pour des workflows bureautiques, et des équipes applicatives
demandant des exceptions. Ils ont choisi une politique qui semblait peu sexy : les propriétés de partage ZFS sont autorisées, mais elles ne sont pas
faisant autorité.

Concrètement : chaque dataset pouvait porter sharenfs ou sharesmb comme métadonnée, mais les hôtes de stockage ne les appliquaient pas automatiquement.
À la place, un petit outil interne tournait la nuit et à la demande, lisait ces propriétés, les validait contre une liste blanche, puis générait des exports/extraits Samba. Tous les changements étaient revus comme du code.

Un jour, la réplication a amené un arbre de datasets depuis un environnement partenaire. Les propriétés reçues incluaient sharenfs=rw=@0.0.0.0/0
(oui, vraiment). Si les hôtes avaient auto-partagé, cela serait devenu un incident de sécurité. À la place, le générateur l’a marqué comme invalide, a refusé de l’appliquer, et a remonté une alerte dans le chat de l’équipe.

L’équipe a conservé la commodité opérationnelle « l’intention de partage suit le dataset ». Mais ils ont gardé l’application de la politique à un seul endroit.
La pratique était ennuyeuse, et elle a évité une nuit très agitée.

Erreurs courantes : symptômes → cause racine → correctif

1) « Nous avons mis sharenfs=on, mais les clients ne montent pas. »

• Symptôme : zfs get sharenfs affiche « on » ; le montage client échoue avec « access denied » ou « no route to host ».
• Cause racine : service d’auto-share non activé, ou service NFS non démarré, ou pare-feu bloquant 2049/111.
• Correctif : Vérifiez systemctl status zfs-share (ou équivalent) et systemctl status nfs-server.
  Confirmez les ports à l’écoute avec ss. Puis vérifiez que exportfs -v affiche le chemin.

2) « Un dataset qui devrait être privé est exporté. »

• Symptôme : exportfs -v liste un export inattendu ; zfs get montre un partage hérité.
• Cause racine : sharenfs défini sur un dataset parent ; l’enfant l’a hérité silencieusement.
• Correctif : Mettez sharenfs=off sur le parent, ou explicitement sur les datasets enfants privés. Ajoutez un contrôle d’audit pour empêcher le partage au niveau parent sauf si c’est une « frontière de partage » délibérée.

3) « Après réplication, les partages se comportent différemment sur la destination. »

• Symptôme : La destination exporte de façon inattendue, ou n’exporte pas avant une mise à jour/redémarrage.
• Cause racine : Les propriétés reçues incluent des réglages de partage ; la destination les honore maintenant en raison de changements de service.
• Correctif : Décidez d’une politique de réplication : supprimer/surcharger les propriétés de partage à la réception, ou ne jamais activer l’auto-share sur les récepteurs. Utilisez zfs get ... source pour trouver received.

4) « SMB fonctionne mais les permissions NFS sont incorrectes (ou inversement). »

• Symptôme : Même dataset, résultats d’accès différents selon le protocole.
• Cause racine : Mismatch de mapping d’identités, divergence d’attentes ACL, ou options d’export comme root_squash mal comprises.
• Correctif : Validez les UIDs/GIDs avec getent côté serveur et client. Confirmez les propriétés ACL/xattr ZFS. Révisez les options d’export et les modules vfs Samba si utilisés.

5) « Nous avons désactivé sharenfs mais c’est toujours exporté. »

• Symptôme : La propriété indique off ; exportfs -v montre toujours l’export.
• Cause racine : L’export existe dans /etc/exports ou dans une config générée en dehors de ZFS ; ou l’unshare n’a pas été appliqué.
• Correctif : Trouvez la source d’autorité. Retirez l’export des configs explicites, puis exécutez exportfs -ra. Si ZFS orchestre, lancez zfs unshare/zfs share -a selon le cas.

6) « Collisions de noms de partages ou chemins incohérents dans le listing SMB. »

• Symptôme : Noms de partages dupliqués, partages bizarrement nommés, ou chemins erronés.
• Cause racine : Partages SMB auto-générés à partir des noms de datasets qui entrent en conflit avec les conventions humaines ; plusieurs datasets mappent à des noms de partages similaires.
• Correctif : N’auto-générez pas les noms de partages SMB depuis les chemins des datasets à moins de contrôler strictement la nomenclature. Préférez des stanzas Samba explicites avec des noms soignés, et traitez sharesmb comme simple métadonnée.

7) « La performance a chuté après avoir ‘tuning’ les options de partage. »

• Symptôme : Pics de latence, timeouts clients, CPU serveur élevé, ou journaux de base de données agacés.
• Cause racine : Activation de sémantiques heavy-sync sans intention (ou désactivation sans compréhension), coût CPU du signing/chiffrement SMB, ou mauvaise négociation rsize/wsize NFS.
• Correctif : Confirmez les exigences de durabilité de la charge. Mesurez le CPU serveur et la latence ZFS. Verrouillez la version NFS et le transport si approprié. Ne faites pas de cargo-cult avec des options de montage trouvées sur Internet.

Patrons opérationnels : comment gérer ça sans regrets

Pattern A: “Properties as metadata, policy elsewhere” (recommandé pour la plupart des organisations)

Vous autorisez les équipes à définir les propriétés sharenfs/sharesmb, mais vous ne les appliquez pas automatiquement. Un processus
contrôlé les lit et génère les configs exports/Samba après validation :

• Le dataset se trouve dans un sous-arbre autorisé (par ex. tank/projects oui, tank/system non).
• Les options proviennent d’une liste blanche sûre (pas d’exports ouverts au monde, pas de modes de sécurité inattendus).
• Le changement est révisé, audité, et appliqué de façon prévisible.

Ce patron garde l’avantage « l’intention de partage suit le dataset » sans laisser une propriété devenir un moteur de politique réseau.

Pattern B: “One host, one purpose, auto-share is fine”

Si vous exploitez un seul appliance de stockage ou un environnement étroitement contrôlé où ZFS est par conception le plan de contrôle des partages
(commun dans les appliances basées sur illumos), l’auto-share peut être parfaitement sensé. Mais vous avez toujours besoin de :

• Des frontières strictes dans la hiérarchie des datasets : un seul sous-arbre est autorisé à être partagé.
• Des off explicites sur les parents sensibles pour prévenir les accidents d’héritage.
• Des jobs d’audit pour détecter des valeurs « on » inattendues, en particulier héritées/reçues.

Pattern C: “Explicit service configs only”

C’est l’approche de contrôle maximal : ignorez les propriétés de partage et gérez NFS/SMB via des configs de service et un gestionnaire de configuration.
C’est viable, mais vous perdez un peu d’introspection pratique. Si vous prenez cette voie, au moins utilisez les propriétés comme documentation :
mettez-les sur off partout et stockez les exports prévus dans un CMDB/inventaire.

Où les équipes se brûlent : mélanger les patrons

Les pires configurations sont des hybrides sans règles :

• Des exports dans /etc/exports et d’autres via l’auto-share ZFS.
• Des partages créés manuellement dans Samba plus des propriétés ZFS qui « parfois » créent des partages.
• De l’automatisation qui définit des propriétés mais que personne ne sait si elles sont appliquées.

Si vous ne retenez qu’une chose : choisissez un plan de contrôle faisant autorité par protocole. Tout le reste est de la métadonnée.

Position de sécurité : supposez que les propriétés de partage ne sont pas un contrôle d’accès

Traitez les options de partage comme une couche parmi d’autres. Votre vraie sécurité repose sur la segmentation réseau, les pare-feux hôtes,
la gestion des identités, et les permissions/ACL. Si vous comptez sur « personne ne mettra sharenfs n’importe comment », vous avez déjà perdu.

Checklists / plan étape par étape

Checklist 1: Introduire sharenfs en toute sécurité dans un environnement existant

1. Inventaire des exports actuels : capturez la sortie de exportfs -v et conservez-la.
2. Inventaire des propriétés de partage ZFS : zfs get -r sharenfs,sharesmb -o name,property,value,source.
3. Définissez une frontière de partage : choisissez un parent dataset autorisé à avoir des partages en dessous.
4. Définissez des valeurs par défaut sûres : mettez sharenfs=off et sharesmb=off sur les parents qui ne doivent jamais partager.
5. Décidez du plan de contrôle : auto-share sur les hôtes, outil générateur, ou configs explicites seulement.
6. Implémentez l’audit : alertez sur sharenfs=on hors de la frontière, et sur source=received.
7. Testez avec un dataset : activez le partage, confirmez son apparition dans la couche service, montez depuis un client test.
8. Déployez progressivement : migrez les exports un par un ; évitez de « basculer la propriété parent et prier ».

Checklist 2: Gérer la réplication vers un environnement non-autoritaires (DR/staging)

1. Sur le récepteur, désactivez l’auto-share sauf si vous avez une bonne raison de l’activer.
2. Après chaque réception, scannez les props reçues : zfs get -r -o name,property,value,source sharenfs,sharesmb.
3. Appliquez la politique : mettez automatiquement sharenfs=off/sharesmb=off là où les partages ne sont pas autorisés.
4. Documentez les exceptions : les quelques datasets qui doivent être exportables en DR (généralement aucun) doivent être explicites et revus.

Checklist 3: Déboguer une panne signalée (NFS/SMB)

1. Confirmez l’intention : le dataset est-il censé être partagé ? Vérifiez propriété et héritage.
2. Confirmez l’état du montage : dataset monté, mountpoint correct.
3. Confirmez la couche service : exportfs -v ou smbclient -L depuis le serveur.
4. Confirmez la reachabilité réseau : ports à l’écoute et règles pare-feu.
5. Confirmez le mapping d’identités : getent, ownership, comportement ACL.
6. Puis seulement, optimisez la performance ou touchez aux options obscures.

FAQ

1) Dois-je utiliser sharenfs/sharesmb en production ?

Oui, mais uniquement si vous êtes explicite sur le plan de contrôle. Pour les environnements multi-hôtes, utilisez-les comme métadonnées et appliquez
la politique via un générateur contrôlé ou une automatisation en liste blanche.

2) Pourquoi « zfs set sharenfs=on » n’exporte-t-il pas immédiatement sur mon hôte Linux ?

Parce que la propriété n’est pas le moteur d’export. Il vous faut la couche d’intégration (souvent une unité systemd comme zfs-share) et un serveur NFS en fonctionnement. Sans cela, ce n’est qu’une propriété stockée.

3) Puis-je exprimer des options d’export NFS à l’intérieur de sharenfs ?

Souvent oui, selon l’intégration plateforme. Mais une fois que vous le faites, vous créez un second langage d’exports. Standardisez les chaînes d’options, ou interdisez les options libres et n’autorisez que « on/off » plus une politique centralisée.

4) Comment savoir si une propriété de partage est héritée ou reçue ?

Utilisez zfs get -o name,property,value,source sharenfs,sharesmb. Si source est inherited ou received, traitez cela comme un risque plus élevé et validez-le.

5) Désactiver sharenfs garantit-il que le dataset n’est pas exporté ?

Non. Cela n’affecte que le chemin d’export contrôlé par ZFS. Le dataset peut toujours être exporté via /etc/exports explicite ou d’autres outils. Confirmez toujours avec exportfs -v.

6) Est-ce une bonne idée d’utiliser sharesmb sur Linux avec Samba ?

Généralement pas comme plan de contrôle faisant autorité, car Samba se configure via ses propres fichiers et outils. Utilisez sharesmb comme indice/métadonnée sauf si vous avez une intégration éprouvée qui génère la config Samba de manière fiable et sûre.

7) Quel est le plus grand risque de sécurité avec les propriétés de partage ?

L’héritage et la réplication. Une propriété parentale ou une propriété reçue peut exporter plus que prévu, et elle peut devenir active plus tard lorsque les services changent. Auditez les partages hérités/reçus et appliquez des frontières.

8) Comment empêcher le partage accidentel de nouveaux datasets enfants ?

Ne mettez pas le partage « on » sur un parent large sauf si ce parent est une frontière de partage délibérée. Privilégiez le partage explicite par dataset, et mettez sharenfs=off sur les parents sensibles comme garde-fou.

9) Pourquoi la navigation SMB montre-t-elle des partages étranges même quand les utilisateurs ne peuvent pas y accéder ?

La navigation reflète la configuration annoncée des partages, pas la réussite des permissions. Vous publiez peut-être des partages automatiquement sans ACLs/mapping d’identités adaptés. Corrigez la définition du partage et le modèle de permissions ; ne comptez pas sur « ils n’y ont de toute façon pas accès ».

10) Quelle est l’approche la plus simple et sûre pour une petite équipe ?

Laissez sharenfs/sharesmb désactivés par défaut, et gérez NFS/SMB explicitement. Si vous adoptez ensuite les propriétés, faites-le seulement dans un sous-arbre dédié et avec un job d’audit.

Conclusion : prochaines étapes réalisables cette semaine

1. Auditez maintenant : lancez zfs get -r sharenfs,sharesmb -o name,property,value,source et trouvez les surprises héritées/reçues.
2. Confirmez la vérité : comparez l’intention ZFS avec l’état des services en direct via exportfs -v et les outils Samba.
3. Choisissez un plan de contrôle : soit « auto-share ZFS fait autorité » (rare), soit « configs de service font autorité » (commun), soit « propriétés = métadonnées + générateur » (meilleur à l’échelle).
4. Tracez des frontières : décidez quel sous-arbre de datasets peut être partagé, et verrouillez le reste explicitement.
5. Rédigez le runbook : incluez les étapes de diagnostic rapide et les actions de re-share/reload requises par votre plateforme.

ZFS vous offre des primitives élégantes. Les propriétés de partage peuvent faire partie de cette élégance, mais la production ne récompense l’élégance que si elle est aussi lisible, auditée et ennuyeuse sous contrainte. Choisissez la commodité quand elle est réversible. Choisissez le contrôle là où elle ne l’est pas.