OpenClaw auf der Synology DiskStation installieren

Was ist OpenClaw – und was wirst du am Ende haben?

OpenClaw ist ein KI-Agent, den du lokal auf deiner Synology DiskStation betreibst. Statt in der Cloud läuft er bei dir zu Hause – du behältst die Kontrolle über deine Daten, zahlst nur für die tatsächlich genutzten API-Anfragen und erreichst deinen persönlichen Assistenten per Telegram oder Browser.

Am Ende dieser Anleitung hast du:

Einen laufenden OpenClaw-Container auf deiner DiskStation
Einen Telegram-Bot, dem du auf deinem Smartphone einfach schreiben kannst
Eine optionale Web-Oberfläche, erreichbar per SSH-Tunnel im Browser
Optional: Netzwerk-Isolation, die dem Container den Zugriff auf dein Heimnetz verwehrt
Optional: Einen eingebetteten Browser, mit dem OpenClaw auch JavaScript-lastige Webseiten bedienen kann

Die Grundinstallation – Container läuft, Telegram antwortet – dauert etwa 30 Minuten. Die optionalen Schritte kommen danach, wenn das Fundament steht.

Voraussetzungen

Bevor du anfängst – stelle sicher, dass du das Folgende zur Hand hast:

Synology DS1621+ mit aktuellem DSM 7.2 oder neuer
Container Manager installiert (aus dem Paket-Zentrum)
SSH-Zugang zur DiskStation (wird in dieser Anleitung erklärt)
Einen API-Schlüssel von Anthropic (Claude) oder OpenAI
Telegram auf dem Smartphone

Noch kein API-Key? Für Claude gehe auf console.anthropic.com, melde dich an, hinterlege eine Zahlungsmethode und erstelle einen Schlüssel. Er beginnt mit sk-ant-...

Architektur auf einen Blick

So sieht die fertige Ordnerstruktur auf deiner DiskStation aus. Sie entsteht Schritt für Schritt – du musst nichts manuell vorbereiten.

/volume1/docker/openclaw/
├── compose.yaml             ← Container-Konfiguration (Berechtigungen, Netzwerk, Volumes)
├── openclaw-firewall.sh     ← Netzwerk-Isolation (optional, aber empfohlen)
├── config/                  ← API-Keys, Einstellungen (wird beim Onboarding befüllt)
└── workspace/               ← Arbeitsdateien des Agenten

OpenClaw besteht aus zwei Diensten, die in der compose.yaml definiert sind:

openclaw-gateway – der dauerhaft laufende Dienst. Er hält die Verbindung zu Telegram, stellt die Web-UI bereit und kommuniziert mit der KI-API.
openclaw-cli – ein Einmal-Container für Verwaltungsaufgaben (Onboarding, Konfiguration, Pairing). Er startet auf Abruf und beendet sich danach selbst.

Container oder VM? Die erste große Entscheidung

Um diese Anleitung verständlicher zu machen, begleiten dich drei Personen:
Die typischen Büro-Charaktere: Die kompetente IT-Kollegin, der selbsternannte Experte und der ehrliche Anfänger. Diese drei Perspektiven helfen dir, typische Stolperfallen zu erkennen.
Tanja ist die IT-Expertin. Sie weiß, wie es funktioniert, erklärt geduldig und strukturiert – und lässt sich von schlechten Ratschlägen nicht aus der Ruhe bringen. Wenn du eine Frage hast, hat Tanja die Antwort.
Bernd ist der selbsternannte „Experte“, der alles besser weiß – und meistens falsch liegt. Seine Abkürzungen und sein Halbwissen führen regelmäßig zu Problemen. Er steht für alle gefährlichen Mythen und schlechten Praktiken, die du vermeiden solltest.
Ulf ist der Lernende, genau wie du. Er stellt die Fragen, die dir im Kopf herumschwirren, und braucht manchmal einen Vergleich aus dem Alltag, um IT zu verstehen. Wenn Ulf etwas nicht versteht, ist das völlig in Ordnung, dafür ist Tanja da.

„Und… Action!“

Es ist Montagmorgen. Bernd steht vor dem Whiteboard, Marker in der Hand, und hat „VM“ in Großbuchstaben hingeschrieben. Er lehnt sich zurück, faltet die Arme, sieht sehr zufrieden aus.
Bernd: „VM. Immer VM. Sicherer. Professioneller. Echte Admins nehmen VMs. Ende der Diskussion.“
Ulf: „Was ist nochmal der Unterschied? VM klingt nach VfL Mönchengladbach.“
Tanja: „Stell dir eine VM vor wie ein komplett eingerichtetes Fußballstadion – eigene Umkleide, eigener Rasen, eigene Kantine. Ein Docker-Container dagegen ist nur der Spieler mit seinen Fußballschuhen. Kein eigenes Stadion, aber er läuft deutlich schneller auf den Platz.“
Bernd: „Eben! Deshalb VM – wegen der Isolation!“
Tanja: „Das stimmt halb, Bernd. Eine VM bietet bessere Kernel-Isolation. Aber OpenClaw wurde als Docker-Applikation gebaut – mit fertigem Dockerfile und docker-compose.yml im Repo. Den Container-Weg wählen wir hier. Und wer wirklich maximale Isolation will, kann OpenClaw auch innerhalb einer VM per Docker Compose installieren – der Rest der Anleitung bleibt dann identisch.“

Kriterium	Container (Docker)	VM (Synology VMM)
Performance	Besser – kein komplett eigener OS-Kernel nötig	Schlechter – braucht ca. 2 GB RAM Minimum
Installation	Einfach – docker-compose.yml liegt fertig vor	Aufwändig – OS installieren, Node ≥22 einrichten, Autostart konfigurieren
Isolation	Prozess-Isolation auf Kernel-Ebene	Vollständige Kernel-Isolation, kein direkter Host-Zugriff
Zusammenfassung	Performanter, leichter, näher an der offiziellen OpenClaw-Installation	Stärkere Isolation, aber schwerer und ressourcenintensiver

