إن ظهور OpenClaw مع الخدمة غير متاحة لا يحدد فشلًا واحدًا بعينه. ففي موضوع مجتمع IceWhale من فبراير 2026، كشف استكشاف الأخطاء وإصلاحها عن ثلاث طبقات مختلفة بالتتابع: رمز بوابة مطلوب، وإذن غير كافٍ لفحص Docker من حساب مضيف ZimaOS، وأخيرًا حاوية OpenClaw لم تُكمل إعدادها الأولي قط.
تكتسب المناقشة أهمية خاصة لأن بعض الاقتراحات الوسيطة اتضح أنها خاطئة بالنسبة إلى الصورة المُعبأة Big-Bear. تؤدي إضافة GATEWAY_MODE لم يؤدِّ متغير البيئة إلى حل حلقة إعادة التشغيل، كما أن إلحاق --gateway.mode=local أدى تمرير الأمر إلى الأمر الخطأ إلى ظهور خطأ خيار غير معروف يؤكد توثيق OpenClaw الحالي أن gateway.mode=local ينبغي أن يكون في إعدادات OpenClaw الدائمة، وأن عمليات نشر Docker يجب أن تشغّل الإعداد الأولي أو برنامج الإعداد لإنشاء ذلك الإعداد.
تحقق أولًا مما إذا كانت حاوية OpenClaw قيد التشغيل بالفعل
أظهر المنشور الأصلي أن تطبيق OpenClaw يفيد بأن التطبيق لا يعمل بشكل صحيح ويعرض تلميحًا حول OPENCLAW_GATEWAY_TOKEN.
قبل تغيير إعدادات التطبيق، افحص حالة الحاوية من مضيف ZimaOS أو CasaOS:
docker ps -a | grep openclawإذا كانت الحاوية تُعاد تشغيلها أو متوقفة، فاقرأ سجلاتها:
docker logs big-bear-openclaw --tail 100قد يختلف اسم الحاوية الفعلي. استخدم docker ps -a لتحديد الاسم الفعلي بدلًا من افتراض أنه دائمًا big-bear-openclaw.
إنشاء OPENCLAW_GATEWAY_TOKEN وتخزينه
كان أول اقتراح من المجتمع هو إنشاء رمز بوابة عشوائي قوي:
openssl rand -hex 32إذا لم يكن OpenSSL متاحًا، فقد اقترح النقاش بديلًا محليًا لإنشاء بايتات عشوائية:
head -c 32 /dev/urandom | xxd -p -c 32تستخدم وثائق Docker الرسمية الحالية لـ OpenClaw أيضًا OPENCLAW_GATEWAY_TOKEN لمصادقة البوابة. ينشئ برنامج الإعداد القياسي الرمز ويكتبه في ملف النشر .env الملف تلقائيًا. في تطبيق CasaOS مُعبأ يدويًا، أدخل القيمة المُنشأة في حقل متغير البيئة المتوقع من تلك الصورة.
تعامل مع هذا الرمز باعتباره سرًا. لا تلصقه في منتدى عام أو لقطة شاشة أو تذكرة دعم أو مستودع.
خطأ أذونات Docker ليس خطأ أذونات OpenClaw
بعد إضافة رمز، واجه المؤلف الأصلي ما يلي:
تم رفض الإذن أثناء محاولة الاتصال بمقبس عفريت Docker
/var/run/docker.sock: connect: permission denied
كانت توصية المجتمع هي رفع الصلاحيات مؤقتاً قبل تشغيل أوامر Docker الإدارية:
sudo -i
docker psاستخدم صلاحيات الجذر فقط للأوامر التي تتطلبها فعلاً. ولا تُضعف /var/run/docker.sock الصلاحيات أو جعل مقبس Docker متاحاً للكتابة عالمياً لمجرد إزالة الخطأ. إذ إن الوصول إلى Docker يمنح فعلياً تحكماً إدارياً بالمضيف.
كان خطأ OpenClaw الحقيقي هو «الإعداد مفقود»
وبمجرد الوصول إلى سجلات Docker، ظهرت الرسالة المهمة:
Missing config. Run `openclaw setup` or set gateway.mode=local
كان هذا أكثر قابلية للتنفيذ من صفحة «الخدمة غير متاحة» العامة. وتؤكد وثائق بوابة OpenClaw الحالية أن البوابة ترفض البدء بشكل طبيعي ما لم يتضمن إعدادها:
gateway.mode = localوتوضح OpenClaw الحالية أيضاً أن أياً من إعداد OpenClaw أو openclaw onboard --mode local يكتب وضع البوابة المحلية في الإعدادات الدائمة.
لماذا لم يُصلح GATEWAY_MODE=local هذه الصورة
اقترح أحد الردود المجتمعية الوسيطة إضافة:
GATEWAY_MODE=localجرّب المستخدم ذلك، واستمرت حلقة إعادة التشغيل. وهذا تصحيح مهم يجب الحفاظ عليه: لا توثّق وثائق OpenClaw الرسمية الحالية متغير بيئة عاماً باسم GATEWAY_MODE متغير البيئة بديلاً عن الإعداد الدائم gateway.mode المستخدم في سير العمل هذا.
لا تحوّل كل مفتاح إعداد من OpenClaw يحتوي على نقاط إلى متغير بيئة مُختلق بأحرف كبيرة. استخدم طريقة الإعداد الموثقة للصورة المحددة من OpenClaw أو لقالب النشر المحدد.
لماذا أنتج --gateway.mode=local رسالة «خيار غير معروف»
وألصقت محاولة مجتمعية لاحقة:
--gateway.mode=localإلى أمر حاوية CasaOS. ثم أعادت الصورة الرسالة:
unknown option '--gateway.mode'حدّد النقاش السبب بشكل صحيح: كان CasaOS يضيف العلامة إلى طبقة أوامر لا تقبلها. تستخدم واجهة OpenClaw الحالية أوامر مثل: openclaw gateway, إعداد OpenClaw, openclaw onboard، و openclaw config set; gateway.mode هو مفتاح إعداد، وليس علامة عامة لوقت التشغيل يمكن وضعها في أي مكان داخل أمر الحاوية.
تحتاج صورة Big-Bear إلى مجلد إعدادات دائم ومهيّأ
تركّز التشخيص النهائي من المجتمع على هذا التحميل:
/DATA/AppData/big-bear-openclaw
→ /home/node/.openclawتوقعت الحاوية وجود إعداداتها ضمن /home/node/.openclaw، لكن المجلد المُحمّل لم تتم تهيئته. وهذا يتوافق مع وثائق OpenClaw الحالية الخاصة بـ Docker: يحتوي مجلد الإعدادات المُحمّل على openclaw.json، وبيانات ملف تعريف المصادقة، والأسرار المدعومة بمتغيرات البيئة.
كانت التوصية النهائية في النقاش هي تشغيل الإعداد داخل الحاوية، حتى يحصل المجلد المُحمّل على إعداد فعلي لـ OpenClaw. ومع ذلك، لم يعد صاحب المنشور الأصلي بتأكيد نهائي بعد ذلك الرد الأخير. لذا تعامل معها على أنها أقوى تشخيص في النقاش، وليست حلاً نهائياً تم التحقق منه.
فضّل الإعداد الأولي الحالي لـ OpenClaw عبر Docker عند التثبيت الجديد
بالنسبة إلى عملية نشر حديثة، اتبع دليل تثبيت Docker الحالي لـ OpenClaw بدلًا من إعادة بناء تسلسل استكشاف الأخطاء وإصلاحها لعام 2026 خطأً تلو الآخر.
يوفّر OpenClaw حاليًا نصًا برمجيًا لإعداد Docker يقوم بما يلي:
- يبني صورة البوابة أو يسحبها؛
- ينفّذ الإعداد الأولي؛
- ينشئ رمز بوابة؛
- يكتب الإعدادات الدائمة؛
- ينشئ مجلدات الأسرار المطلوبة؛
- يشغّل البوابة عبر Docker Compose.
بالنسبة إلى نشر Docker دون واجهة، توثّق OpenClaw حاليًا أيضًا إعدادًا أوليًا غير تفاعلي باستخدام وضع البوابة المحلية والمصادقة بالرمز المميز. وهذا أفضل من اختراع متغيرات بيئية يدويًا أو إلحاق أعلام غير مدعومة.
نمط الإعداد اليدوي الحالي
يوثّق دليل Docker الحالي لـ OpenClaw نمطًا يدويًا مكافئًا لما يلي:
openclaw onboard --mode local --no-install-daemon
openclaw config set gateway.mode local
openclaw config set gateway.bind lanفي Docker Compose، تُنفَّذ هذه الأوامر عادةً من خلال حاوية CLI أو حاوية الإعداد الأولي المخصصة التي يعرّفها المشروع. لا تلصق أوامر المضيف داخل صورة CasaOS المجمّعة قبل التحقق من نقطة الدخول ووحدات الربط الخاصة بها.
تؤكد وثائق OpenClaw الحالية لواجهة سطر أوامر البوابة أن الأمرين openclaw setup وopenclaw onboard --mode local ينشئان إعدادات البوابة المحلية المطلوبة.
استخدم رمز البوابة نفسه في واجهة التحكم
تكشف وثائق Docker الحالية الخاصة بـ OpenClaw عن واجهة التحكم على المنفذ 18789 في إعداد Compose القياسي، وتوجّه المستخدمين إلى لصق رمز البوابة من بيئة النشر في إعدادات واجهة المستخدم.
قد يؤدي عدم تطابق الرمز المميز إلى فشل المصادقة بعد أن تصبح البوابة سليمة، لكنه يختلف عن حاوية تتوقف مرارًا بسبب عدم وجود إعدادات. شخّص بدء التشغيل أولًا، ثم مصادقة واجهة المستخدم.
لا تجعل --allow-unconfigured إصلاحًا دائمًا
يوفّر OpenClaw --allow-unconfigured للتشغيل المؤقت أو لأغراض التطوير. تنص الوثائق الحالية صراحةً على أنه يتجاوز الحماية الخاصة بالوضع المحلي من دون كتابة الإعدادات أو إصلاحها. وهو مفيد للاختبار، لكنه لا يحل محل الإعداد الصحيح لخادم دائم.
قائمة فحص لاستكشاف أخطاء عدم توفر خدمة OpenClaw وإصلاحها
- تحقق مما إذا كانت حاوية OpenClaw قيد التشغيل أو متوقفة أو تعيد التشغيل.
- اقرأ سجلات الحاوية الحالية قبل تغيير الإعدادات.
- تأكد من
OPENCLAW_GATEWAY_TOKENموجودًا ويُعامَل باعتباره سرًا. - إذا فشلت أوامر Docker بسبب رفض الإذن للمقبس، فاستخدم جلسة إدارية مخوّلة بدلًا من إضعاف صلاحيات مقبس Docker.
- ابحث تحديدًا عن
إعداد مفقودأوgateway.mode=localالأخطاء. - تأكد من أن مسار AppData على المضيف موصول بدليل إعداد OpenClaw الذي تتوقعه الصورة.
- شغّل مسار الإعداد أو التهيئة الأولية المدعوم من OpenClaw، بحيث
openclaw.jsonيُنشأ في مساحة تخزين مستمرة. - لا تعتمد على
GATEWAY_MODE=localما لم توضّح وثائق الصورة المحددة ذلك صراحةً. - لا تُضف
--gateway.mode=localإلى أمر حاوية عشوائي في CasaOS. - أعد تشغيل الحاوية وتحقق من السجلات مجددًا بعد كتابة الإعداد.
- بعد أن تظل البوابة قيد التشغيل، استكشف أخطاء مصادقة واجهة التحكم أو إعداد موفّر النموذج وإصلاحها.
الأسئلة الشائعة حول عدم توفر خدمة OpenClaw
هل يتطلب OpenClaw المتغير OPENCLAW_GATEWAY_TOKEN؟
تدعم عمليات نشر OpenClaw عبر Docker حاليًا هذا المتغير وتستخدمه عادةً OPENCLAW_GATEWAY_TOKEN لمصادقة البوابة. ويمكن لبرنامج الإعداد الرسمي إنشاء واحد تلقائيًا. وقد تكشف الصور المعبأة التابعة لجهات خارجية القيمة بطريقة مختلفة، لذا اتبع مخطط البيئة الفعلي للصورة.
ماذا يعني «تم رفض الإذن /var/run/docker.sock»؟
يعني ذلك أن المستخدم الحالي على المضيف لا يملك صلاحية الوصول إلى عفريت Docker. وهذا لا يعني بحد ذاته أن دليل بيانات OpenClaw الداخلي غير قابل للكتابة. استخدم حسابًا إداريًا مخوّلًا لتشخيص Docker.
كيف أضبط gateway.mode=local؟
استخدم أمر الإعداد أو التهيئة الأولية أو الإعداد المدعوم من OpenClaw، بحيث تُكتب القيمة في openclaw.json. وتقول الوثائق الحالية إعداد OpenClaw أو openclaw onboard --mode local ينشئ هذا الإعداد.
هل ينبغي أن أضيف GATEWAY_MODE=local؟
ليس استنادًا إلى هذا النقاش. فلم تحلّ تلك الاقتراحات حلقة إعادة التشغيل الخاصة بصورة المستخدم المعبأة، بينما تتعامل وثائق المنبع الحالية مع gateway.mode كإعداد بدلًا من متغير بيئة عام باسم GATEWAY_MODE.
لماذا يظهر --gateway.mode=local على أنه خيار غير معروف؟
لأن الخيار أُضيف إلى طبقة الأوامر الخطأ في حزمة CasaOS. فمفتاح الإعداد المنقّط ليس تلقائيًا علامة سطر أوامر صالحة لكل ملف ثنائي أو نقطة إدخال في OpenClaw.
هل حُلّ نقاش المجتمع بشكل نهائي؟
توصل النقاش إلى تشخيص نهائي قوي — وهو أن دليل الإعداد المستمر غير مهيأ — وأوصى بتشغيل إعداد OpenClaw داخل الحاوية. لم ينشر صاحب المنشور الأصلي تأكيدًا نهائيًا بعد ذلك التوجيه الأخير، لذا لا ينبغي للصفحة أن تدّعي التوصل إلى حل موثّق لا يتضمنه المصدر.
