كان المستخدم المصدر يشغّل مزامنة صور الهاتف عبر Syncthing، لكن الملفات كانت تستقر باستمرار على محرك النظام بدلًا من قرص التخزين. أدّى نسخ مسار من تطبيق الملفات ولصقه مباشرةً في Syncthing إلى إعادة إنشاء شجرة المجلدات نفسها ظاهريًا داخل نظام ملفات الحاوية الخاص به.
كان الحل النهائي مفاهيميًا، وليس أمرًا سحريًا لنظام الملفات: لدى Docker مسار على المضيف ومسار داخل الحاوية. يجب أن يستخدم Syncthing المسار المرئي داخل الحاوية، وليس المسار الخام المرئي لـ CasaOS أو ZimaOS.
لماذا كان يُعاد إنشاء المسار الخارجي في المكان الخطأ
إذا طُلب من Syncthing استخدام مسار لا يستطيع رؤيته فعليًا، فقد ينشئ ذلك المسار داخل نظام الملفات القابل للكتابة الخاص به أو داخل موقع إعدادات مُعيَّن. فسّر المستخدم المصدر اسم المجلد على أنه مسار لقرص خارجي، بينما فسّرته الحاوية على أنه مسار نسبي إلى نظام الملفات الخاص بها.
العثور على نقطة التحميل الحقيقية على المضيف
استخدم المجتمع lsblk لتحديد المكان الذي حمّل فيه نظام التشغيل محرك الأقراص الخارجي. في مثال المُجيب، ظهر المحرك ضمن مسار مشابه لـ /media/devmon/...؛ ظهرت محركات الأقراص الخاصة بصاحب المنشور الأصلي لاحقًا ضمن /mnt/Storage1 و /mnt/Storage2.
تلك المسارات التاريخية الدقيقة لنقاط التحميل هي أمثلة من CasaOS/ZimaBlade، ولا ينبغي اعتبارها مسارات عامة حالية في ZimaOS.
تعيين محرك المضيف داخل Syncthing
استخدم المُجيب /DATA باعتباره المسار المستخدم في Syncthing. بعد إنشاء هذا التعيين، ينبغي أن يشير Syncthing إلى المجلدات الموجودة أسفل /DATA بدلًا من مسار التحميل الأصلي على المضيف.
أدخل المستخدم في البداية مسار المضيف داخل Syncthing
ثم أعاد Syncthing خطأً متعلقًا بالإذن أو المسار، لأن ذلك المسار الداخلي لم يكن يقابل وحدة التخزين المُعيَّنة.
كان المسار النهائي العامل هو /DATA/Documents
أوضح المُجيب أنه بعد تعيين محرك المضيف إلى /DATA، ينبغي أن يستخدم Syncthing:
/DATA/Documentsأو ما يعادله ~/Documents صيغة مختصرة عندما يشير مجلد Syncthing الرئيسي إلى موقع البيانات المُعيَّن.
عاد صاحب المنشور الأصلي في اليوم التالي وأكد نجاح العملية.
كان chown التكراري جزءًا من سير عمل المجتمع، وليس الحل الأساسي
استخدمت المناقشة أيضًا chown على محرك الأقراص الخارجي. قد يكون ذلك مناسبًا على نظام ملفات مملوك لنظام Linux، لكنه يغيّر الملكية عبر الهدف بأكمله، ولم يكن متطلبًا وضعته IceWhale.
لا تُجرِ تغييرًا تكراريًا للملكية على قرص مشترك موجود قبل أن تعرف المستخدمين والتطبيقات الذين يعتمدون بالفعل على صلاحياته.
يُسهّل ZimaOS الحالي تعيين مساحة تخزين التطبيقات
يوثّق ZimaOS الحالي مسارات المضيف والحاوية مباشرةً في إعدادات التطبيق، ويوصي بتعيين بيانات التطبيق إلى التخزين المُدار بدلًا من السماح للتطبيقات بملء قرص النظام.
استخدم نموذج مسارات التطبيقات الحالي في ZimaOS لوحدات تخزين Docker بدلًا من الاعتماد على مواقع التحميل القديمة في CasaOS.
أعاد المستخدم المصدر تثبيت Syncthing وأعاد إنشاء التعيين
بعد أن ظلت المحاولات الأولى مربكة، أجرى صاحب المنشور الأصلي تثبيتًا جديدًا لـ Syncthing، وأعاد إضافة محركات التخزين، وعيّن /mnt/Storage1 على المضيف إلى /DATA داخل الحاوية. أزال هذا الاختبار النظيف إعدادات الحاوية القديمة من عملية التشخيص.
صلاحيات المضيف وحدها لم تجعل مسار الحاوية الخاطئ يعمل
تمكن المستخدم من الاتصال عبر SSH بمحرك التخزين وإنشاء مجلدات، ومع ذلك ظل Syncthing يفشل عند مطالبته باستخدام /mnt/Storage1/Documents داخليًا. هذه النتيجة السلبية مفيدة: فالقدرة على الكتابة كمستخدم المضيف لا تعني أن الحاوية تستطيع رؤية مساحة الأسماء نفسها.
يجب أن تكون رؤية الحاوية صحيحة قبل أن تتمكن معايرة الصلاحيات من حل أي مشكلة.
يُفضّل أن يستخدم ZimaOS الحالي مسارات التخزين المُدارة
هذا النقاش منشور على جهاز ZimaBlade مزوّد بمسارات تخزين على نمط CasaOS. أما ZimaOS الحالي فلديه سلوك مختلف للتخزين المُدار وواجهة أوضح لوحدات تخزين التطبيقات. على خادم حالي، استخدم مسار التخزين المحدد عبر ZimaOS بدلًا من افتراض /mnt/Storage1 أو /media/devmon سيكون موجودًا.
غيّر الصلاحيات التي يحتاجها التطبيق فعلًا فقط
يحتاج Syncthing عادةً إلى صلاحيات القراءة والكتابة على مجلد المزامنة. إذا كان المجلد المعين ظاهرًا لكنه غير قابل للكتابة، فتحقق من الملكية وصلاحيات المجموعة لذلك المجلد تحديدًا. تجنب تغيير الملكية بشكل تكراري عبر محرك أقراص كامل متعدد الاستخدامات، ما لم تكن قد راعيت كل خدمة أخرى تستخدم ذلك المحرك.
الأسئلة الشائعة حول محرك الأقراص الصلبة الخارجي في Syncthing
لماذا أنشأ Syncthing مسار محرك الأقراص الخارجي داخل قرص النظام؟
لم يكن مسار المضيف هو المسار الذي استطاع Syncthing رؤيته داخل حاويته.
ما المسار الذي نجح بعد تعيين محرك الأقراص إلى /DATA؟
أكد المستخدم المصدر /DATA/Documents نجح الأمر.
هل كان تغيير الملكية بشكل تكراري هو الحل الوحيد؟
لا. كان الفهم الحاسم هو الفرق بين مسار المضيف ومسار الحاوية.
