عندما يرفض Docker التشغيل بعد ترحيل بيانات ZimaOS، قد يكون السطر الأخير في السجل مضللًا. في حالة المصدر هذه من فبراير 2026، أبلغ Docker في النهاية عن أن برنامج تخزين overlay2 غير مدعوم. لكن قراءة بضعة أسطر سابقة تكشف الفشل الحقيقي: تعذّر على Docker إنشاء ملفات مؤقتة أو اختبار تخزين overlay لأن قرص النظام لم تكن عليه مساحة متبقية.
كان لدى المستخدم قرص SSD بسعة 180 GB لنظام ZimaOS، وقد ترك عن طريق الخطأ قاعدة بيانات Immich المتنامية عليه. وعندما حاول الترحيل، لم تعد هناك مساحة خالية كافية لإجراء نقل سليم. وبعد عدة محاولات وحذف يدوي للسجلات، بدا أن AppData قد انتقلت، لكن قرص النظام ظل يصل إلى نسبة امتلاء 100%، ولم يعد Docker قادرًا على التهيئة بعد إعادة التشغيل.
تسبب Immich في امتلاء قرص SSD الصغير للنظام قبل الترحيل
ثبّت المستخدم Immich من دون نقل قاعدة بياناته بعيدًا عن قرص النظام. ومع نمو حزمة الصور، امتلأ القرص وبدأ ZimaOS في الإبلاغ عن أخطاء.
يتوافق هذا مع إرشادات IceWhale الحالية: ينبغي وضع بيانات التطبيقات على مساحة التخزين الرئيسية بدلًا من قرص نظام صغير، لأن مكتبات الصور والبيانات الوصفية للوسائط وفهارس المستندات وقواعد البيانات وذاكرات التخزين المؤقت قد تنمو بسرعة.
احتاج الترحيل نفسه إلى مساحة عمل
لم يجرّب المستخدم سير عمل الترحيل في ZimaOS إلا بعد امتلاء قرص النظام بشكل حرج. وقال إن محاولات الترحيل الأولى فشلت بسبب عدم وجود مساحة خالية كافية لتخزين البيانات مؤقتًا أثناء العملية.
هذا درس تشغيلي مهم: انقل AppData قبل أن يصل قرص النظام إلى بضعة غيغابايتات متبقية، وليس بعد أن تصبح خدمات Docker والترحيل محرومة من مساحة العمل اللازمة.
كانت رسالة مقبس Docker مجرد عرض
أبلغت التطبيقات بما يلي:
يتعذّر الاتصال بعفريت Docker على unix:///var/run/docker.sock.
هل عفريت Docker قيد التشغيل؟تعني هذه الرسالة أن عفريت Docker غير متاح. لكنها لا تحدد سبب تعذّر تشغيل العفريت.
كشفت السجلات السبب الجذري الحقيقي
كانت الأسطر المهمة هي:
لا توجد مساحة متبقية على الجهاز
تعذّر التأكد من تحميل ملف تعريف AppArmor الافتراضي
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
فشل بدء البرنامج الخفي: حدث خطأ أثناء تهيئة graphdriverفشل Docker أولًا لأنه لم يتمكن من كتابة البيانات المؤقتة. ثم ظهر لاحقًا برنامج التشغيل غير مدعوم كانت الرسالة نتيجة لفشل تهيئة برنامج تشغيل التخزين، وليست دليلًا على أن النواة قيد التشغيل فقدت فجأة دعم overlay2 بعد الترحيل.
لماذا لم تُحل المشكلة بإعادة تشغيل Docker
حاول المستخدم إعادة تشغيل docker.service و docker.socket يدويًا وتلقى رسالة «تم رفض الوصول». وربط أحد أعضاء المجتمع ذلك بعناصر التحكم في خدمات ZimaOS الشبيهة بالأجهزة المتخصصة.
حتى لو سُمح بإعادة تشغيل الخدمة، فلن يؤدي ذلك إلى إنشاء مساحة خالية على القرص. سيواجه البرنامج الخفي فشل الكتابة نفسه مجددًا.
لم يؤدِّ حذف ملفات Docker المؤقتة إلى استعادة مساحة كافية
اقترح المجتمع حذف ملفات Docker المؤقتة بعد التحقق أولًا من مساحة القرص. جرّب المستخدم الأصلي ذلك وردّ بأن محرك النظام ظل ممتلئًا بنسبة 100%، وأن Docker ظل غير قادر على البدء.
هذه النتيجة السلبية مفيدة: لا يمكن للتنظيف المؤقت المحدود إصلاح تصميم تخزين يظل فيه قرص النظام ممتلئًا بالكامل.
اختار المستخدم المصدر النسخ الاحتياطي واستعادة إعدادات المصنع
بعد فشل محاولة التنظيف، قرر المستخدم إجراء نسخ احتياطي لـ /DATA/AppData وإعادة تثبيت ZimaOS واستعادته. أوصى أحد أعضاء المجتمع بتدوين التطبيقات المثبّتة، واستخدام استعادة النظام إلى إعدادات المصنع، ثم ترحيل مساحة تخزين التطبيقات ذات الصلة إلى القرص الكبير قبل إعادة تثبيت التطبيقات.
ينتهي النقاش العام بعد أن قال المستخدم إنه سيفعل ذلك. ولا يتضمن تأكيدًا بعد الاستعادة، لذلك لا ينبغي للصفحة أن تصف إعادة التثبيت بأنها حل نهائي موثّق لهذا المستخدم تحديدًا.
ترحيل بيانات ZimaOS الحالي يوضّح بشكل أكبر ما يمكن نقله
يوفّر ZimaOS الحالي فئات منفصلة للترحيل تشمل:
- صور Docker؛
- بيانات تطبيقات Docker؛
- قواعد بيانات المستخدم، مثل Gallery وDownloads وDocuments وMedia وBackup.
هذا تحديث مهم للنقاش الأقدم، حيث عوملت «ترحيل AppData» أحيانًا كما لو أنه يشمل تلقائيًا جميع وحدات تخزين Docker.
استخدم فئات ترحيل البيانات الحالية في ZimaOS قبل أن يمتلئ قرص النظام الصغير بشكل حرج.
تجنب المشكلة بضبط موقع بيانات التطبيقات مبكرًا
يكشف ZimaOS الحالي أيضًا عن موقع لبيانات التطبيقات ضمن الإعدادات > التطبيقات. وتوصي IceWhale بتوجيهه إلى مصفوفة التخزين منذ البداية بدلًا من ترك نمو جميع بيانات التطبيقات الدائمة على جهاز النظام.
يُعد الشرح الحالي لـ مكان تخزين تطبيقات ZimaOS للبيانات الدائمة أفضل مرجع وقائي.
تحقق من السعة ووحدات inode
قد يرفض نظام الملفات إنشاء ملفات جديدة بسبب عدم وجود كتل خالية أو بسبب استنفاد وحدات inode. وقد اقترحت خطوات استكشاف أخطاء المصدر التحقق من كليهما. وتشير السجلات في هذه الحالة بقوة إلى استنفاد السعة العادي، لكن يظل التحقق من القيمتين تشخيصًا مفيدًا للقراءة فقط.
متى تصبح إعادة التثبيت خيارًا معقولًا
إذا كان قرص النظام ممتلئًا بنسبة 100%، وكانت بيانات Docker الوصفية للتخزين تالفة، وتعذر بدء البرنامج الخفي، ولم تتمكن عملية تنظيف آمنة من توفير مساحة عمل كافية، فقد تكون استعادة النظام المُتحكَّم بها أسرع وأكثر أمانًا من تعديل بيانات overlay الوصفية الخاصة بـ Docker يدويًا.
احمِ AppData وبيانات المستخدم أولًا، وافهم الأقراص التي ستطالها الاستعادة، وتجنب حذف النسخة الوحيدة من قواعد بيانات التطبيقات.
الأسئلة الشائعة حول Docker بعد الترحيل
هل كان overlay2 غير مدعوم فعلًا على العتاد المصدر؟
تُظهر السجلات أولًا أن Docker تعذر عليه إنشاء ملفات اختبار overlay2 لأن القرص كان ممتلئًا. ثم ظهرت رسالة برنامج التشغيل بعد ذلك الفشل.
هل أدى مسح ملفات Docker المؤقتة إلى إصلاح النظام المصدر؟
لا. ذكر صاحب المنشور الأصلي أن محرك نظام التشغيل ظل ممتلئًا بنسبة 100%.
هل يتيح ZimaOS الحالي نقل صور Docker بشكل منفصل عن AppData؟
نعم. يعرض ترحيل البيانات الحالي صور Docker وبيانات تطبيقات Docker كفئتين منفصلتين قابلتين للنقل.
هل تم تأكيد نجاح استعادة إعدادات المصنع في سلسلة النقاش؟
لا. ذكر المستخدم أنه سيمضي قدمًا في ذلك، لكن سلسلة النقاش العامة تنتهي قبل ظهور نتيجة ما بعد الاستعادة.