Diese Anleitung geht den Container-Weg. Die zusätzlichen iptables-Regeln im optionalen Sicherheitskapitel reduzieren das Risiko, dass ein kompromittierter Container interne Geräte im Heimnetz erreicht. Sie ersetzen jedoch keine VM-Isolation, kein Patch-Management und keine sorgfältige Prüfung der eingesetzten Container-Images.

Teil 1: Vorbereitung auf der DiskStation

Schritt 1.1: Container Manager installieren

Ulf: „Container Manager – ist das so eine Art Transfer-Manager für Docker-Spieler?“
Tanja: „Fast! Container Manager ist die grafische Oberfläche auf deiner DiskStation, über die du Docker-Container startest, stoppst und überwachst. Ohne ihn läuft gar nichts.“
Bernd: „Hab ich nie gebraucht. Ich mach das alles per SSH. Echter Admin braucht keine GUI.“
Tanja: „Bernd, du hast letzten Monat versehentlich alle Container gelöscht, weil du dich in der IP vertippt hast.“

Öffne die DiskStation-Oberfläche im Browser.
Öffne das Paket-Zentrum.
Suche nach Container Manager.
Klicke Installieren – falls nicht bereits vorhanden.

Schritt 1.2: SSH aktivieren

SSH (Secure Shell) ist dein verschlüsselter Tunnel direkt in die DiskStation. Statt für jeden Befehl durch die Weboberfläche zu klicken, kannst du Befehle direkt eintippen – wie eine Direktverbindung zum Herzstück deines Servers.

Bernd: „Ich hab SSH dauerhaft offen und Port 22 direkt ins Internet weitergeleitet. Effizienter.“
Tanja: „… Das machen wir nicht. SSH ist hier nur für die Verbindung im lokalen Netzwerk gedacht.“

Öffne die Systemsteuerung.
Gehe zu Terminal & SNMP.
Setze den Haken bei SSH-Dienst aktivieren.
Port bleibt auf 22.
Klicke Übernehmen.

Schritt 1.3: Per SSH verbinden

Jetzt verbindest du dich zum ersten Mal mit deiner DiskStation über das Terminal. Keine Sorge – das ist kein schwarzer Bildschirm aus einem Hacker-Film. Es ist nur ein Textfenster, in dem du Befehle tippst.

Auf dem Mac (Programme → Dienstprogramme → Terminal):

ssh dein-benutzername@deine_NAS_IP

Auf Windows (Windows-Taste, cmd, Enter):

ssh dein-benutzername@deine_NAS_IP

Die IP-Adresse deiner DiskStation findest du in DSM unter Systemsteuerung → Netzwerk → Netzwerkschnittstelle.

Schritt 1.4: Ordner anlegen

Nach dem ersten Login wechselst du zu root. Ohne root-Rechte darfst du keine Ordner in /volume1/ anlegen.

Ulf: „Root, ist das der Kapitän des Systems?“
Tanja: „Root ist der Admin aller Admins. Auf einem Linux-System darf root alles. Wir brauchen root jetzt für die Ordner – danach läuft der Container aber bewusst nicht als root.“

Nachdem du per SSH verbunden bist:

# Zu root wechseln
sudo -i

# Ordner erstellen
mkdir -p /volume1/docker/openclaw/config
mkdir -p /volume1/docker/openclaw/workspace

# Rechte setzen
chown -R 1000:1000 /volume1/docker/openclaw
chmod -R 755 /volume1/docker/openclaw

Warum 1000:1000? Das ist die User-ID, unter der der Container später läuft. Indem du die Ordner schon jetzt auf diesen Nutzer setzt, hat der Container die nötigen Schreibrechte – ohne Administratorrechte zu benötigen.

Soll-Ergebnis – so prüfst du, ob es geklappt hat:

ls -la /volume1/docker/openclaw/

Du solltest sehen, dass beide Unterordner (config, workspace) dem Benutzer mit UID 1000 gehören:

drwxr-xr-x  1000 users  config/
drwxr-xr-x  1000 users  workspace/

Schritt 1.5: compose.yaml erstellen

Jetzt wird es konkret. Die compose.yaml ist das Herzstück: Hier steht alles drin, was der Container braucht – Berechtigungen, Netzwerk, Volumes, Sicherheitseinstellungen.

Ulf: „Compose.yaml – ist das wie der Aufstellungszettel vor dem Anpfiff?“
Tanja: „Genau so! Stell dir vor: Der Trainer schreibt auf, wer spielen darf, welche Position er hat, und was verboten ist. Genau das macht die compose.yaml für deinen Container.“
Bernd: „Ich mach das alles ohne Compose-Datei. docker run mit zehn Flags ist viel flexibler.“
Tanja: „Und wenn du beim nächsten Neustart die Flags nicht mehr weißt?“
Bernd: „…dann fang ich halt neu an.“

Immer noch in der SSH-Sitzung als root. Kopiere den kompletten Block und füge ihn im Terminal ein:

cat > /volume1/docker/openclaw/compose.yaml << 'DATEIENDE'
services:
  openclaw-gateway:
    image: ghcr.io/openclaw/openclaw:latest
    container_name: openclaw-gateway
    restart: unless-stopped
    user: "1000:1000"
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /tmp
      - /run
    pids_limit: 256
    dns:
      - 1.1.1.1
      - 8.8.8.8
    networks:
      - openclaw-isolated
    ports:
      - "18789:18789"
    volumes:
      - /volume1/docker/openclaw/config:/home/node/.openclaw
      - /volume1/docker/openclaw/workspace:/home/node/.openclaw/workspace
    environment:
      - HOME=/home/node
      - TERM=xterm-256color
      - NODE_ENV=production
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://127.0.0.1:18789/ >/dev/null 2>&1 || exit 1"]
      interval: 60s
      timeout: 10s
      retries: 3
      start_period: 30s
    init: true
    command:
      [
        "node",
        "dist/index.js",
        "gateway",
        "--bind",
        "lan",
        "--port",
        "18789",
      ]

  openclaw-cli:
    image: ghcr.io/openclaw/openclaw:latest
    container_name: openclaw-cli
    user: "1000:1000"
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    network_mode: "service:openclaw-gateway"
    volumes:
      - /volume1/docker/openclaw/config:/home/node/.openclaw
      - /volume1/docker/openclaw/workspace:/home/node/.openclaw/workspace
    environment:
      - HOME=/home/node
      - TERM=xterm-256color
      - NODE_ENV=production
    stdin_open: true
    tty: true
    init: true
    entrypoint: ["node", "dist/index.js"]
    profiles:
      - cli

