L’affichage de Service Unavailable par OpenClaw n’identifie pas une seule défaillance. Dans la discussion de la communauté IceWhale de février 2026, le dépannage a révélé successivement trois niveaux différents : un jeton de passerelle requis, des autorisations insuffisantes pour inspecter Docker depuis le compte hôte ZimaOS, puis un conteneur OpenClaw qui n’avait jamais terminé sa configuration initiale.
La discussion est particulièrement utile, car certaines suggestions intermédiaires se sont révélées incorrectes pour l’image empaquetée Big-Bear. L’ajout d’une GATEWAY_MODE la variable d’environnement n’a pas résolu la boucle de redémarrage, et l’ajout de --gateway.mode=local vers la mauvaise commande a produit une option inconnue erreur. La documentation actuelle d’OpenClaw confirme que gateway.mode=local doit figurer dans la configuration persistante d’OpenClaw et que les déploiements Docker doivent lancer l’intégration ou la configuration initiale pour créer cette configuration.
Vérifier d’abord si le conteneur OpenClaw est réellement en cours d’exécution
La publication originale indiquait que l’application OpenClaw signalait que l’application ne fonctionnait pas correctement et affichait un conseil concernant OPENCLAW_GATEWAY_TOKEN.
Avant de modifier les paramètres de l’application, examinez l’état du conteneur depuis l’hôte ZimaOS ou CasaOS :
docker ps -a | grep openclawSi le conteneur redémarre ou s’est arrêté, consultez ses journaux :
docker logs big-bear-openclaw --tail 100Le nom exact du conteneur peut varier. Utilisez docker ps -a pour identifier le nom réel, plutôt que de supposer qu’il est toujours big-bear-openclaw.
Générer et stocker OPENCLAW_GATEWAY_TOKEN
La première suggestion de la communauté consistait à générer un jeton de passerelle aléatoire robuste :
openssl rand -hex 32Si OpenSSL n’est pas disponible, la discussion proposait une alternative locale générant des octets aléatoires :
head -c 32 /dev/urandom | xxd -p -c 32La documentation Docker officielle actuelle d’OpenClaw utilise également OPENCLAW_GATEWAY_TOKEN pour l’authentification de la passerelle. Son script d’installation standard génère un jeton et l’écrit dans le .env fichier automatiquement. Dans une application CasaOS empaquetée manuellement, saisissez la valeur générée dans le champ de variable d’environnement attendu par cette image.
Considérez ce jeton comme un secret. Ne le publiez pas sur un forum public, dans une capture d’écran, un ticket d’assistance ou un dépôt.
Une erreur d’autorisation Docker n’est pas une erreur d’autorisation OpenClaw
Après avoir ajouté un jeton, l’auteur d’origine a rencontré le problème suivant :
autorisation refusée lors de la tentative de connexion au socket du démon Docker
/var/run/docker.sock: connect: permission denied
La recommandation de la communauté était d’élever temporairement les privilèges avant d’exécuter les commandes Docker administratives :
sudo -i
docker psN’utilisez les privilèges root que pour les commandes qui en ont réellement besoin. N’affaiblissez pas /var/run/docker.sock les autorisations ni rendre le socket Docker accessible en écriture à tous simplement pour faire disparaître l’erreur. L’accès à Docker confère effectivement un contrôle administratif sur l’hôte.
La véritable erreur OpenClaw était « Configuration manquante »
Une fois les journaux Docker accessibles, le message important est apparu :
Missing config. Run `openclaw setup` or set gateway.mode=local
Cette piste était plus exploitable que la page générique « Service Unavailable ». La documentation actuelle de la passerelle OpenClaw confirme que la passerelle refuse normalement de démarrer tant que sa configuration ne contient pas :
gateway.mode = localLa documentation actuelle d’OpenClaw indique également que configuration d’OpenClaw ou openclaw onboard --mode local enregistre le mode de passerelle local dans la configuration persistante.
Pourquoi GATEWAY_MODE=local n’a pas corrigé cette image
Une réponse intermédiaire de la communauté suggérait d’ajouter :
Ne vous fiez pas àL’utilisateur a essayé cette méthode, mais la boucle de redémarrage a continué. Il est important de conserver cette précision : la documentation officielle actuelle d’OpenClaw ne définit pas de GATEWAY_MODE variable d’environnement en remplacement du paramètre persistant gateway.mode utilisé dans ce flux de travail.
Ne convertissez pas chaque clé de configuration OpenClaw contenant des points en une variable d’environnement en majuscules inventée. Utilisez la méthode de configuration documentée pour l’image OpenClaw ou le modèle de déploiement exact.
Pourquoi --gateway.mode=local a produit « Option inconnue »
Une tentative ultérieure de la communauté a ajouté :
--gateway.mode=localdans la commande du conteneur CasaOS. L’image a alors renvoyé :
unknown option '--gateway.mode'Le fil a correctement identifié la cause : CasaOS ajoutait l’indicateur à une couche de commande qui ne l’acceptait pas. L’interface CLI actuelle d’OpenClaw utilise des commandes telles que openclaw gateway, configuration d’OpenClaw, openclaw onboard, et openclaw config set; gateway.mode est une clé de configuration, et non un indicateur d’exécution universel de niveau supérieur pouvant être placé n’importe où dans la commande du conteneur.
L’image Big-Bear nécessitait un répertoire de configuration persistant et initialisé
Le diagnostic final de la communauté s’est concentré sur ce montage :
/DATA/AppData/big-bear-openclaw
→ /home/node/.openclawLe conteneur attendait sa configuration dans /home/node/.openclaw, mais le répertoire monté n’avait pas été initialisé. Cela correspond à la documentation actuelle d’OpenClaw pour Docker : le répertoire de configuration monté contient les données persistantes openclaw.json, les données du profil d’authentification et les secrets fournis par l’environnement.
La dernière suggestion du fil consistait à exécuter la configuration à l’intérieur du conteneur afin que le répertoire monté reçoive une véritable configuration OpenClaw. Toutefois, l’auteur du message initial n’est pas revenu confirmer le résultat après cette dernière réponse. Considérez donc cette suggestion comme le diagnostic le plus probable du fil, et non comme une résolution finale vérifiée.
Privilégiez l’intégration Docker actuelle d’OpenClaw lors d’une nouvelle installation
Pour un déploiement actuel, suivez le guide officiel d’installation Docker d’OpenClaw plutôt que de reconstituer la séquence de dépannage de 2026 erreur après erreur.
OpenClaw fournit actuellement un script de configuration Docker qui :
- construit ou récupère l’image de la passerelle ;
- exécute l’intégration ;
- génère un jeton de passerelle ;
- écrit la configuration persistante ;
- crée les répertoires requis pour les secrets ;
- démarre la passerelle via Docker Compose.
Pour un déploiement Docker sans interface, OpenClaw documente également une intégration non interactive avec le mode passerelle locale et l’authentification par jeton. Cette méthode est préférable à l’invention manuelle de variables d’environnement ou à l’ajout d’options non prises en charge.
Procédure actuelle de configuration manuelle
Le guide Docker actuel d’OpenClaw documente une procédure manuelle équivalente à :
openclaw onboard --mode local --no-install-daemon
openclaw config set gateway.mode local
openclaw config set gateway.bind lanDans Docker Compose, ces commandes sont normalement exécutées via le conteneur CLI ou d’intégration dédié défini par le projet. Ne collez pas de commandes destinées à l’hôte dans une image CasaOS préconfigurée sans vérifier d’abord son point d’entrée et ses montages.
La documentation actuelle de l’interface CLI de la passerelle OpenClaw confirme que openclaw setup et openclaw onboard --mode local créent la configuration locale requise de la passerelle.
Utilisez le même jeton de passerelle dans l’interface de contrôle
La documentation Docker actuelle d’OpenClaw expose l’interface de contrôle sur le port 18789 dans la configuration Compose standard et demande aux utilisateurs de coller dans les paramètres de l’interface le jeton de passerelle provenant de l’environnement de déploiement.
Une incompatibilité de jetons peut provoquer des échecs d’authentification une fois la passerelle opérationnelle, mais elle diffère d’un conteneur qui s’arrête à répétition parce qu’aucune configuration n’existe. Diagnostiquez d’abord le démarrage, puis l’authentification dans l’interface.
N’utilisez pas --allow-unconfigured comme solution permanente
OpenClaw fournit --allow-unconfigured pour un démarrage ponctuel ou de développement. La documentation actuelle précise que cette option contourne la protection du mode local sans écrire ni réparer la configuration. Elle est utile pour les tests, mais ne remplace pas l’intégration correcte d’un serveur persistant.
Liste de vérification pour résoudre l’indisponibilité du service OpenClaw
- Vérifiez si le conteneur OpenClaw est en cours d’exécution, arrêté ou en redémarrage.
- Lisez les journaux actuels du conteneur avant de modifier les paramètres.
- Vérifiez
OPENCLAW_GATEWAY_TOKENexiste et est traité comme un secret. - Si les commandes Docker échouent avec une erreur d’autorisation sur le socket, utilisez un shell administratif autorisé plutôt que d’affaiblir les autorisations du socket Docker.
- Recherchez précisément
Configuration manquanteougateway.mode=localerreurs. - Vérifiez que le chemin AppData de l’hôte est monté vers le répertoire de configuration OpenClaw attendu par l’image.
- Exécutez le flux de configuration ou d’initialisation pris en charge par OpenClaw afin que
openclaw.jsonest créé dans le stockage persistant. - GATEWAY_MODE=local
Ne vous fiez pas àsauf si la documentation exacte de l’image le définit explicitement. - N’ajoutez pas
--gateway.mode=localà une commande arbitraire du conteneur CasaOS. - Redémarrez le conteneur et vérifiez à nouveau les journaux après l’écriture de la configuration.
- Uniquement après que la passerelle reste active, dépannez l’authentification par jeton de l’interface de contrôle ou la configuration du fournisseur de modèles.
FAQ : service OpenClaw indisponible
OpenClaw nécessite-t-il OPENCLAW_GATEWAY_TOKEN ?
Les déploiements Docker actuels d’OpenClaw prennent en charge et utilisent couramment OPENCLAW_GATEWAY_TOKEN pour l’authentification de la passerelle. Le script officiel d’installation peut en générer un automatiquement. Les images tierces packagées peuvent exposer cette valeur différemment ; suivez donc le schéma d’environnement réel de l’image.
Que signifie « permission denied /var/run/docker.sock » ?
Cela signifie que l’utilisateur actuel de l’hôte ne peut pas accéder au démon Docker. Cela ne signifie pas en soi que le répertoire de données interne d’OpenClaw n’est pas accessible en écriture. Utilisez un compte administratif autorisé pour les diagnostics Docker.
Comment définir gateway.mode=local ?
Utilisez la commande de configuration, d’initialisation ou de paramétrage prise en charge par OpenClaw afin que la valeur soit écrite dans openclaw.json. La documentation actuelle indique configuration d’OpenClaw ou openclaw onboard --mode local crée ce paramètre.
Dois-je ajouter GATEWAY_MODE=local ?
Pas d’après cette discussion. Cette suggestion n’a pas résolu la boucle de redémarrage de l’image packagée de l’utilisateur, et la documentation actuelle en amont indique gateway.mode comme configuration plutôt que comme variable d’environnement générique nommée GATEWAY_MODE.
Pourquoi --gateway.mode=local indique-t-il une option inconnue ?
Parce que l’option a été ajoutée à la mauvaise couche de commande dans le paquet CasaOS. Une clé de configuration avec des points n’est pas automatiquement une option valide en ligne de commande pour chaque binaire ou point d’entrée OpenClaw.
La discussion de la communauté a-t-elle été définitivement résolue ?
La discussion a abouti à un diagnostic final solide — un répertoire de configuration persistant non initialisé — et recommandait d’exécuter configuration d’OpenClaw dans le conteneur. L’auteur du message original n’a pas publié de confirmation finale après cette dernière instruction ; la page ne doit donc pas prétendre à une résolution vérifiée que la source ne contient pas.
