2026 OpenClaw Docker volumes & permissions
Config persistante, Skills en écriture & état après redémarrage

Lecture ~21 min · MACCOME

Les équipes qui font tourner OpenClaw Gateway sur Docker / Compose perdent rarement le plus de temps à tirer les images : elles le perdent quand les redémarrages, upgrades ou docker compose down effacent l’appariement et la config, ou quand les répertoires Skills sont en lecture seule avec un flot de Permission denied qui ne correspond pas aux entrées réseau du dépannage officiel. Cet article complète la triage réseau Docker, la triage doctor post-installation, le runbook Docker production & Gateway et les opérations Mac distant sans présence : six pièges volumes/permissions, deux tableaux persistance vs anti-patterns, une matrice symptôme→commande→correctif, extraits inspect à copier-coller, un runbook en six étapes et trois métriques tableau de bord. Ordre de triage : d’abord volumes et UID/GID, puis réseau et reverse proxies.

Transformer « ça se réinitialise après redémarrage » en six causes volumes prêtes pour l’ACR

Les images sont des gabarits immuables ; seul l’état écrit dans la couche inscriptible, les volumes anonymes ou des chemins non persistés disparaît. Capturez les signaux ci-dessous dans les tickets de changement et revoyez-les sur la même ligne que les révisions Compose et les tags d’image.

  1. Montages anonymes ou sans nom : Compose déclare des chemins conteneur sans binds hôte ; down -v ou les scripts de nettoyage suppriment les caches d’appariement même quand « rien n’a changé dans git ».
  2. Dérive des chemins bind sur Mac distants : les dossiers home, de sync ou points de montage temporaires bougent ; les binds pointent vers des répertoires vides ou des instantanés obsolètes pendant que le Gateway démarre encore.
  3. Décalage UID/GID : l’utilisateur processus dans le conteneur ne correspond pas au propriétaire hôte ; les hot-reload Skills ou écritures de logs échouent. Docker Desktop sur macOS et les hôtes Linux divergent—copier-coller Compose sans ajuster user est un échec fréquent.
  4. Mauvais usage du lecture seule : marquer config ou Skills :ro pour la « sécurité » bloque les caches de tokens ou l’état local attendu par l’exemple amont ; les échecs peuvent rester silencieux jusqu’au redémarrage.
  5. État uniquement dans la couche inscriptible : docker commit est tentant mais les upgrades ou changements de tag jettent quand même cette couche—éviter en production.
  6. Rédacteurs concurrents sans coordination : deux projets Compose expérimentaux bindent le même répertoire, corrompant le JSON ou écrivant la config à moitié.

Si la triage réseau montre encore un succès CLI intermittent mais un échec certain après redémarrage, revenez ici pour vérifier que les volumes nommés sont sur le disque attendu et que l’utilisateur processus peut écrire les Skills avant de toucher network_mode ou les proxies.

Tableau 1 : ce qu’OpenClaw doit persister dans Docker—et anti-patterns courants

Les sous-chemins suivent votre image et la doc ; le tableau cadré trois questions d’ingénierie : survit au cycle de vie du conteneur, nécessite une sauvegarde, partagé en lecture seule ? Consignez les réponses dans le README et les playbooks d’astreinte.

ClasseContenu typiquement persistéSchéma recommandéAnti-pattern
Config & matériel secretsPoints de terminaison Gateway, choix de fournisseur, chemins des tokens de canalBind hôte ou volume nommé ; droits limités à l’utilisateur d’exécutionCuire dans l’image ; stocker sous des répertoires nettoyés par des outils de sync
Exécution & appariementÉtat d’appariement d’appareil et restauration de sessionSous-arbre bind dédié ; tar avant upgradesVolumes anonymes non documentés dans Compose ; un seul prune efface tout
Skills / extensionsFichiers et scripts Skills de l’équipeBind à côté du repo ; chemins identiques en CI et prod:ro alors que les caches d’exécution doivent être en écriture ; UID ne peut pas écrire
Journaux & tamponsGros journaux, exportsVolume séparé ou chemin hôte avec rotationRemplir la couche inscriptible jusqu’à l’OOM ou un FS lecture seule inattendu

Tableau 2 : symptômes → vérifications → correctifs (volumes avant réseau)

Pendant les contrôles, journalisez les ID d’image, noms de projet Compose et noms de volumes dans la même session shell pour simplifier les rollbacks ; réutilisez la page checklist de release du runbook production.

SymptômeVérifier d’abordCorrectif typiqueSi ça échoue encore
Tout ressemble à une install fraîche après docker compose updocker inspect Mounts vs chemins hôte attendus ; nettoyage récent -vBinds explicites ou volumes nommés ; documenter si down peut utiliser -vVérifier que vous êtes dans le bon répertoire de projet Compose
Skills ignorés ou écritures en échecid dans le conteneur vs propriété hôte ls -lnAjuster user, chmod ou aligner l’UID dans Dockerfile/point d’entréeConfirmer que les montages ne sont pas :ro
Flux d’erreurs de permissionSELinux/AppArmor sur Linux ; partage de fichiers Docker Desktop sur macOSLinux : évaluer labels ou :z selon la baseline sécurité ; macOS : ajouter les chemins au partage de fichiersÉcarter un disque lecture seule avant de rouvrir la triage réseau
Partiellement fonctionnel après bump d’imageChangements de schéma de config ; ancien répertoire de données encore montéSuivre les notes de release ; sauvegarder avant upgradeLancer openclaw doctor contre les changements cassants documentés
bash
# 1) Les montages atteignent-ils les chemins hôte attendus ? (remplacer le conteneur)
docker inspect -f '{{ json .Mounts }}' <container> | jq .

