عندما تعرض ملفات ZimaOS رسالة خطأ في التحميل بينما يظل الوصول عبر Windows SMB يعمل، فلا تفترض فورًا أن RAID أو البيانات قد اختفت. كان هذا هو النمط في نقاش فبراير 2026: تعطلت واجهة الملفات بعد تحديث 1.5.4، بينما ظلت التطبيقات الأخرى والوصول إلى الملفات عبر Samba يعملان.
قدّم موظفو IceWhale لاحقًا أهم حدود السبب الجذري. أوضح raller1028 أنه في ZimaOS 1.5.4، عندما يكون قرص النظام ممتلئًا، قد تتوقف خدمة الملفات عن العمل بشكل صحيح. وكان الإجراء الرسمي للاسترداد هو تحرير مساحة على قرص النظام ثم إعادة تشغيل icewhale-files. وقد ساعد حل مجتمعي منفصل لإعادة تسمية قاعدة البيانات عدة مستخدمين، لكن IceWhale لم تقدمه باعتباره الحل الأول.
عمل SMB دليل قوي على أن البيانات ونقاط التركيب ما زالت موجودة
كان بإمكان صاحب المنشور الأصلي الوصول إلى الملفات من خلال مشاركة Samba على Windows. وهذا يعني أن مساحة التخزين المضيفة ومسار البيانات كانا يعملان، رغم أن تطبيق الملفات على الويب لم يتمكن من عرضها.
وهذا تمييز مهم بين:
- فقدان التخزين أو البيانات؛
- تعطل خدمة الملفات؛
- تعطل المتصفح أو واجهة المستخدم.
الملفات ليست حاوية Docker عادية من متجر التطبيقات
لذلك، من المتوقع ألا يعرض الأمر docker ps حاوية للملفات. ولن تؤدي إعادة تشغيل حاويات Docker عشوائية إلى إصلاح خدمة الملفات الأصلية.
حددت IceWhale امتلاء مساحة تخزين النظام باعتباره سبب المشكلة في 1.5.4
في 26 فبراير، كتب raller1028 من IceWhale أن المشكلة «يُفترض أن تكون» ناتجة عن امتلاء قرص النظام في الإصدار 1.5.4.
كان تسلسل الاسترداد الرسمي كما يلي:
- تحرير بعض المساحة على قرص النظام من خلال سطر الأوامر؛
- إعادة تشغيل خدمة الملفات:
systemctl restart icewhale-filesوطُلب من المستخدمين غير الملمّين بتنظيف سطر الأوامر التواصل مع الدعم بدلًا من حذف الملفات عشوائيًا.
لماذا قد يؤدي امتلاء قرص النظام إلى تعطيل الملفات بينما يظل SMB يعمل؟
تحتاج الخدمات الأصلية إلى مساحة عمل لقواعد البيانات، والحالة، والملفات المؤقتة، والسجلات، وعمليات الخدمة. وقد تظل بيانات المستخدم الكبيرة سليمة على مصفوفة تخزين أخرى، بينما يصل قسم نظام صغير إلى نسبة استخدام 100% ويتسبب في تعطل خاص بخدمة معينة.
ولهذا، لا يكفي التحقق من أن «لدي مساحة خالية في RAID» فقط.
أبقِ بيانات التطبيقات المتزايدة بعيدًا عن قرص النظام
توصي وثائق ZimaOS الحالية بنقل بيانات التطبيقات إلى مساحة تخزين فعلية بدلًا من السماح لقواعد بيانات Docker، والصور المصغرة، وذاكرات التخزين المؤقت بملء قرص النظام.
استخدم إرشادات تخزين التطبيقات الحالية في ZimaOS لمنع مصدر مختلف للضغط على قرص النظام.
نجحت إعادة تسمية files.db المجتمعية مع عدة مستخدمين
نشر أحد المستخدمين في المجتمع لاحقًا ما يلي:
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-filesوردّ عدة مشاركين بأن ذلك أعاد الملفات إلى العمل.
ومع ذلك، ينبغي التعامل مع هذا باعتباره مسار استرداد مجتمعيًا ثانويًا. فقد سأل موظفو IceWhale فورًا عن أهمية إزالة قاعدة بيانات الملفات، ولم يستبدلوا التوجيه الرسمي «تحرير مساحة النظام + إعادة تشغيل الخدمة» بهذا الأمر.
إعادة تسمية قاعدة البيانات أكثر أمانًا من حذفها، لكنها لا تزال تغيّر حالة التطبيق
يحتفظ الأمر المجتمعي بنسخة .bak بدلًا من محو قاعدة البيانات. وهذا أفضل للتراجع عن التغيير، لكن إعادة إنشاء قاعدة بيانات الملفات قد تغيّر البيانات الوصفية المفهرسة أو حالة أخرى للخدمة.
لا تستخدمه كإجراء أول عندما يكون قرص النظام ممتلئًا ببساطة.
لا تفترض استمرار خطأ 1.5.4 في إصدارات ZimaOS الحالية
الإصدار الحالي من ZimaOS هو 1.7.x، وقد واصل تلقي إصلاحات للملفات، والتخزين، والذاكرة، والأمان، وتخزين التطبيقات. وتفيد المشكلة التاريخية في تعليمك كيفية التمييز بين تعطل الخدمة وفقدان البيانات، لا لأنها تعني أن كل خطأ حديث في الملفات له السبب نفسه.
إذا عادت المشكلة اليوم، فابدأ بتسجيل المساحة الخالية الحالية في النظام، والإصدار الحالي، وحالة الخدمة، وما إذا كان الوصول إلى الملفات عبر SMB أو غيره لا يزال يعمل.
حرّر المساحة بعناية
لا تشغّل نصوص تنظيف شاملة على أدلة النظام غير المعروفة. حدّد ذاكرات التخزين المؤقت الكبيرة للتطبيقات، وبيانات Docker، والنسخ الاحتياطية، أو السجلات، واستخدم عناصر التحكم الحالية في ZimaOS للتنظيف أو النقل متى أمكن.
الأسئلة الشائعة حول خطأ تحميل الملفات
هل ظل SMB يعمل في الحالة الأصلية؟
نعم، مما أشار بقوة إلى أن البيانات ونقاط التركيب كانت لا تزال موجودة.
ما المشكلة التي حددها موظفو IceWhale في الإصدار 1.5.4؟
امتلاء قرص النظام، مما تسبب في توقف خدمة الملفات عن العمل بشكل صحيح.
ما أمر إعادة تشغيل الخدمة الرسمي؟
systemctl restart icewhale-files.
هل كانت إعادة تسمية files.db توجيهًا رسميًا كحل أول؟
لا. كانت حلًا بديلًا من المجتمع أكّد عدة مستخدمين نجاحه، بينما كان التوجيه الأول من IceWhale هو تحرير المساحة وإعادة تشغيل خدمة الملفات.
