TrueNAS SCALE s’est imposé ces dernières années comme la référence open source pour construire un NAS performant en infra perso. Basé sur Debian Linux et propulsé par ZFS, il promet le meilleur des deux mondes : la robustesse d’un système de fichiers de niveau entreprise et la flexibilité d’une plateforme moderne avec conteneurs et applications intégrées. Sur le papier, c’est séduisant. Dans la pratique, c’est un peu plus nuancé — et c’est l’objet de cet article.

Après plusieurs mois d’utilisation, de migrations matérielles, de séances de debug nocturnes et quelques surprises inattendues, voici un retour d’expérience honnête sur TrueNAS SCALE Dragonfish dans un infra perso de taille intermédiaire.

Ce qu’est TrueNAS SCALE

TrueNAS SCALE est la branche Linux de la famille TrueNAS, développée par iXsystems. Elle se distingue de l’ancienne branche CORE (FreeBSD) par plusieurs aspects fondamentaux :

Base Linux/Debian — Le système repose sur Debian, ce qui ouvre la porte à un support matériel bien plus large que FreeBSD, notamment pour les cartes réseau et les contrôleurs RAID modernes.

ZFS natif — Le cœur du système reste ZFS, avec tout ce que cela implique : checksums sur les données, snapshots atomiques, compression transparente, déduplication, et une gestion du cache (ARC) qui peut avaler des dizaines de gigaoctets de RAM pour accélérer les lectures.

Applications intégrées — SCALE embarque un système d’applications basé sur des conteneurs, permettant de déployer des services directement sur le NAS sans VM dédiée.

Interface web moderne — L’UI a été entièrement repensée et couvre la quasi-totalité des opérations sans avoir à toucher un terminal.

Les avantages réels

ZFS : le vrai argument

C’est la raison principale de choisir TrueNAS plutôt qu’une solution concurrente. ZFS offre une protection des données à un niveau rarement atteint dans le monde grand public :

  • Chaque bloc de données est checksumé et vérifié à la lecture — une corruption silencieuse (bit rot) est détectée et corrigée automatiquement sur les pools redondants.
  • Les snapshots sont instantanés et ne coûtent rien en espace initial. Ils permettent de revenir en arrière sur n’importe quel dataset en quelques secondes.
  • L’ARC (Adaptive Replacement Cache) utilise la RAM disponible de façon intelligente. Sur une machine avec 32 Go de RAM, il n’est pas rare de voir 20+ Go utilisés en cache ZFS lors d’un transfert intensif — les débits s’en ressentent immédiatement. Et contrairement à d’autres systèmes, cette RAM n’est pas “perdue” : l’ARC est dynamique et libère de la mémoire si un processus en a besoin. Plus vous donnez de RAM à TrueNAS SCALE, plus il en profite — les performances de lecture s’améliorent proportionnellement, et c’est l’un des rares cas où ajouter quelques barrettes DDR3 d’occasion donne un retour sur investissement immédiatement mesurable en Mo/s.

Intégration réseau avancée

TrueNAS SCALE gère nativement le bonding réseau (LACP, Load Balance), les VLANs, et les interfaces dédiées par usage. Avoir une interface d’administration sur un VLAN management séparé et les partages sur un VLAN données dédié est parfaitement supporté via l’interface graphique.

Intégration Active Directory

Le support SMB avec Active Directory fonctionne globalement bien une fois configuré. Le NAS peut rejoindre un domaine et exposer des partages avec les ACL Windows standard, ce qui est indispensable dans un infra perso avec infrastructure Microsoft.

Les limitations qu’on ne vous dit pas toujours

La compatibilité matérielle des cartes réseau

C’est probablement le point le plus critique pour un infra perso qui recycle du matériel existant. TrueNAS SCALE étant basé sur Linux, il hérite de tous les problèmes historiques du kernel Linux avec certains chipsets réseau.

Realtek en particulier est à éviter autant que possible pour les interfaces qui transportent du trafic intensif. Le driver r8169/r8168 fonctionne souvent au démarrage mais peut se révéler instable sous charge soutenue — exactement ce qu’on demande à un NAS lors des sauvegardes nocturnes.

Les chipsets recommandés pour TrueNAS SCALE sont :

  • Intel (i210, i211, i217, i350) — support natif parfait, driver igb/e1000e irréprochable
  • Broadcom (BCM57xx, BCM5709) — gamme serveur, driver bnx2/tg3 très stable
  • Chelsio — excellent support Linux

