Les outils d’utilisation du disque peuvent être trompeurs sur un NAS, car un répertoire peut être soit un espace de stockage local ordinaire, soit l’emplacement où un autre système de fichiers est monté. Ce fil de janvier 2026 a commencé avec un disque ZimaOS de 1 To indiquant environ 915 Go utilisés, alors que l’utilisateur pensait ne disposer que d’environ 450 Go de fichiers multimédias. La première hypothèse concernait le cache Docker. La sortie de la commande indiquait plutôt /DATA/.media, où intervenaient des points de montage de sauvegarde et de stockage distant.
Mesurer avant de nettoyer Docker
La première réponse de la communauté suggérait d’examiner les dossiers les plus volumineux sous /DATA et de vérifier les propres données comptabilisées par Docker. C’était raisonnable, mais le résultat de l’utilisateur ne montrait qu’environ 2,1 Go sous l’arborescence Docker et environ 2 Go d’AppData.
Docker ne pouvait donc pas expliquer plusieurs centaines de gigaoctets manquants.
/DATA La partition était presque pleine.Le premier utilisateur a trouvé 424 Go sous /DATA/.media/UNTITLED 2
L’analyse de la taille indiquait environ 419 Go de fichiers multimédias ordinaires, auxquels s’ajoutaient 424 Go sous /DATA/.media/UNTITLED 2. L’utilisateur a reconnu ce nom comme celui du SSD précédemment utilisé comme destination de sauvegarde ZimaOS.
La difficulté venait du fait que le disque de sauvegarde physique n’était plus connecté.
Un point de montage peut devenir un simple dossier local
Sous Linux, les points de montage sont des répertoires. Lorsqu’un lecteur USB ou un partage SMB est monté, les accès au répertoire atteignent le système de fichiers externe. Si celui-ci disparaît et qu’une application continue d’écrire dans le même répertoire, ces écritures peuvent se retrouver sur le système de fichiers local sous-jacent.
C’est le scénario classique où l’on se demande : « Ma cible de sauvegarde est externe, alors pourquoi le disque système est-il plein ? »
Ne supprimez pas un répertoire .media avant de savoir s’il est monté
Le dépannage proposé dans la source recommandait des commandes de suppression destructives après vérification de l’état des montages. Cet ordre est important. Supprimer des fichiers d’une cible de sauvegarde montée peut effacer la véritable sauvegarde externe au lieu de récupérer des données locales masquées.
Comme la commande de suppression relevait des conseils de la communauté et non d’une instruction de l’assistance IceWhale, cette page ne la présente pas comme une procédure de nettoyage générique.
Un deuxième utilisateur reproduit le même phénomène après une panne de courant
Plus loin dans le fil, un autre utilisateur disposant d’une petite partition système/de données ZimaOS-HD a perdu tout l’espace libre restant après une panne de courant ayant interrompu une sauvegarde. Ses données brutes du la sortie paraissait énorme parce qu’elle comptait également les données RAID et SMB montées en dessous /DATA/.media.
Utilisez une analyse limitée au même système de fichiers pour séparer les données locales des montages
La communauté a recommandé une du une analyse qui reste sur le même système de fichiers afin d’exclure les partages réseau montés. Dans le deuxième cas, cela a révélé environ 30 Go de données réellement locales sous un répertoire nommé d’après une adresse IP à l’intérieur de /DATA/.media.
Le deuxième utilisateur a récupéré 30 Go
Après avoir confirmé que le répertoire nommé d’après l’adresse IP n’était pas un montage SMB actif et l’avoir identifié comme des données locales restées sous le point de montage, l’utilisateur a supprimé le contenu indésirable et a indiqué avoir récupéré 30 Go.
C’est le résultat confirmé le plus solide du fil.
La théorie de la communauté était que la sauvegarde écrivait alors que la cible n’était pas montée
Le répondant pensait que le processus de sauvegarde avait continué à écrire vers le chemin SMB prévu alors que le partage n’était pas correctement monté, ce qui avait amené Linux à écrire dans le répertoire local à la place.
La récupération confirmée de 30 Go confirme la présence de fichiers locaux sous le point de montage, mais l’hypothèse exacte concernant le problème de sauvegarde relevait d’un diagnostic de la communauté, et non d’une publication d’un ingénieur d’IceWhale dans ce fil.
La gestion actuelle des sauvegardes et du stockage dans ZimaOS a changé
La documentation actuelle de ZimaOS décrit les tâches de sauvegarde gérées et la gestion générale du stockage. Pour les nouvelles tâches, utilisez la procédure de sauvegarde actuelle de ZimaOS, puis vérifiez que la destination prévue est bien montée avant le début des écritures importantes.
Une procédure plus sûre pour retrouver l’espace manquant
- Utilisez
dfpour confirmer quel système de fichiers local est saturé. - Analysez uniquement ce système de fichiers afin que les montages SMB, USB et RAID ne gonflent pas les totaux.
- Vérifiez séparément Docker et AppData.
- Inspecter
/DATA/.mediapour les répertoires de points de montage qui contiennent réellement des fichiers locaux. - Confirmez que la cible n’est pas montée avant de supprimer quoi que ce soit sous un point de montage.
- Après le nettoyage, vérifiez l’espace libre et testez à nouveau la destination de sauvegarde.
Le cas des 424 Go du premier utilisateur était plus ambigu que celui des 30 Go récupérés ultérieurement
L’auteur du message original a constaté environ 424 Go dans un répertoire portant le nom du SSD de sauvegarde déconnecté et a pensé qu’il s’agissait de données redondantes. La discussion s’est ensuite orientée vers la vérification des montages et le nettoyage proposé, mais la récupération clairement vérifiée dans le fil vient de l’utilisateur ultérieur qui a récupéré 30 Go.
Cette distinction est importante, car un répertoire situé sous /DATA/.media peut représenter un montage actif, un point de montage obsolète ou de véritables fichiers locaux. Un même chemin en apparence n’implique pas la même action de nettoyage sûre sur tous les systèmes.
Utilisez df et du pour répondre à des questions différentes
df répond à la question « quel système de fichiers est réellement plein ? », tandis que du répond à la question « quels répertoires visibles contiennent des fichiers ? » Sur un NAS comportant des montages imbriqués, les deux outils peuvent sembler se contredire, car du peut parcourir d’autres systèmes de fichiers si on ne lui demande pas de s’en tenir au système local.
La discussion est devenue beaucoup plus claire seulement après que le dépannage a distingué le système de fichiers local ZimaOS-HD du contenu SMB et RAID monté.
Les pertes de courant inattendues rendent les problèmes de points de montage plus dangereux
Le cas ultérieur des 30 Go a commencé après une coupure de courant alors que des sauvegardes étaient en cours. Si une destination distante n’est pas remontée correctement après le démarrage, mais qu’une tâche de sauvegarde reprend ou est redémarrée, le chemin peut toujours exister comme un répertoire local ordinaire.
Pour les tâches de sauvegarde importantes, vérifiez que la destination est montée et accessible en écriture après un redémarrage ou une coupure de courant avant de supposer que l’ancien chemin pointe toujours vers la cible externe.
Ne supprimez pas manuellement overlay2 de Docker pour récupérer de l’espace
Au début de la discussion, les chemins overlay de Docker semblaient particulièrement visibles dans la sortie du système de fichiers. La communauté a expressément déconseillé de supprimer arbitrairement des fichiers de overlay2. La couche de stockage de Docker doit être gérée via Docker ou le cycle de vie de l’application, et non en supprimant des répertoires de couches au hasard.
ZimaOS affiche également désormais l’utilisation du stockage des applications
Les paramètres actuels des applications ZimaOS affichent l’espace de stockage consommé par les applications et permettent de nettoyer le cache pour les applications prises en charge. Cela aide à distinguer la croissance normale des applications des données situées sous un point de montage avant d’utiliser le terminal.
L’explication de l’emplacement où les applications ZimaOS actuelles stockent les données et le cache fournit une première cartographie plus sûre du système de fichiers.
FAQ sur l’espace manquant
Le stockage overlay2 de Docker était-il responsable des centaines de gigaoctets manquants du premier utilisateur ?
Non. Docker ne représentait qu’une petite fraction de l’espace utilisé dans la sortie publiée.
Pourquoi du peut-il signaler des téraoctets sur un disque local beaucoup plus petit ?
Il peut compter récursivement les systèmes de fichiers distants montés ou RAID, sauf si l’analyse est limitée au système de fichiers local.
Une récupération a-t-elle été confirmée ?
Oui. L’utilisateur suivant a récupéré 30 Go de données locales stockées sous un répertoire servant de point de montage SMB.
