يحتوي هذا المصدر على عدة أعطال حدثت في فترة زمنية متقاربة، لذلك لا ينبغي إعادة صياغته باعتباره مجرد «خلل في Portainer». كان قرص النظام شبه ممتلئ، وتمت ترقية Docker وcontainerd إلى إصدارات رئيسية جديدة عبر Debian، ورُفض اختبار قديم لـ Docker CLI من قِبل خدمة Docker 29، وفقد Portainer بيئة Local، وظل CasaOS يعرض رسالة «جارٍ تحميل التطبيقات»، ثم تسببت مشكلة إقلاع لاحقة في جعل لوحة التحكم تبدو تقريبًا كأنها تثبيت جديد.
لا يؤكد أي رد في المصدر سببًا جذريًا نهائيًا واحدًا. والتفسير الأكثر أمانًا هو أن المشكلة تتعلق بعملية استرداد متعددة الطبقات: يجب أولًا الحفاظ على البيانات الحالية، ثم تحديد نظام الإقلاع/نظام الملفات الجذري النشط، والتحقق مما إذا كان جذر بيانات Docker لا يزال موجودًا، وما إذا كانت الخدمة سليمة، وما إذا كان Portainer وCasaOS متوافقين مع واجهة برمجة Docker التي تمت ترقيتها.
كان قرص النظام يعاني بالفعل من ضغط شديد بسبب نقص المساحة
لم يكن لدى المستخدم سوى نحو 1 غيغابايت متاحًا على نظام ملفات جذري سعته 27 غيغابايت قبل التنظيف. وشملت العناصر التي تستهلك مساحة كبيرة بيانات Docker overlay، وبيانات Jellyfin الوصفية، وسجلات النظام، وحزم التطوير.
يمكن أن يؤدي انخفاض المساحة المتاحة إلى جعل عمليات صور Docker والحاويات وقواعد البيانات والسجلات وخدمات CasaOS تتصرف بصورة غير متوقعة. لذلك كان تحرير المساحة ضروريًا بغض النظر عن مشكلة واجهة برمجة Docker اللاحقة.
غيّرت ترقية المضيف Docker من الإصدار 28.x إلى 29.0.0
أظهر سجل حزم Debian ترقيات الحزم التالية:
-
docker-ce؛ -
docker-ce-cli؛ -
containerd.io؛ - إضافات Docker للتشغيل دون صلاحيات الجذر.
يمكن لترقية رئيسية لمحرك Docker أن تكشف عن مشكلات توافق في أدوات الإدارة التي تتضمن عملاء قديمة لواجهة برمجة التطبيقات أو تتفاوض باستخدامها.
سجّل المصدر عدم توافق حقيقيًا في إصدار واجهة برمجة Docker
أعادت حاوية Docker CLI الإصدار 24.0.5 الرسالة التالية:
client version 1.43 is too old.
Minimum supported API version is 1.44تُعد هذه الرسالة دليلًا مباشرًا على أن عميلًا قديمًا واحدًا على الأقل لم يعد قادرًا على الاتصال بخدمة Docker التي تمت ترقيتها. لكنها لا تثبت وحدها أن Portainer كان يستخدم إصدار العميل نفسه، مع أنها تجعل التحقق من توافق واجهة برمجة التطبيقات أولوية عالية.
ظهور Local في Portainer ثم اختفاؤها هو عرض من طبقة الإدارة
حاول المصدر إعادة إنشاء بيئة Docker محلية باستخدام /var/run/docker.sock دون نجاح. وقبل حذف حالة Portainer، تحقّق من:
docker info
docker ps
ls -l /var/run/docker.sockإذا كانت واجهة Docker عبر سطر الأوامر تعمل لكن Portainer لا يعمل، فركّز على إصدار Portainer وتوافق واجهة برمجة التطبيقات والوصول إلى المقبس. أما إذا كانت Docker نفسها لا تعمل، فأصلح الخدمة أولًا.
يشير عرض CasaOS لعبارة «جارٍ تحميل التطبيقات» إلى أن العطل كان أوسع من Portainer
واجه CasaOS أيضًا صعوبة في تعداد التطبيقات. وقد يحدث ذلك إذا كانت Docker غير متاحة، أو إذا تغيرت واجهة Docker بطريقة غير متوافقة، أو إذا كان جذر بيانات الخدمة مفقودًا، أو إذا لم يعد المضيف الذي تم الإقلاع منه في حالة النظام المتوقعة.
تغيّر أولوية الاسترداد بعد ظهور حدث «اختر جهاز الإقلاع المناسب» لاحقًا
بعد إعادة التشغيل، توقف الجهاز عن الإقلاع بصورة طبيعية إلى أن غيّر المستخدم اختيار الإقلاع. وعندما عاد النظام للعمل، لم يعرض CasaOS أي تطبيقات رغم بقاء القرص الصلب الكبير متصلًا.
يثير ذلك احتمال اختيار قرص إقلاع/نظام ملفات جذري مختلف، أو تغير قسم النظام/حالته. ولا يثبت المصدر أيًّا من الاحتمالين.
احتفظ ببيانات AppData قبل إعادة تثبيت CasaOS
كان المستخدم يهتم خصوصًا بما يلي:
-
ملفات المشاريع في
/home/casaos؛ - بيانات Jellyfin الوصفية الموجودة ضمن AppData؛
- ملفات الوسائط على القرص الصلب؛
- تهيئة Docker وCasaOS حيثما أمكن استردادها.
انسخ تلك المجلدات الدائمة إلى قرص أو نظام آخر قبل إعادة تثبيت Docker أو إعادة ضبطها. فعادةً ما تكون إعادة إنشاء الحاويات أسهل من إعادة إنشاء قواعد بيانات التطبيقات وبياناتها الوصفية.
لا تُجرِ تنظيفًا شاملًا لـ Docker دون معرفة ما يزال قيد الاستخدام
يمكن أن يؤدي حذف الصور غير المستخدمة إلى استعادة مساحة، لكن حذف وحدات التخزين أو مجلدات جذر البيانات قد يزيل حالة التطبيق التي تحاول حفظها. حدّد الحاويات ووحدات التخزين والربط بالمجلدات ومسارات AppData أولًا.
تعامل مع تحديثات Debian وDocker باعتبارها جزءًا من منصة CasaOS
يعمل CasaOS فوق مضيف Linux الأساسي. ويمكن لترقية شاملة باستخدام apt upgrade أن تحدّث Docker والنواة وsystemd وحزم الشبكات والتخزين التي يعتمد عليها CasaOS. اختبر ترقيات المضيف الرئيسية بعناية، واحتفظ بنسخة احتياطية للنظام والتطبيقات قبل تطبيقها على جهاز NAS يعمل بصورة سليمة.
الأسئلة الشائعة حول استرداد Portainer وCasaOS
هل أثبت المصدر أن Docker 29 وحدها تسببت في جميع الأعطال؟
لا. كان النظام شبه ممتلئ أيضًا، ثم ظهرت لاحقًا مشكلة في جهاز الإقلاع/حالة النظام.
هل تم تأكيد عدم توافق في واجهة برمجة Docker؟
نعم. رُفض عميل Docker 24 الذي يستخدم واجهة برمجة التطبيقات 1.43 لأن خدمة Docker 29 تطلبت الإصدار 1.44 على الأقل.
هل ينبغي للمستخدم إعادة تثبيت CasaOS قبل نسخ AppData؟
لا. احتفظ أولًا بنسخة من AppData المهمة وملفات الدليل المنزلي وملفات الوسائط كلما ظلت الأقراص قابلة للوصول.