La règle pratique : pour les interfaces de données et de bonding, investir 15-20€ dans une carte PCIe Intel ou Broadcom d’occasion évite beaucoup d’ennuis.

Le comportement de l’interface réseau après changement matériel

Sous Linux, les noms d’interfaces réseau sont déterminés par la position sur le bus PCIe. Si vous changez de carte mère ou déplacez des cartes entre slots, les noms changent (ex: enp2s0 devient enp8s0f0). TrueNAS conserve l’ancienne configuration qui ne correspond plus aux nouvelles interfaces — il faut la reconfigurer manuellement dans Network → Interfaces.

Ce n’est pas un bug, c’est le comportement normal de Linux, mais c’est un point à anticiper lors d’une migration matérielle pour ne pas se retrouver sans accès réseau au premier reboot.

L’intégration SMB/Active Directory : subtilités de démarrage

Lorsque TrueNAS est joint à un domaine Active Directory, le service SMB dépend de la connexion au contrôleur de domaine. Si la machine démarre avant d’avoir contacté le DC (timeout réseau, boot trop rapide), SMB se lance dans un état dégradé et les partages ne sont pas accessibles — tout en apparaissant comme “actifs” dans l’interface.

Symptôme typique : une alerte répétée du type WBC_ERR_WINBIND_NOT_AVAILABLE dans les notifications TrueNAS.

La solution consiste à configurer le service SMB pour qu’il attende explicitement la disponibilité du contrôleur de domaine avant de démarrer — une option qui n’est pas activée par défaut mais qui change tout dans la stabilité quotidienne.

Le workflow Test Changes → Save

Un point d’interface qui perd du temps à tout le monde la première fois : sur TrueNAS SCALE, les modifications réseau ne sont pas appliquées en cliquant simplement sur Save. Il faut obligatoirement passer par Test Changes puis confirmer pour que la configuration soit effectivement appliquée. Sans cette étape, les changements semblent sauvegardés mais ne sont pas pris en compte.

Nos chantiers : les réussites

Migration du bonding : de Load Balance à LACP

Le NAS était initialement configuré avec un bond réseau en mode Load Balance statique (round-robin) sur deux ports physiques. La migration vers le LACP dynamique (802.3ad) en coordination avec le switch manageable a considérablement amélioré la stabilité et la visibilité réseau.

La procédure est simple dans TrueNAS : Network → Interfaces → éditer le bond existant, changer le protocole vers LACP. Côté switch (H3C/Comware dans notre cas), configurer les ports correspondants en agrégation dynamique.

Résultat : les deux liens montés et stables, agrégation correctement négociée, débit effectif amélioré pour les transferts multi-flux.

Piège rencontré : TrueNAS est configuré par défaut en LACPDU Rate FAST (envoi de paquets de négociation toutes les secondes), alors que la plupart des switches sont en SLOW (toutes les 30 secondes). Cette différence de timer peut empêcher un des liens de monter correctement. Les flags de statut côté switch montraient un port en état Defaulted et Unselected — diagnostic classique d’un timer mismatch. La solution passe généralement par aligner le timer LACP des deux côtés.

Architecture réseau multi-VLAN

La configuration cible — et c’est une bonne pratique à adopter dès le départ — consiste à séparer le trafic sur deux interfaces distinctes :

  • Interface d’administration : un port dédié sur le VLAN management, avec une IP fixe. C’est par là qu’on accède à l’interface web et au SSH. Trafic très léger, tolérant aux contraintes de chipset.
  • Interface de données : le bond LACP sur le VLAN données, par où transitent tous les partages SMB/NFS et les sauvegardes. Doit être sur du matériel réseau de qualité.

Cette séparation apporte plusieurs avantages : isolation des flux, sécurité (l’interface admin n’est pas exposée sur le même réseau que les données), et la possibilité de modifier le bond de données sans risquer de perdre l’accès à l’interface de gestion.

Synchronisation de sauvegarde : la stratégie pull

L’objectif était de synchroniser automatiquement les données d’un serveur Windows vers le NAS chaque nuit. La première approche — un outil de synchronisation poussant depuis Windows vers TrueNAS — s’est révélée instable : problèmes de connexion SMB en début de nuit, timeouts, synchronisations partielles silencieuses.

Le pivot vers une approche pull depuis TrueNAS a tout résolu : un script bash sur le NAS monte le partage administratif Windows en CIFS, lance un rsync incrémental, démonte proprement, et envoie un mail HTML de récapitulatif. Ce script est planifié via cron.

