Teams, die OpenClaw Gateway auf Docker / Compose betreiben, verlieren selten die meiste Zeit beim Image-Pull. Sie verlieren sie, wenn Neustarts, Upgrades oder docker compose down Pairing und Konfiguration löschen oder Skills-Verzeichnisse nur lesbar sind und Permission denied-Spam ausgibt, der nicht zu den Netzwerkeinträgen in der offiziellen Fehlersuche passt. Dieser Artikel teilt die Arbeit mit Docker-Netzwerk-Triage, Doctor-Triage nach der Installation, Docker-Produktions- & Gateway-Runbook und unbeaufsichtigtem Remote-Mac-Betrieb: sechs Volume-/Berechtigungsfallen, zwei Tabellen für Persistenz versus Anti-Patterns, eine Symptom→Befehl→Fix-Matrix, kopierbare Inspect-Snippets, ein Sechs-Schritte-Runbook und drei Dashboard-Metriken. Triage-Reihenfolge: zuerst Volumes und UID/GID, danach Netzwerk und Reverse Proxies.
Images sind unveränderliche Vorlagen; nur Zustand in der beschreibbaren Schicht, anonymen Volumes oder nicht persistenten Pfaden verschwindet. Erfassen Sie die Signale unten in Change-Tickets und prüfen Sie sie auf derselben Linie wie Compose-Revisionen und Image-Tags.
down -v oder Aufräumskripte löschen Pairing-Caches, obwohl „sich in git nichts geändert hat“.user zu übernehmen ist ein typischer Fehler.:ro markieren blockiert Token-Caches oder lokalen Zustand, den das Upstream-Beispiel erwartet; Ausfälle können still bleiben bis zum Neustart.docker commit wirkt verlockend, doch Upgrades oder Tag-Wechsel verwerfen diese Schicht—für Produktion vermeiden.Wenn die Netzwerk-Triage weiterhin zeigt, dass die CLI zeitweise klappt, nach Neustart aber garantiert scheitert, kehren Sie hierher zurück und prüfen Sie, ob benannte Volumes auf der erwarteten Platte liegen und der Prozessbenutzer Skills beschreiben kann, bevor Sie network_mode oder Proxies anfassen.
Exakte Unterpfade folgen Ihrem Image und der Doku; die Tabelle rahmt drei Engineering-Fragen: überlebt es den Container-Lebenszyklus, braucht es Backup, gemeinsam nur lesbar? Antworten in README und On-Call-Playbooks festhalten.
| Klasse | Typischer persistenter Inhalt | Empfohlenes Muster | Anti-Pattern |
|---|---|---|---|
| Konfiguration & Secrets-Material | Gateway-Endpunkte, Provider-Auswahl, Pfade zu Channel-Tokens | Host-Bind oder benanntes Volume; Rechte auf Laufzeitbenutzer begrenzt | In das Image backen; unter von Sync-Tools geleerten Verzeichnissen ablegen |
| Laufzeit & Pairing | Geräte-Pairing und Sitzungs-Wiederherstellung | Eigener Bind-Unterbaum; tar vor Upgrades | Anonyme Volumes ohne Compose-Doku; ein prune löscht alles |
| Skills / Erweiterungen | Team-eigene Skill-Dateien und Skripte | Bind neben dem Repo; identische Pfade in CI und Prod | :ro, obwohl Laufzeit-Caches beschreibbar sein müssen; UID kann nicht schreiben |
| Logs & Puffer | Große Logs, Exporte | Separates Volume oder Host-Pfad mit Rotation | Beschreibbare Schicht füllen bis OOM oder unerwartetes read-only-FS |
Während der Checks Image-IDs, Compose-Projektnamen und Volumenamen in derselben Shell-Session protokollieren, um Rollbacks zu vereinfachen; die Release-Checklist-Seite aus dem Produktions-Runbook wiederverwenden.
| Symptom | Zuerst prüfen | Typischer Fix | Wenn es weiter scheitert |
|---|---|---|---|
Nach jedem docker compose up wirkt alles wie Neuinstallation | docker inspect Mounts vs. erwartete Host-Pfade; kürzliche -v-Bereinigung | Explizite Binds oder benannte Volumes; dokumentieren, ob down -v nutzen darf | Prüfen, ob Sie im richtigen Compose-Projektverzeichnis sind |
| Skills werden ignoriert oder Schreiben scheitert | id im Container vs. Besitz mit ls -ln auf dem Host | user, chmod oder UID in Dockerfile/Entrypoint angleichen | Sicherstellen, dass Mounts nicht :ro sind |
| Fluten von Berechtigungsfehlern | SELinux/AppArmor auf Linux; Dateifreigabe in Docker Desktop auf macOS | Linux: Labels oder :z gegen Sicherheitsbaseline bewerten; macOS: Pfade zur Dateifreigabe hinzufügen | Plattenweises read-only ausschließen, bevor die Netzwerk-Triage wieder geöffnet wird |
| Nach Image-Bump halb funktionsfähig | Konfigurationsschema-Änderungen; altes Datenverzeichnis noch gemountet | Release Notes folgen; vor Upgrade sichern | openclaw doctor gegen dokumentierte Breaking Changes laufen lassen |
# 1) Landen Mounts auf den erwarteten Host-Pfaden? (Container ersetzen)
docker inspect -f '{{ json .Mounts }}' <container> | jq .
# 2) Laufzeitbenutzer im Container (mit Host-Besitz vergleichen)
docker exec -it <container> id
# 3) Compose-Projekte und Volumes (anonyme Drift vermeiden)
docker compose ls
docker volume ls | grep <project>
# 4) Beispiel: Bind-Backup vor Upgrade (Pfad nach Teamkonvention)
tar czf openclaw-state-$(date +%Y%m%d).tgz ./openclaw-data/
Hinweis: Docker Desktop auf Remote-Macs hält Binds meist unter Benutzer-Homeverzeichnissen; Linux-Cloud-Hosts brauchen oft andere user-Zeilen und Berechtigungsmodelle. „Funktioniert auf meinem Laptop“ heißt nicht „funktioniert auf Pool-Hosts“. Unternehmen sollten prüfen, ob bind-gemountete Zustandsverzeichnisse personenbezogene Daten enthalten und ob Aufbewahrungs- und Löschfristen, Zugriffskontrollen sowie Verzeichnis von Verarbeitungstätigkeiten nach DSGVO diese Speicherorte und Datenaufbewahrung abdecken.
down -v zerstört.openclaw doctor und Channel-Probes ausführen, um falsch negative Ergebnisse zu vermeiden.Permission denied / EACCES filtern; Korrelation mit Gateway-Upgrades deutet meist auf Mounts, nicht auf Provider.Diese neben Platten- und Log-Metriken aus dem Remote-Mac-Artikel plotten—Volume-Probleme zeigen sich oft als Plattenlauf oder read-only-Mounts vor CPU-Spikes.
Viele Teams legen Gateway und Skills 2025–2026 unter einen Host-Baum; ohne Quotas auf reinen Log-Unterbäumen können Logs den Bind füllen und Konfigurationsschreiben blockieren. Rotation oder getrennte Volumes, bevor endlos Container neu erstellt werden.
Unterscheiden Sie docker compose restart von down/up: Ersteres behält deklarierte Volumes meist; Letzteres mit Aufräum-Flags ändert das Schicksal der Daten—gemeinsames Verb-Cheatsheet in Runbooks.
Einbenutzer-Laptop-Berechtigungen unterscheiden sich von gepoolten Remote-Hosts mit Automatisierungs-Logins; Sleep, Sync-Tools und manuelle Bind-Edits machen „gestern ging es“ nicht reproduzierbar. OpenClaw als 24/7-Steuerungsebene braucht vertraglich festgelegte Pfade, reversible Upgrades und auditierbare Berechtigungen.
Lernschleifen auf persönlicher Hardware sind in Ordnung, Produktionskosten zeigen sich als Pager-Lärm und tote Channels. Ephemere Scratch-Container ohne stabile Mounts vervielfachen Fehlerdomänen bei Upgrades. Teams, die immer verfügbare, backup-freundliche, portable Gateways brauchen, kommen oft schneller bei professionellen Mac-Cloud-Footprints mit Apple-Silicon-Bare-Metal und Multi-Region-Wahl an als beim endlosen Tweaken privater Docker-Setups. MACCOME bietet Mac Mini M4 / M4 Pro-Mieten über Regionen hinweg plus öffentliche Hilfe—starten Sie mit Hilfe-Center und Mietpreisen, dann regionales Checkout.
Rollout-Tipp: Tabellen-2-Checks auf derselben Host-Klasse wie in Produktion (Docker Desktop vs. Linux) fahren, bevor Channels und Modelle verkabelt werden—UID- und Pfad-Drift „lokal ok, Cloud kaputt“ vermeiden.
Wenn Sie zudem Kubernetes betreiben, recyceln Pods häufiger als Compose-Stacks: Alles ohne PVC verschwindet bei Rolling Updates—dieselbe explizite Persistenzregel gilt, nur mit kubectl describe pvc und Mount-Manifesten verifizieren.
FAQ
Worin unterscheidet sich das von der Docker-Netzwerk-Triage?
Netzwerk behandelt Erreichbarkeit und Namespaces; dieser Artikel, ob Daten auf der Platte liegen und beschreibbar sind. Für Installations-Einstiege den Drei-Plattformen-Installationsleitfaden nutzen. Zugang und Preise: Hilfe-Center und Mietpreise.
Zuerst doctor oder Volumes?
Zuerst Volumes und Berechtigungen, dann doctor, um falsch positive Ergebnisse durch ständig neu erstellte Container zu vermeiden. WSL2-Details bleiben im Doctor-Artikel nach der Installation.
Wie passt das zum Remote-Mac-Betrieb?
Dort geht es um launchd/systemd, Logs und Hang-Triage; hier um Docker-Persistenz und Beschreibbarkeit. Beides gehört in dieselbe Change-Review und denselben On-Call-Index.