networks:
  openclaw-isolated:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.0.0/24
          gateway: 172.30.0.1
DATEIENDE

Was bedeuten die wichtigsten Einstellungen?

Einstellung	Bedeutung
`user: "1000:1000"`	Container läuft nicht als root – kein Administratorzugriff.
`cap_drop: ALL`	Alle Linux-Sonderrechte (Capabilities) werden entzogen.
`read_only: true`	Root-Dateisystem schreibgeschützt – Schadsoftware kann sich nicht dauerhaft festsetzen.
`tmpfs: /tmp, /run`	Temporärer Speicher im Arbeitsspeicher für Programme, die dort schreiben müssen.
`pids_limit: 256`	Maximal 256 Prozesse – Schutz gegen Fork-Bombs.
`dns: 1.1.1.1 / 8.8.8.8`	DNS-Anfragen gehen direkt ins Internet. Ohne diese Einstellung würden sie zum Router laufen – der wird durch die optionale Firewall blockiert und der Container hätte kein Internet.
`"18789:18789"`	Web-UI erreichbar auf Port 18789.
Kein `docker.sock`Volume	Container kann Docker und Host nicht steuern.
`subnet: 172.30.0.0/24`	Festes Subnetz, das im optionalen Firewall-Kapitel gezielt geblockt werden kann.

Soll-Ergebnis – Datei validieren:

docker compose -f /volume1/docker/openclaw/compose.yaml config

docker compose config validiert die Datei und gibt sie normalisiert aus. Das ist verlässlicher als ein reines cat. Du solltest eine vollständige, fehlerfreie YAML-Ausgabe sehen. Eine Fehlermeldung wie mapping values are not allowed here weist auf Einrückungsfehler hin – dann den cat-Block aus dem vorigen Schritt nochmals einfügen.

Schritt 1.6: OpenClaw Onboarding durchführen

Das Onboarding ist ein interaktiver Einrichtungsassistent. Er fragt dich nach API-Key, Modell und Kommunikationskanal – und schreibt danach eine fertige Konfigurationsdatei ins config/-Verzeichnis. Dieser Schritt muss per SSH erledigt werden, weil der Assistent eine direkte Terminalverbindung braucht.

Bernd: „Ich hab einfach das Image gezogen und gestartet. Lief sofort.“
Tanja: „Und dann?“
Bernd: „Dann kam eine Fehlermeldung. Aber das ist normal.“
Tanja: „Das ist nicht normal. Das ist fehlende Konfiguration. Deshalb machen wir das Onboarding vor dem ersten Start.“

cd /volume1/docker/openclaw
docker compose run --rm openclaw-cli onboard

Der Assistent führt dich durch folgende Schritte:

Schritt 1 – Sicherheitshinweise bestätigen

Eingabe: Yes

Schritt 2 – Onboarding-Modus wählen

Eingabe: QuickStart
QuickStart ist der geführte Einrichtungspfad für neue Installationen. Er fragt nur das Nötigste ab und überspringt erweiterte Konfigurationsoptionen.

Schritt 3 – KI-Anbieter und Modell wählen

Ulf: „Welchen Provider soll ich nehmen? Ist das wie die Wahl zwischen Bundesliga und Champions League?“
Tanja: „Die Wahl beeinflusst Qualität und Kosten. Hier ein Überblick:“

Modell	Input (pro Mio. Token)	Output (pro Mio. Token)
OpenAI GPT-4.1 nano	~$0.10	~$0.40
OpenAI GPT-4.1 mini	~$0.40	~$1.60
Anthropic Haiku 3.5	~$0.80	~$4.00
OpenAI GPT-4o	~$2.50	~$10
Anthropic Sonnet 4	~$3.00	~$15

(Stand Februar 2026)

Für einen Chat-Assistenten im Heimgebrauch reden wir bei beiden Anbietern eher über Cent-Beträge pro Gespräch. Der Unterschied ist in der Praxis gering.

Empfehlung: Nimm Anthropic, weil Claude bei längeren Gesprächen und komplexen Anweisungen qualitativ oft stärker ist. Wähle Haiku wenn du sparen möchtest, Sonnet wenn du Qualität willst. Du kannst das jederzeit wechseln. Falls dir vor allem der günstigste Preis wichtig ist: OpenAI mit GPT-4.1 mini oder nano.

Falls du noch keinen API-Key hast: Für Claude gehe auf console.anthropic.com. Falls du das gerade nicht einrichten willst: Wähle Back, dann Skip for now. Du kannst den Provider später nachrüsten:

cd /volume1/docker/openclaw
docker compose run --rm openclaw-cli configure

Schritt 4 – Authentifizierungsmethode

Eingabe: Anthropic API key

Schritt 5 – API-Key eingeben

Deinen sk-ant-...-Schlüssel eingeben.

Schritt 6 – Standardmodell bestätigen

Eingabe: Keep current (claude-sonnet-4-6)

Modell	Stärke	Relative Kosten
Haiku	Schnell, günstig – für einfache Aufgaben	~1/4 von Sonnet
Sonnet	Bestes Preis-Leistungs-Verhältnis	Mittel
Opus	Am leistungsfähigsten – für komplexe Aufgaben	~5× Sonnet

Schritt 7 – Kommunikationskanal wählen

Eingabe: Telegram (Bot API)
Telegram ist der empfohlene Kanal für die Smartphone-Nutzung. Du hast auch Synology Chat als Option. Falls du dir unsicher bist: Wähle Skip for now – Kanäle lassen sich jederzeit nachrüsten.