Avantages de cette approche :

  • TrueNAS maîtrise le timing
  • Moins de dépendance à la stabilité SMB côté Windows
  • rsync gère nativement la reprise et l’incrémental
  • Le mail de récap donne une visibilité immédiate sur les résultats

Point d’attention : les permissions ZFS peuvent poser problème lors d’un rsync depuis un partage Windows. Les flags --no-perms --no-owner --no-group sont souvent nécessaires pour éviter des erreurs de permission qui bloquent la copie sans faire échouer clairement le script.

Nos chantiers : les déboires et surprises

Swap de carte mère : une transparence surprenante

Dans le cadre d’une cascade d’upgrades matériels, la carte mère du NAS a été remplacée — passage d’une plateforme LGA1155 à une LGA1150 avec un processeur plus récent. Les deux cartes réseau PCIe (dual-port pour le bond, mono-port pour l’admin) ont été physiquement transplantées dans le nouveau châssis.

Au premier démarrage : TrueNAS SCALE s’est lancé normalement, le pool ZFS a été reconnu immédiatement, les datasets sont remontés, les partages SMB sont devenus accessibles. Zéro manipulation sur la configuration de stockage.

C’est l’un des grands avantages de ZFS : le pool est attaché aux disques, pas à la machine. Vous pouvez changer de carte mère, déplacer les disques sur un autre système, et ZFS retrouve son état exact — transactions en cours comprises si un import propre est effectué. Pour un infra perso où le matériel évolue régulièrement, c’est une assurance non négligeable.

La seule friction a concerné le réseau — les noms d’interfaces avaient changé suite au swap (comportement normal de Linux, les noms sont dérivés de la position sur le bus PCIe) — mais la reconfiguration dans Network → Interfaces prend moins de cinq minutes.

Le serpent qui se mord la queue : l’histoire du Realtek

Ce NAS a connu trois cartes mères successives, et l’interface d’administration réseau a été le fil rouge — parfois rouge sang — de toute cette histoire.

Première carte mère : une Gigabyte avec un i7 de première génération. Le NIC intégré assurait l’interface d’admin sans le moindre souci. Tout allait bien.

Deuxième carte mère : migration vers une Gigabyte Z77 (LGA1155). C’est là que tout a déraillé. Le NIC intégré de la Z77 était un Realtek RTL8111, et sous TrueNAS SCALE, il s’est montré instable pour l’interface d’administration — comportement erratique, lien qui ne montait pas proprement. La solution de contournement : une carte PCIe Broadcom BCM5722 mono-port (récupération Dell) dédiée à l’admin, le NIC Realtek intégré désactivé dans le BIOS. Ça fonctionnait, mais c’était un workaround.

Troisième carte mère : migration vers une Gigabyte Z97-HD3 (LGA1150) avec un i7 de quatrième génération. Les deux cartes PCIe sont transplantées — la dual-port Broadcom BCM5709 pour le bond LACP données, et la BCM5722 mono pour l’admin. Mais après le swap, la BCM5722 remonte avec le lien physique signalé comme down dans TrueNAS, cause inconnue (câble pendant le chantier ? slot PCIe capricieux ?). En dépannage, le NIC intégré de la Z97-HD3 est activé.

Et là, la révélation : lspci | grep -i ethernet révèle un Realtek RTL8111 rev 06. Exactement le chipset source de tous les ennuis sur la Z77.

Le comble : il fonctionne parfaitement. La rev 06 du RTL8111 est bien supportée par le driver r8169 en usage modéré, et l’interface d’admin ne génère pas le trafic intensif qui met ce chipset en difficulté. La BCM5722 part en spare, le Realtek tourne en prod.

Morale : tous les Realtek ne se valent pas, et l’usage compte autant que le chipset. C’est le Realtek sous charge soutenue qui pose problème — pas le Realtek qui se contente de laisser passer quelques requêtes HTTP vers l’interface web.

Au-delà de l’infra perso : TrueNAS en environnement professionnel

Il serait réducteur de cantonner TrueNAS SCALE à l’usage personnel. La plateforme a également fait ses preuves dans un contexte professionnel, sur une architecture nettement plus exigeante.

Stockage partagé pour cluster Proxmox

