39 lines
3.4 KiB
Markdown
39 lines
3.4 KiB
Markdown
# 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.
|
|
|
|
1. 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.
|
|
2. Lister tous les dossiers refusés : `du -sx / 2>&1 1>/dev/null | grep denied`
|
|
3. 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
|
|
|
|
```bash
|
|
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.).
|