Schritt 8 – Telegram Bot einrichten

Falls du Telegram gewählt hast, brauchst du einen Bot-Token:

Öffne Telegram und suche den Kontakt @BotFather.
Schreibe ihm: /newbot
Vergib einen Anzeigenamen (frei wählbar, z.B. „MeinOpenClaw“) und einen Benutzernamen (muss einmalig auf Telegram sein, muss auf bot enden, z.B. meinopenclaw_bot).
BotFather gibt dir einen Bot-Token – eine lange Zeichenkette. Den gibst du jetzt im Onboarding-Assistenten ein.

Schritt 9 – Skills konfigurieren

Eingabe: No
Skills sind optionale Zusatzmodule (Browser-Automation, Kalender, Notizen etc.). Sie laden jeweils eigene Software nach und können bei unserem schreibgeschützten Container Konflikte verursachen. Die Kernfunktion – per Telegram mit Claude chatten – funktioniert ohne Skills. Einzelne Skills lassen sich später gezielt nachrüsten.

Schritte 10 – 15 Weitere API-Keys (Google Places, Gemini, Notion, OpenAI-Image, Whisper, ElevenLabs)

Alle mit No beantworten. Das sind optionale Skills für spezielle Anwendungsfälle.

Schritt 16 – Hooks aktivieren

Eingabe: Skip for now
Hooks sind Automatisierungen, die bei bestimmten Ereignissen ausgelöst werden. Für den Start nicht nötig.

Das Onboarding ist abgeschlossen!

Wichtig: Schreibe dir den Gateway Token auf, der am Ende des Onboardings angezeigt wird. Er sieht so aus:

#token=2bbea678f.........................67003d38

Du brauchst ihn für die optionale Web-Oberfläche. Schreib ihn jetzt auf.

Bevor du den Gateway zum ersten Mal startest, ein notwendiger Konfigurationsschritt. Ohne ihn startet der Gateway mit einem Fehler:

cd /volume1/docker/openclaw
docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins '["http://localhost:18789"]'

Was ist allowedOrigins? Das ist eine Sicherheitseinstellung, die festlegt, von welchen Adressen aus die Control UI – die Web-Oberfläche des Gateways – aufgerufen werden darf. Ohne diese Freigabe verweigert OpenClaw den Zugriff, weil die Web-UI über localhost (per SSH-Tunnel) erreichbar ist, was standardmäßig nicht erlaubt ist.

Schritt 1.7: Container starten

Variante A: Über Container Manager

Öffne Container Manager in der DiskStation-Oberfläche.
Gehe zu Projekt.
Klicke Erstellen.
Projektname: openclaw
Pfad: /volume1/docker/openclaw
Container Manager zeigt die compose.yaml an → Weiter → Erstellen.

Der erste Download des Images dauert erfahrungsgemäß rund 8 Minuten. Wenn du Container Manager verwendest und das Projekt vor dem Onboarding erstellt hast: Container Manager startet das Projekt sofort nach dem Erstellen. Der Container meldet dann „Missing config“ und beendet sich. Das ist kein Fehler – stoppe das Projekt, führe das Onboarding durch (Schritt 1.6), und starte dann neu.

Variante B: Per SSH

cd /volume1/docker/openclaw
docker compose up -d openclaw-gateway

Soll-Ergebnis – so prüfst du, ob der Container läuft:

# Läuft der Container?
docker ps --filter name=openclaw-gateway

# Was sagen die Logs?
docker logs openclaw-gateway --tail 50

Was du sehen solltest:

[gateway] listening on ws://0.0.0.0:18789
[telegram] starting provider (@dein_botname)

Was normale Erststart-Meldungen sind (kein Fehler):

[warn] pids_limit discarded – der Synology-Kernel unterstützt dieses Feature nicht, es wird ignoriert.
Was ein echter Fehler ist:
Missing config → Onboarding (Schritt 1.6) nicht abgeschlossen.
non-loopback Control UI requires allowedOrigins → den config set-Befehl am Ende von Schritt 1.6 nachholen.
Error: EACCES: permission denied → Ordnerrechte prüfen (chown -R 1000:1000 /volume1/docker/openclaw).

Schritt 1.8: Telegram testen

Beim allerersten Mal antwortet dein Bot mit einem Pairing-Code. Pairing bedeutet: Du bestätigst einmalig, dass dieses Gerät (dein Smartphone) berechtigt ist, mit dem Bot zu chatten. Ohne diese Bestätigung antwortet der Bot nicht.
Schreibe dem Bot irgendetwas in Telegram. Er antwortet mit einem Code. Dann in der SSH-Sitzung:

cd /volume1/docker/openclaw
docker compose run --rm openclaw-cli pairing approve telegram <CODE>

Den Code aus der Telegram-Nachricht einsetzen. Danach funktioniert der Chat ganz normal.
Soll-Ergebnis: Der Bot antwortet auf deine nächste Nachricht mit einer sinnvollen KI-Antwort.

Teil 2: Optionale Erweiterungen

Die Grundinstallation läuft. OpenClaw antwortet per Telegram. Was jetzt kommt, ist optional – aber empfehlenswert.

Optional A: Web-Oberfläche per SSH-Tunnel

Zusätzlich zu Telegram gibt es eine browserbasierte Oberfläche. Sie ist bewusst nicht direkt im Netzwerk erreichbar – der Zugriff läuft über einen SSH-Tunnel. Das ist kein Umweg, sondern Absicht: Die Web-UI soll nicht offen im Heimnetz hängen.

SSH-Tunnel öffnen (auf dem Mac, neues Terminalfenster):

ssh -L 18789:127.0.0.1:18789 dein-benutzername@IP_der_Diskstation

Das Kommando leitet deinen lokalen Port 18789 verschlüsselt durch SSH an Port 18789 auf der DiskStation weiter. Solange dieses Terminalfenster offen ist, funktioniert der Tunnel.