Un déploiement notable, sur une version TrueNAS SCALE Dragonfish 24.x qui venait tout juste de sortir à l’époque : un serveur lame équipé de disques SAS de 600 Go montés en pool ZFS (RAIDZ1, équivalent fonctionnel d’un RAID 5), avec 96 Go de RAM dédiés à l’ARC. Ce serveur TrueNAS constituait la couche de stockage partagé d’un cluster Proxmox à trois nœuds, chaque lame disposant de 64 Go de RAM.

Les datastores étaient exposés via NFS et montés directement sur chaque nœud du cluster. Cette architecture permettait à Proxmox de gérer la haute disponibilité (HA) des machines virtuelles sur plusieurs niveaux :

En fonctionnement normal, les VM étaient réparties sur les trois nœuds selon des règles de préférence de positionnement — chaque VM avait son nœud d’affinité privilégié pour optimiser la répartition de charge au quotidien.

En cas d’arrêt planifié d’un nœud pour maintenance, les VM migraient automatiquement vers leurs nœuds de destination prioritaires, définis à l’avance pour chaque VM. Pas d’intervention manuelle, pas de temps d’arrêt visible pour les utilisateurs — Proxmox orchestrait les migrations à chaud, les disques virtuels restant accessibles en permanence depuis le stockage TrueNAS centralisé.

C’est précisément là que ZFS démontre toute sa valeur en production : les 96 Go de RAM transformaient le serveur en un cache massif, les lectures de disques virtuels étant servies quasi-intégralement depuis l’ARC. Les performances en lecture étaient remarquables pour du matériel HDD — et la stabilité sur la durée, y compris pendant les migrations à chaud, irréprochable.

Ce que cette expérience confirme : TrueNAS SCALE n’est pas qu’un outil d’enthousiaste. Avec le bon dimensionnement matériel — RAM généreuse, chipsets réseau sérieux, ZFS correctement configuré — il peut tenir un rôle de stockage partagé en production sans rougir face à des solutions commerciales bien plus coûteuses. Et sur une version aussi récente que Dragonfish à sa sortie, la stabilité était au rendez-vous.

Recommandations pratiques

Sur le matériel :

  • Préférer des cartes réseau Intel ou Broadcom pour les interfaces de données
  • Pour l’admin uniquement, un Realtek récent (RTL8111 v6+) est acceptable
  • Prévoir 16 Go de RAM minimum, mais ne pas hésiter à aller plus loin — l’ARC ZFS absorbe tout ce qu’on lui donne et le rend en performances. C’est probablement l’upgrade au meilleur rapport qualité/prix sur un NAS existant
  • Vérifier les slots PCIe disponibles sur la carte mère — certains partagent des lanes et ne se comportent pas comme attendu

Sur la configuration :

  • Séparer dès le départ les interfaces admin et données
  • Activer l’option d’attente du contrôleur de domaine si joint à un AD
  • Pour la synchronisation avec des sources Windows, préférer le pull rsync depuis TrueNAS au push depuis Windows
  • Ne jamais oublier le Test Changes avant de sauvegarder une config réseau
  • Pour rsync vers ZFS, penser aux flags de permissions si la source est un serveur Windows

Sur les attentes :

  • TrueNAS SCALE est un excellent outil mais nécessite un minimum de compréhension de Linux
  • La compatibilité matérielle est bien meilleure que FreeBSD (CORE) mais pas universelle
  • L’intégration Active Directory fonctionne mais demande une configuration soignée
  • Les applications intégrées sont pratiques pour les services légers, mais une VM dédiée reste préférable pour les services critiques

Conclusion

TrueNAS SCALE est, en 2026, l’une des meilleures solutions — aussi bien pour une infra perso que pour un environnement professionnel de taille intermédiaire — pour combiner robustesse, flexibilité et coût maîtrisé. ZFS seul justifie le choix, et l’interface web couvre 95% des besoins quotidiens sans ligne de commande.

Mais comme tout système puissant, il récompense ceux qui prennent le temps de comprendre son fonctionnement plutôt que ceux qui espèrent un plug-and-play parfait. Les chantiers documentés ici ont autant appris sur TrueNAS lui-même que sur les subtilités du réseau, des permissions Linux, et de la fiabilité matérielle.

Et parfois, la solution à un problème complexe, c’est un Realtek qui fonctionne très bien. L’ironie a son mot à dire dans toute infra perso qui se respecte.

Article rédigé suite à des expériences en conditions réelles — toute ressemblance avec des nuits de debug est parfaitement intentionnelle.