# 2) Utilisateur d’exécution dans le conteneur (comparer à la propriété hôte)
docker exec -it <container> id

# 3) Projets Compose et volumes (éviter la dérive anonyme)
docker compose ls
docker volume ls | grep <project>

# 4) Exemple de sauvegarde bind avant upgrade (chemin selon convention d’équipe)
tar czf openclaw-state-$(date +%Y%m%d).tgz ./openclaw-data/
info

Note : Docker Desktop sur Mac distants garde en général les binds sous les répertoires home utilisateur ; les hôtes cloud Linux peuvent nécessiter d’autres lignes user et modèles de permissions. « Ça marche sur mon portable » n’équivaut pas à « ça marche sur des hôtes en pool ».

Runbook en six étapes : du « conteneur tourne » au « l’état survit redémarrage/upgrade »

  1. Tracer le plan de données : étiqueter config, exécution, Skills et binds de logs sur le schéma d’architecture ; fusionner avec le diagramme de service du runbook production.
  2. Interdire les volumes anonymes implicites : nommer dans Compose tout chemin qui doit survivre aux redémarrages ; le README doit indiquer ce que down -v détruit.
  3. Geler la politique UID/GID : choisir l’utilisateur conteneur, refléter la propriété ou les ACL sur l’hôte, et coder dans Ansible ou cloud-init pour les pools multi-hôtes.
  4. Sauvegarder avant upgrades : tarballs horodatés des racines bind ; noter anciens digests d’image et révisions Compose.
  5. Santé des volumes avant doctor : une fois les Mounts cohérents, lancer openclaw doctor et les sondes de canaux pour éviter les faux négatifs.
  6. Intégrer l’astreinte : l’étape un ouvre ce tableau plus le tableau 1 de l’article réseau—éviter les modifications parallèles réseau et stockage.

Trois métriques solides pour tableaux de bord et post-mortems

  1. Couverture des volumes : pourcentage des chemins persistés requis avec binds explicites ou volumes nommés ; la préprod n’est pas prête prod en dessous de 100 %.
  2. Taux d’échecs de permission : filtrer les logs conteneur pour Permission denied / EACCES ; corréler aux upgrades Gateway indique souvent les montages, pas les fournisseurs.
  3. Cadence de sauvegarde d’état : journaliser si chaque upgrade avait une archive ; un mode d’échec fréquent en 2026 : « l’upgrade a réussi mais personne n’a rappelé que le bind vivait sur un autre hôte. » Stocker les sauvegardes hors du disque Gateway pour respecter les RPO informels.

Tracer ces courbes à côté des métriques disque et logs de l’article Mac distant—les problèmes de volume apparaissent souvent comme disque qui dérape ou montages lecture seule avant les pics CPU.

Beaucoup d’équipes colocalisent Gateway et Skills sous un même arbre hôte en 2025–2026 ; sans quotas sur les sous-arbres purement logs, les logs peuvent remplir le bind et bloquer les écritures de config. Corriger la rotation ou scinder les volumes avant de recréer les conteneurs en boucle.

Distinguer aussi docker compose restart de down/up : le premier conserve en général les volumes déclarés ; le second, avec flags de nettoyage, change le sort des données—utiliser une antisèche de verbes partagée dans les runbooks.

Pourquoi les expériences Docker « portable seulement » évoluent rarement vers des Gateways sans présence

Les permissions portable mono-utilisateur diffèrent des hôtes distants en pool avec connexions automatisées ; veille, utilitaires de sync et éditions manuelles des binds rendent « ça marchait hier » non reproductible. Faire tourner OpenClaw comme plan de contrôle 24/7 exige des chemins contractuels, des upgrades réversibles et des permissions auditables.

Les boucles d’apprentissage sur matériel perso vont bien, mais le coût production apparaît comme bruit de pagers et canaux morts. Des conteneurs scratch éphémères sans montages stables multiplient les domaines de défaillance lors des upgrades. Les équipes qui ont besoin de Gateways toujours disponibles, propices aux sauvegardes et portables convergent souvent plus vite vers des empreintes Mac cloud pro avec bare metal Apple Silicon et choix multi-régions que vers l’ajustement infini de Docker perso. MACCOME propose des locations Mac mini M4 / M4 Pro multi-régions plus une aide publique—commencez par le centre d’aide et les tarifs de location, puis le checkout régional.

Conseil de déploiement : exécuter les contrôles du tableau 2 sur la même classe d’hôte que en production (Docker Desktop vs Linux) avant de câbler canaux et modèles—éviter la dérive UID et chemins « local OK, cloud KO ».

Si vous utilisez aussi Kubernetes, les pods recyclent plus souvent que les stacks Compose : tout ce qui n’est pas soutenu par un PVC disparaît lors des mises à jour rolling—la même règle de persistance explicite s’applique, à vérifier avec kubectl describe pvc et les manifests de montage.

FAQ

En quoi est-ce différent de l’article de triage réseau Docker ?

Le réseau couvre connectivité et espaces de noms ; cet article couvre si les données sont sur disque et en écriture. Pour les points d’entrée d’installation, voir le guide d’installation trois plateformes. Accès et tarifs : centre d’aide et tarifs de location.

Doctor ou volumes en premier ?

Volumes et permissions d’abord, puis doctor, pour éviter les faux positifs quand les conteneurs sont sans cesse recréés. Les détails WSL2 restent dans l’article doctor post-installation.

Comment cela s’associe-t-il aux opérations Mac distant ?

L’article sur les opérations Mac distant traite launchd/systemd, les journaux et la triage des blocages ; le présent article traite la persistance Docker et l’écriture. Les deux vont dans la même revue de changement et le même index d’astreinte.