Dann im Browser aufrufen (eigenen Token aus Schritt 1.6 einsetzen):

http://localhost:18789#token=2bbea678f.........................67003d38

Verwende localhost, nicht 127.0.0.1. Das ist kein Tippfehler – es macht technisch einen Unterschied bei der Erkennung des Tokens. Der Token muss direkt hinter dem # stehen, ohne Leerzeichen.

Falls „channel: open failed: administratively prohibited“ kommt:

SSH Port-Forwarding ist auf der DiskStation deaktiviert. Einmalig freischalten (andere Terminal-Sitzung, als root):

sudo -i
echo "AllowTcpForwarding yes" >> /etc/ssh/sshd_config
sed -i '85s/AllowTcpForwarding no/AllowTcpForwarding yes/' /etc/ssh/sshd_config
systemctl restart sshd

Falls systemctl nicht verfügbar ist:

synosystemctl restart sshd

Dann SSH-Tunnel neu starten und wieder im Browser aufrufen.
Falls „pairing required“ angezeigt wird:
Der Browser muss einmalig gepairt werden – genau wie Telegram in Schritt 1.8. Offene Pairing-Codes anzeigen:

sudo docker exec -it openclaw-gateway node /app/openclaw.mjs devices list

Den Code aus der Spalte „Pending → Request → Code“ notieren und bestätigen:

sudo docker exec -it openclaw-gateway node /app/openclaw.mjs devices approve DEIN_CODE

Optional B: Netzwerk-Isolation härten

Bisher kann der Container theoretisch alle Geräte in deinem Heimnetz erreichen – deinen Router, andere NAS-Geräte, Smart-Home-Systeme. Für einen KI-Agenten, der API-Anfragen ins Internet schickt, ist das ein unnötiges Risiko.

Bernd: „Ich versteh nicht, warum das nötig sein soll. Die Fritzbox macht das doch schon.“
Tanja: „Deine Fritzbox filtert Verbindungen von außen nach innen. Verbindungen vom Container in dein Netz sieht sie gar nicht – die laufen intern auf der NAS. Dafür brauchen wir iptables-Regeln direkt auf der DiskStation.“
Ulf: „iptables – ist das wie die Schiedsrichterregeln?“
Tanja: „Perfekter Vergleich! iptables ist das Regelwerk, das entscheidet, welche Datenpakete durchdürfen und welche direkt abgepfiffen werden.“
Ulf: „Und DOCKER-USER?“
Tanja: „DOCKER-USER ist die iptables-Kette, die Docker speziell für benutzerdefinierte Filterregeln vor der Container-Weiterleitung berücksichtigt. Wir schreiben unsere Regeln dorthin, damit sie Docker nicht überschreibt.“

Die zusätzlichen iptables-Regeln in diesem Abschnitt reduzieren das Risiko, dass ein kompromittierter Container interne Geräte im Heimnetz erreicht. Sie ersetzen jedoch keine VM-Isolation, kein Patch-Management und keine sorgfältige Prüfung der eingesetzten Container-Images.

Schritt B.1: Firewall-Skript erstellen

Das Skript arbeitet in drei Phasen:

Phase 1: Löscht eigene Regeln, falls das Skript schon einmal gelaufen ist.
Phase 2: Baut IPv4-Regeln neu auf.
Phase 3: Ergänzt IPv6-Regeln.
Das Skript ist idempotent – du kannst es beliebig oft ausführen, es baut immer sauber neu auf.

cat > /volume1/docker/openclaw/openclaw-firewall.sh << 'DATEIENDE'
#!/bin/bash
# =============================================================================
# openclaw-firewall.sh
# Netzwerk-Isolations-Skript für OpenClaw auf Synology DS1621+
# =============================================================================
# Kompatibel mit Synology DSM iptables 1.8.x (kein comment-Modul verfügbar).
#
# Blockiert ausgehenden Traffic vom OpenClaw-Container zu allen privaten
# und reservierten IPv4-Netzen. Internet-Zugang bleibt erlaubt.
# DNS läuft über öffentliche Server (1.1.1.1 / 8.8.8.8, gesetzt in
# docker-compose.yml), da der Router-DNS durch die Regeln blockiert wird.
#
# Idempotent: Löscht zuerst alle eigenen Regeln (per exakter Spezifikation),
# dann baut es die Regeln in definierter Reihenfolge neu auf.
# Kann beliebig oft ausgeführt werden.
#
# IPv6: Blockiert ULA (fc00::/7) und Link-Local (fe80::/10) global für den
# gesamten Docker-Forward-Traffic, da dem Container kein festes IPv6-Präfix
# zugewiesen ist. Falls du später andere Container mit IPv6 betreiben willst,
# diese Regeln anpassen.
#
# Verwendung:
#   Als Boot-Aufgabe im Synology Aufgabenplaner einrichten:
#   bash /volume1/docker/openclaw/openclaw-firewall.sh
# =============================================================================

sleep 30

DOCKER_SUBNET="172.30.0.0/24"   # Muss mit compose.yaml übereinstimmen

# ─────────────────────────────────────────────────────────────────────────────
# Phase 1: Alle eigenen Regeln entfernen (exakte Spezifikation)
# ─────────────────────────────────────────────────────────────────────────────

# IPv4
iptables -D DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 2>/dev/null
iptables -D DOCKER-USER -s "$DOCKER_SUBNET" -d 192.168.0.0/16 -j DROP 2>/dev/null
iptables -D DOCKER-USER -s "$DOCKER_SUBNET" -d 10.0.0.0/8 -j DROP 2>/dev/null
iptables -D DOCKER-USER -s "$DOCKER_SUBNET" -d 172.16.0.0/12 -j DROP 2>/dev/null
iptables -D DOCKER-USER -s "$DOCKER_SUBNET" -d 169.254.0.0/16 -j DROP 2>/dev/null
iptables -D DOCKER-USER -s "$DOCKER_SUBNET" -d 100.64.0.0/10 -j DROP 2>/dev/null

