بدأ هذا النقاش كسؤال حول تعطيل نظام ملفات للقراءة فقط في ZimaOS، لكن ذلك لم يكن المشكلة الحقيقية. بعد فحص الحزمة، اكتشف صاحب المنشور الأصلي أن ملف Compose كان يستخدم مسارات نسبية لوحدات التخزين.
هذا التمييز مهم، لأن تغيير أذونات نظام ملفات المضيف أو إعادة تركيب مسارات النظام كان سيكون حلاً خاطئًا في هذه الحالة.
تحقق من ملف Compose قبل تغيير ZimaOS
عندما يتعذر على حزمة حاويات إنشاء مسار أو الكتابة فيه، حدّد أولًا ما الذي يركّبه ملف Compose داخل الحاوية. يمكن لعملية ربط أن تشير إلى مسار على المضيف، بينما يدير Docker وحدة التخزين المُسمّاة. توضح قواعد وحدات تخزين Docker Compose الحالية أن مسارات المضيف النسبية تُحل انطلاقًا من موقع مشروع Compose.
بالنسبة إلى جهاز NAS مُدار ذاتيًا، غالبًا ما يكون المسار الدائم الصريح أسهل للفهم من مسار نسبي غامض، إذ يمكنك التحقق من وجود المجلد المصدر فعلًا وإمكانية الكتابة فيه.
لماذا كان افتراض وضع القراءة فقط مضللًا
عادةً ما تؤثر مشكلة نظام الملفات الحقيقي للقراءة فقط في أكثر من مسار واحد في Compose، وينبغي تشخيصها من حالة التركيب الفعلية وسجلات النظام. في هذا النقاش، لم يكن المستخدم بحاجة إلى إيقاف آلية حماية في ZimaOS، بل صحح إعداد وحدات التخزين النسبية.
ما الذي اقترحه المجتمع
قبل معرفة السبب الجذري، اقترح أحد أعضاء المجتمع فتح وضع المطوّر في ZimaOS، واستخدام الطرفية عبر الويب بصلاحيات الجذر، وإنشاء الدليل المطلوب يدويًا. قد يكون ذلك مفيدًا عندما لا يكون مسار المضيف المقصود موجودًا فعلًا، لكنه ينبغي أن يأتي بعد التحقق من مسار Compose، لا أن يحل محله.
ترتيب أكثر أمانًا لاستكشاف الأخطاء وإصلاحها
- افحص كل إدخال
volumes:في ملف Compose. - حدّد ما إذا كان كل مصدر وحدة تخزين مُسمّاة، أو مسارًا مطلقًا على المضيف، أو مسارًا نسبيًا.
- تأكد من وجود دليل المضيف المتوقع.
- تأكد من أن الحاوية ليست مركّبة صراحةً باستخدام
:roأوread_only: true. - لا تفحص حالة تركيب نظام ملفات المضيف إلا إذا استمر فشل الكتابة نفسه خارج إعدادات الحاوية.
السياق الحالي لـ Docker وPortainer
بالنسبة إلى عمليات نشر ZimaOS الحالية، توفر متطلبات أجهزة Portainer السياق الأوسع لاستمرارية Portainer وبيئة التشغيل، بينما يشرح تطبيق Docker الأول كيفية ربط تطبيقات ZimaOS بالبيانات الدائمة داخل الحاويات. وإذا كان التركيب للقراءة فقط فعلًا، وليس مجرد توجيه خاطئ للمسار، فإن إصلاح عملية ربط Docker يميّز بين تركيب :ro المُعدّ وبين نظام ملفات المضيف الذي توقف عن قبول عمليات الكتابة.
تؤكد قواعد عمليات ربط Docker أن عمليات الربط يمكنها استخدام مسارات مصدر على المضيف، وأن سلوك القراءة فقط يُتحكم فيه صراحةً باستخدام readonly أو ro. ويعرّف سلوك حزم Portainer حزمة Portainer بأنها مجموعة مترابطة من الخدمات، ولذلك ينبغي فحص ملف Compose قبل تغيير مضيف ZimaOS نفسه.
الخلاصة
لم يُحل خطأ حزمة Portainer المُبلغ عنه بتعطيل نظام ملفات للقراءة فقط. بل صحح المستخدم مسارات وحدات التخزين النسبية في docker-compose.yml. بالنسبة إلى أخطاء الحاويات المماثلة في ZimaOS، تحقّق من تعريف التركيب في Compose قبل إجراء تغييرات على نظام ملفات المضيف.
