Partition système NAS pleine — écart du/df caché dans des dossiers root (2026-07-20)

Symptôme

df -h / sur l'hôte NAS (Container Manager ou SSH direct) affiche /dev/md0 à 95%+ avec quelques dizaines/centaines de Mo restants. Attention : depuis le container mcp-nas, df -h / pointe sur /dev/mapper/cachedev_0 (le volume data, 11 To), pas sur la partition système — toujours ssh nas-host (ou SSH direct Best0f) pour voir la vraie partition /dev/md0 (~2,3 Go, taille fixe DSM, indépendante de la capacité totale du NAS).

Méthode de diagnostic

du exécuté sans sudo (compte Best0f) sous-estime toujours l'usage réel : les dossiers appartenant à root avec permissions restrictives (souvent 0700) sont ignorés silencieusement par du, pas seulement inaccessibles en lecture de contenu — le dossier entier est exclu du total.

Comparer le total réel : du -sx / 2>/dev/null vs le "Used" de df -h /. Un écart de plusieurs centaines de Mo = quasi certain que la cause est un dossier root illisible, pas une vraie saturation user.
Lister tous les dossiers refusés : du -sx / 2>&1 1>/dev/null | grep denied
Filtrer le bruit (configs/certs/logs système, quelques Ko chacun) et chercher les chemins avec beaucoup d'entrées groupées sous un même parent = signe d'un gros dossier applicatif, pas d'un fichier de config isolé.

Cause trouvée sur cette instance

/usr/lib/python3.8/site-packages en drwx------ root:root contenait une stack data-science/Streamlit complète (pandas, numpy, pyarrow, pillow, altair, pydeck, tornado, jupyter — l'empreinte typique des dépendances Streamlit) installée à la main début 2026 dans le Python système de base (pas un paquet Package Center — /var/packages/ ne liste que Python2 et Python3.9, pas 3.8). /usr/etc/jupyter et /usr/share/jupyter faisaient partie du même reliquat. Aucun process actif dessus (ps aux | grep -iE "jupyter|streamlit|python3.8" vide), aucun lien avec le stack actuel (n8n/Baserow/Hermes/Bifrost/context-hub) — prototype abandonné, poids mort pur.

Fix

sudo du -sh /usr/lib/python3.8/site-packages /usr/etc/jupyter /usr/share/jupyter 2>/dev/null  # confirmation avant suppression
sudo rm -rf /usr/lib/python3.8/site-packages/*
sudo rm -rf /usr/etc/jupyter /usr/share/jupyter
df -h /

Sans risque pour DSM : la stdlib Python vit ailleurs que site-packages (qui ne contient que des paquets tiers ajoutés manuellement) ; aucun script interne Synology ne dépend de pandas/pyarrow/jupyter pour fonctionner.

Résultat : /dev/md0 2,1 Go → 1,7 Go utilisés, 113 Mo → 529 Mo disponibles (95% → 77%).

Limite rencontrée

Best0f n'a pas de sudo sans mot de passe (sudo -n échoue), et ce mot de passe n'est jamais transmis à un agent (règle de sécurité permanente). claude-ops a du NOPASSWD mais scopé docker/compose/rsync/journalctl — pas de rm générique. Le diagnostic complet a pu être fait en lecture seule (Best0f), mais la suppression a nécessité l'exécution manuelle par Nabil en SSH direct.

Règle réutilisable

Sur toute alerte "partition système NAS pleine" : ne jamais conclure à une vraie saturation avant d'avoir comparé du -sx / (non-root) au Used de df -h /. Un écart important pointe presque toujours vers un dossier root oublié — chercher avec du -sx / 2>&1 1>/dev/null | grep denied avant toute action corrective (extension de volume, nettoyage agressif de logs, etc.).

3.4 KiB Raw Blame History