# IPv6
ip6tables -D DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 2>/dev/null
ip6tables -D DOCKER-USER -d fc00::/7 -j DROP 2>/dev/null
ip6tables -D DOCKER-USER -d fe80::/10 -j DROP 2>/dev/null

# ─────────────────────────────────────────────────────────────────────────────
# Phase 2: IPv4-Regeln in DOCKER-USER aufbauen
# ─────────────────────────────────────────────────────────────────────────────

# Position 1: Antwortpakete von erlaubten Verbindungen durchlassen
iptables -I DOCKER-USER 1 \
  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Position 2-6: Private und reservierte Netze blockieren
iptables -I DOCKER-USER 2 \
  -s "$DOCKER_SUBNET" -d 192.168.0.0/16 -j DROP

iptables -I DOCKER-USER 3 \
  -s "$DOCKER_SUBNET" -d 10.0.0.0/8 -j DROP

iptables -I DOCKER-USER 4 \
  -s "$DOCKER_SUBNET" -d 172.16.0.0/12 -j DROP

iptables -I DOCKER-USER 5 \
  -s "$DOCKER_SUBNET" -d 169.254.0.0/16 -j DROP

iptables -I DOCKER-USER 6 \
  -s "$DOCKER_SUBNET" -d 100.64.0.0/10 -j DROP

# RETURN: nur hinzufügen wenn keiner existiert
if ! iptables -L DOCKER-USER -n 2>/dev/null | grep -q "RETURN"; then
  iptables -A DOCKER-USER -j RETURN
fi

# ─────────────────────────────────────────────────────────────────────────────
# Phase 3: IPv6-Regeln (falls DOCKER-USER in ip6tables existiert)
# ─────────────────────────────────────────────────────────────────────────────

if ip6tables -L DOCKER-USER -n >/dev/null 2>&1; then
  ip6tables -I DOCKER-USER 1 \
    -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

  ip6tables -I DOCKER-USER 2 \
    -d fc00::/7 -j DROP

  ip6tables -I DOCKER-USER 3 \
    -d fe80::/10 -j DROP

  if ! ip6tables -L DOCKER-USER -n 2>/dev/null | grep -q "RETURN"; then
    ip6tables -A DOCKER-USER -j RETURN
  fi
fi

# ─────────────────────────────────────────────────────────────────────────────
# Ausgabe
# ─────────────────────────────────────────────────────────────────────────────
logger "openclaw-firewall: DOCKER-USER Regeln aktiv fuer $DOCKER_SUBNET"

echo ""
echo "========================================"
echo " OpenClaw Netzwerk-Isolation aktiviert"
echo "========================================"
echo ""
echo "IPv4 DOCKER-USER:"
iptables -L DOCKER-USER -n -v --line-numbers
echo ""

if ip6tables -L DOCKER-USER -n >/dev/null 2>&1; then
  echo "IPv6 DOCKER-USER:"
  ip6tables -L DOCKER-USER -n -v --line-numbers
  echo ""
fi

echo "Erwartete Reihenfolge:"
echo "  1  ACCEPT     ctstate RELATED,ESTABLISHED"
echo "  2  DROP       172.30.0.0/24 -> 192.168.0.0/16"
echo "  3  DROP       172.30.0.0/24 -> 10.0.0.0/8"
echo "  4  DROP       172.30.0.0/24 -> 172.16.0.0/12"
echo "  5  DROP       172.30.0.0/24 -> 169.254.0.0/16"
echo "  6  DROP       172.30.0.0/24 -> 100.64.0.0/10"
echo "  7  RETURN"
DATEIENDE

Dann das Skript ausführbar machen:

# Zu root wechseln
sudo -i

chmod +x /volume1/docker/openclaw/openclaw-firewall.sh

Welche Netze werden blockiert?

Bereich	Protokoll	Was ist das?
`192.168.0.0/16`	IPv4	Heimnetze (Fritzbox, etc.)
`10.0.0.0/8`	IPv4	Firmennetzwerke, VPNs
`172.16.0.0/12`	IPv4	Weitere private Netze
`169.254.0.0/16`	IPv4	Link-Local (mDNS-Geräte, APIPA)
`100.64.0.0/10`	IPv4	CGNAT (manche Provider/VPNs)
`fc00::/7`	IPv6 (global)	ULA (IPv6-Äquivalent zu privaten Netzen)
`fe80::/10`	IPv6 (global)	IPv6 Link-Local

Hinweis IPv6: Die IPv6-Regeln gelten für den gesamten Docker-Forward-Traffic auf der DiskStation, nicht nur für OpenClaw. Falls du später andere Container mit IPv6 betreiben willst, müssen diese Regeln angepasst werden.

Schritt B.2: Firewall als Boot-Aufgabe einrichten

Die iptables-Regeln sind flüchtig – ein Neustart löscht sie. Damit sie nach jedem Hochfahren automatisch aktiv sind:

Öffne: Systemsteuerung → Dienste → Aufgabenplaner.
Klicke Erstellen → Ausgelöste Aufgabe → Benutzerdefiniertes Skript.
Reiter Allgemein:
- Aufgabe: OpenClaw Netzwerk-Isolation
- Benutzer: root
- Ereignis: Hochfahren
Reiter Aufgabeneinstellungen: In das Textfeld eingeben:

   bash /volume1/docker/openclaw/openclaw-firewall.sh

Klicke OK und bestätige die Warnung.

Schritt B.3: Firewall sofort aktivieren

bash /volume1/docker/openclaw/openclaw-firewall.sh

Soll-Ergebnis – Regeln prüfen:

iptables -L DOCKER-USER -n -v --line-numbers

Erwartete Ausgabe:

num   target     prot  source           destination
1     ACCEPT     all   0.0.0.0/0        0.0.0.0/0        ctstate RELATED,ESTABLISHED
2     DROP       all   172.30.0.0/24    192.168.0.0/16
3     DROP       all   172.30.0.0/24    10.0.0.0/8
4     DROP       all   172.30.0.0/24    172.16.0.0/12
5     DROP       all   172.30.0.0/24    169.254.0.0/16
6     DROP       all   172.30.0.0/24    100.64.0.0/10
7     RETURN     all   0.0.0.0/0        0.0.0.0/0

