runbook: partition systeme NAS pleine - cause python3.8 site-packages orpheline (resolu 20/07)

common/PROTOCOL-INFRA.md

@@ -157,3 +157,14 @@ Une réponse "success" d'un outil de modification (update_workflow, edit de jobs
 - Réseau : toujours `172.17.0.1:3232` depuis le container. Fichiers NAS lisibles/éditables via le mount `/mnt/docker` = `/volume1/docker`.
 - SSH `Best0f` par mot de passe : non fonctionnel depuis mcp-nas (pas de clé, `SSHPASS` ≠ mdp Best0f) — ne pas compter dessus.
 - Restart de containers sans docker CLI : **API Portainer** (creds `bestof` dans `.env`), `POST /endpoints/{id}/docker/containers/{id}/restart`.
+
+
+## 2026-07-20 — Partition système `/dev/md0` pleine (95%, 113 Mo restants) — résolu
+
+**Symptôme** : `df -h /` sur l'hôte NAS à 95%. Piège : depuis le container mcp-nas, `df -h /` pointe sur `/dev/mapper/cachedev_0` (volume data, 11 To) — toujours `ssh nas-host` pour voir la vraie partition système `/dev/md0` (~2,3 Go, taille fixe DSM).
+
+**Méthode** : `du -sx /` sans sudo (Best0f) sous-estime toujours l'usage réel — les dossiers `root` en permissions restrictives (souvent `0700`) sont exclus silencieusement du total, pas juste illisibles en contenu. Comparer `du -sx / 2>/dev/null` au "Used" de `df -h /` ; un écart de plusieurs centaines de Mo pointe vers un dossier root oublié. Lister les coupables : `du -sx / 2>&1 1>/dev/null | grep denied`.
+
+**Cause ici** : `/usr/lib/python3.8/site-packages` (`0700 root:root`) contenait une stack data-science/Streamlit complète (pandas, numpy, pyarrow, pillow, altair, jupyter) installée à la main début 2026 dans le Python système de base — pas un paquet Package Center, aucun process actif, aucun lien avec le stack actuel. Prototype abandonné.
+
+**Fix** : `sudo rm -rf /usr/lib/python3.8/site-packages/* /usr/etc/jupyter /usr/share/jupyter` → 2,1 Go → 1,7 Go utilisés, 113 Mo → 529 Mo disponibles (95% → 77%). Diagnostic fait en lecture seule par Best0f (sans sudo), suppression exécutée par Nabil (le mot de passe sudo Best0f n'est jamais transmis à un agent). Runbook détaillé : common/partition-systeme-nas-du-vs-df-permissions.md.

common/partition-systeme-nas-du-vs-df-permissions.md

@@ -0,0 +1,38 @@
+# 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.).