Falls die Reihenfolge nicht stimmt: Skript nochmals ausführen – es räumt zuerst auf und baut sauber neu.

Isolation testen:

# Internet muss funktionieren:
sudo docker exec openclaw-gateway node -e "fetch('https://api.telegram.org').then(r=>console.log('OK',r.status)).catch(e=>console.log('FEHLER',e.message))"

# Heimnetz muss blockiert sein:
sudo docker exec openclaw-gateway node -e "fetch('http://192.168.2.1',{signal:AbortSignal.timeout(3000)}).then(r=>console.log('OFFEN!',r.status)).catch(e=>console.log('BLOCKIERT (gut!)'))"

# Firewall-Regeln prüfen:
sudo iptables -L DOCKER-USER -n -v --line-numbers

Erwartetes Ergebnis: Internet antwortet mit OK 200, Heimnetz meldet BLOCKIERT (gut!).

Optional C: Playwright-Browser nachrüsten

Bisher kommuniziert OpenClaw über APIs und Text. Mit einem eingebetteten Playwright-Browser kann er auch echte Webseiten laden, scrollen, Formulare ausfüllen und JavaScript-Rendering nutzen.

Ulf: „OpenClaw soll selbst surfen können? Wie ein Libero, der plötzlich stürmt?“
Tanja: „Genau so! Das LLM plant, Playwright führt aus. OpenClaw kann damit Inhalte aus dynamischen Seiten lesen, die über einfache HTTP-Requests nicht zugänglich sind.“
Bernd: „Ich hab einfach den System-Chromium genommen. Lief nicht. Dreimal probiert. Nie funktioniert.“
Tanja: „Deshalb bringt man die Browser-Binaries mit dem Container mit. Dann klappt es reproduzierbar – immer.“

Ein Playwright-Browser im Docker-Container bringt seine eigenen Browser-Binaries und Abhängigkeiten mit. Das vermeidet Konflikte mit System-Bibliotheken und Versionsinkompatibilitäten.

Schritt C.1: Dockerfile anlegen

Erstelle /volume1/docker/openclaw/Dockerfile:

FROM ghcr.io/openclaw/openclaw:latest

USER root

# Systembibliotheken für Chromium / Playwright
RUN apt-get update && apt-get install -y \
    libnspr4 \
    libnss3 \
    libatk1.0-0 \
    libatk-bridge2.0-0 \
    libcups2 \
    libdrm2 \
    libxkbcommon0 \
    libxcomposite1 \
    libxdamage1 \
    libxfixes3 \
    libxrandr2 \
    libgbm1 \
    libasound2 \
    ca-certificates \
    wget \
    && rm -rf /var/lib/apt/lists/*

USER node

Dann in der compose.yaml bei beiden Diensten (openclaw-gateway und openclaw-cli) die image-Zeile ersetzen:

# Vorher:
image: ghcr.io/openclaw/openclaw:latest

# Nachher:
build:
  context: /volume1/docker/openclaw
  dockerfile: Dockerfile

Schritt C.2: Chromium installieren

cd /volume1/docker/openclaw

sudo docker compose -p openclaw run --rm --entrypoint sh \
  -e PLAYWRIGHT_BROWSERS_PATH=/home/node/.openclaw/workspace/.browser \
  openclaw-cli -c 'mkdir -p /home/node/.openclaw/workspace/.browser && \
  node /app/node_modules/playwright-core/cli.js install chromium'

Soll-Ergebnis – Installation prüfen:

sudo docker exec -it openclaw-gateway sh -c 'ls -la /home/node/.openclaw/workspace/.browser'

Du solltest einen Ordner wie chromium-1208 sehen. Dann den Browser-Pfad testen:

sudo docker exec -it openclaw-gateway sh -c '/home/node/.openclaw/workspace/.browser/chromium-1208/chrome-linux64/chrome --version'

Eine ausgegebene Chrome-Versionsnummer bedeutet: Chromium ist korrekt installiert.
Der Ordnername (z.B. chromium-1208) hängt von der Playwright-Version ab. Prüfe ihn immer mit ls – er kann sich bei Updates ändern.

Schritt C.3: Browser-Pfad in openclaw.json setzen

Öffne /volume1/docker/openclaw/config/openclaw.json und füge den browser-Block ein:

"browser": {
  "enabled": true,
  "defaultProfile": "openclaw",
  "headless": true,
  "noSandbox": true,
  "executablePath": "/home/node/.openclaw/workspace/.browser/chromium-1208/chrome-linux64/chrome",
  "profiles": {
    "openclaw": {
      "cdpPort": 18800,
      "color": "#FF4500"
    }
  }
}

Schritt C.4: Testen

sudo docker exec -it openclaw-gateway sh -c '/home/node/.openclaw/workspace/.browser/chromium-1208/chrome-linux64/chrome --version'

Dann in OpenClaw (per Telegram oder Web-UI):

Verwende das Browser-Profil "openclaw" und öffne https://example.com.

Wenn OpenClaw antwortet und den Seiteninhalt beschreibt, ist alles korrekt eingerichtet.

Nützliche Befehle – der Spickzettel

Ulf: „Kann ich die ganzen Befehle irgendwo nachschlagen, ohne die ganze Anleitung nochmal zu lesen?“
Tanja: „Genau dafür gibt es diese Tabelle.“

Was	Befehl
Stoppen	Container Manager → Projekt → openclaw → Stoppen
Starten	Container Manager → Projekt → openclaw → Starten
Logs	Container Manager → Projekt → openclaw → Logs
Stoppen (SSH)	`cd /volume1/docker/openclaw && docker compose down`
Starten (SSH)	`cd /volume1/docker/openclaw && docker compose up -d openclaw-gateway`
Logs (SSH)	`docker logs openclaw-gateway --tail 20`
Aktualisieren	`cd /volume1/docker/openclaw && docker compose pull && docker compose down && docker compose up -d openclaw-gateway`
SSH-Tunnel (vom Mac)	`ssh -L 18789:127.0.0.1:18789 Teddy@192.168.2.10`
Firewall prüfen	`sudo iptables -L DOCKER-USER -n -v --line-numbers`
Firewall neu laden	`sudo bash /volume1/docker/openclaw/openclaw-firewall.sh`

Fehlerbehebung

Hier sind die häufigsten Probleme und ihre Lösungen. Bernd hat mindestens drei davon bereits persönlich erlebt.

Container startet nicht oder beendet sich sofort

Symptom: Container Manager meldet „unerwartet beendet“, Logs zeigen Fehler.
Prüfen:

docker logs openclaw-gateway --tail 50

Fehlermeldung	Ursache	Lösung
`Missing config`	Onboarding nicht abgeschlossen	Schritt 1.6 durchführen
`non-loopback Control UI requires allowedOrigins`	`config set`-Befehl fehlt	Befehl am Ende von Schritt 1.6 nachholen
`EACCES: permission denied`	Ordnerrechte falsch	`sudo chown -R 1000:1000 /volume1/docker/openclaw`
`pids_limit discarded`	Synology-Kernel unterstützt es nicht	Harmlos, ignorieren

Web-Oberfläche nicht erreichbar

Symptom: Browser zeigt leere Seite, Verbindung abgelehnt oder „pairing required“.
Prüfen:

docker ps --filter name=openclaw-gateway
docker logs openclaw-gateway --tail 50

Mögliche Ursache	Prüfbefehl / Lösung
Container läuft nicht	`docker compose up -d openclaw-gateway`
SSH-Tunnel nicht aktiv	`ssh -L 18789:127.0.0.1:18789 user@NAS_IP` im Terminal öffnen
Port-Forwarding deaktiviert	Fehler „administratively prohibited“ → SSH-Forwarding freischalten (Schritt Optional A)
`allowedOrigins` nicht gesetzt	`docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins '["http://localhost:18789"]'`
Browser noch nicht gepairt	`devices list` und `devices approve` (Schritt Optional A)
Falsche URL	`http://localhost:18789` – nicht `127.0.0.1`, nicht die NAS-IP

Telegram antwortet nicht

Symptom: Bot bleibt stumm, keine Antwort auf Nachrichten.
Prüfen:

docker logs openclaw-gateway --tail 20

Mögliche Ursache	Lösung
Pairing nicht abgeschlossen	Schritt 1.8 durchführen
Kein Internet	Folgenden Test ausführen (s.u.)
Falscher Bot-Token	Token im Onboarding neu eingeben (`configure`)

Internet-Test:

docker exec openclaw-gateway node -e "fetch('https://api.telegram.org').then(r=>console.log('OK',r.status)).catch(e=>console.log('FEHLER',e.message))"

Firewall-Regeln fehlen nach DSM-Update

Symptom: Internet-Zugriff vom Container ins Heimnetz ist wieder möglich.
Prüfen:

sudo iptables -L DOCKER-USER -n -v --line-numbers

Falls die Liste leer oder unvollständig ist:

sudo bash /volume1/docker/openclaw/openclaw-firewall.sh

Außerdem prüfen, ob die Boot-Aufgabe noch aktiv ist: Systemsteuerung → Aufgabenplaner.

„Read-only file system“

Symptom: Fehlermeldung bei einem Skill oder Modul, das schreiben will.
Temporäre Lösung: In der compose.yaml diese Zeile auskommentieren, Projekt neu starten:

# read_only: true

„non-loopback Control UI requires allowedOrigins“

Der Konfigurationsschritt aus Schritt 4.2 wurde übersprungen. Nachholen:

cd /volume1/docker/openclaw
docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins '["http://localhost:18789"]'

„Permission denied“

Die Ordner gehören dem falschen Benutzer. Beheben mit:

sudo chown -R 1000:1000 /volume1/docker/openclaw

DNS / kein Internet

Prüfe ob dns: 1.1.1.1 und dns: 8.8.8.8 in der compose.yaml vorhanden sind. Dann testen:

docker exec openclaw-gateway node -e "fetch('https://api.telegram.org').then(r=>console.log('OK',r.status)).catch(e=>console.log('FEHLER',e.message))"

„PIDs limit discarded“ Warnung

Harmlos. Der Synology-Kernel unterstützt das pids_limit-Feature nicht. Die Warnung kann ignoriert werden.

Wartung und Updates

Container aktualisieren:

cd /volume1/docker/openclaw
docker compose pull
docker compose down
docker compose up -d openclaw-gateway

Nach DSM-Updates: Firewall-Regeln prüfen und ggf. neu laden (siehe Fehlerbehebung oben).
Konfiguration ändern (Modell, API-Key, Kanäle):

cd /volume1/docker/openclaw
docker compose run --rm openclaw-cli configure

Fertig!

Tanja: „Das war’s. OpenClaw läuft, die Firewall ist aktiv, Telegram ist verbunden. Du hast einen abgesicherten AI-Agenten auf deiner Heimnetz-NAS.“
Ulf: „Und Bernd? Hat er seine VM noch?“
Bernd: „Meine VM läuft übrigens auch. Aber der RAM war dann weg und das DSM-Update hat dann… ähm. Das ist eine andere Geschichte.“
Tanja: „…war die VM weg. Ich weiß, Bernd. Ich weiß.“

Du hast in dieser Anleitung folgendes aufgebaut:

Container Manager und SSH auf der DiskStation aktiviert
Ordnerstruktur für OpenClaw angelegt
compose.yaml mit vollständigen Sicherheitseinstellungen erstellt und validiert
OpenClaw per interaktivem Onboarding konfiguriert
Telegram-Bot verbunden und gepairt

Optional ergänzt:

Web-Oberfläche per SSH-Tunnel zugänglich gemacht
Netzwerk-Isolation per iptables eingerichtet und als Boot-Aufgabe gespeichert
Playwright-Browser installiert