الاستنتاج الأساسي: من المرجح أن المشكلة ليست «الاستمرار في تغيير chmod حتى يعمل Syncthing». فالمؤشر الأقوى هو أن المجلد يعمل عندما يكون على مسار يستطيع Syncthing رؤيته مباشرة، لكنه يفشل عندما يعبر رابط رمزي إلى محرك أقراص فعلي آخر. وفي CasaOS، يشير ذلك أولًا إلى المسارات المحمّلة في الحاوية، ثم إلى أذونات UID/GID.
«لقد ضبطت الأذونات بالكامل… فهو يعمل عندما أحدد /DATA/AppData/، لكنه لا يعمل عندما يشير الرابط إلى محرك أقراص فعلي مختلف.» وتُعد نتيجة الاختبار هذه أكثر فائدة من خطأ الأذونات الأصلي، لأنها تحصر سبب الفشل في مسار التخزين.
لماذا يجب أن يكون الرابط الرمزي أول ما يتم التحقق منه
لا يتعامل Syncthing مع الرابط الرمزي على أنه «انتقل إلى الهدف وزامن كل ما يوجد هناك». ينص السلوك الموثق للروابط الرمزية في Syncthing على أنه يمكن مزامنة الروابط الرمزية، لكن لا يتم اتباعها مطلقًا. كما يتوقع إعداد المجلد مسارًا حقيقيًا محليًا للجهاز: مسار مجلد Syncthing هو المسار الفعلي للمجلد على القرص الصلب.
وهذا يجعل مسارًا مثل هذا موضع شك:
/DATA/Documents/Syncthing/SyncFiles → رابط رمزي → /some/other/physical/driveإذا كان Syncthing يعمل داخل Docker، فقد يتمكن المضيف من حل ذلك الرابط، بينما قد لا تتمكن الحاوية من رؤية الوجهة على الإطلاق.
يوضح تطبيق Syncthing في CasaOS سبب اختفاء محرك أقراص ثانٍ
يُعد تعريف CasaOS الرسمي لتطبيق Syncthing مفيدًا بشكل استثنائي هنا. إذ يربط ملف Compose الخاص به مسارين من المضيف داخل الحاوية:
/DATA/AppData/$AppID/config → /config
/DATA → /DATAيمكنك التحقق من تعيين وحدة التخزين الفعلي في ملف Compose الخاص بـ Syncthing في CasaOS.
هذا يعني أن الوجهة المتاحة فعليًا ضمن شجرة /DATA على المضيف يجب أن تكون مرئية أيضًا ضمن /DATA داخل حاوية Syncthing. لكن إذا كان الرابط الرمزي يشير في النهاية إلى نقطة تحميل على المضيف خارج تلك الشجرة، فستحتاج الحاوية إلى ربط تحميل منفصل للوجهة الفعلية. باستخدام عمليات ربط التحميل في Docker، يجب تحميل أدلة المضيف صراحةً داخل الحاوية.
استخدم هذا الاختبار للتمييز بين مشكلة في المسار ومشكلة في الأذونات
نفّذ عمليات التحقق بهذا الترتيب. لا تبدأ بأمر chmod تكراري آخر.
1. حلّ المسار الحقيقي على مضيف CasaOS
readlink -f "/DATA/Documents/Syncthing/SyncFiles"إذا أعاد الأمر مسارًا خارج /DATA، فقد عثرت على دليل مهم.
2. اسأل حاوية Syncthing عما إذا كانت ترى الهدف نفسه
docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"ثم اختبر الوجهة المحلولة إذا كان من المفترض أن تكون موجودة داخل الحاوية. إذا كان المضيف يستطيع سردها بينما لا تستطيع الحاوية ذلك، فالأذونات ليست المشكلة الأساسية بعد؛ إذ إن المسار مفقود من مساحة أسماء الحاوية.
3. افحص عمليات التحميل الفعلية في الحاوية
docker inspect syncthingانظر إلى التحميلات قسم . يجب أن تتمكن من تحديد مصدر المضيف ووجهة الحاوية لمحرك الأقراص الذي تنوي مزامنته.
الحل الأنظف: اربط محرك الأقراص الحقيقي، ثم استخدم مسار الحاوية هذا
إذا كان محرك الأقراص الخارجي خارج /DATA، واعرضه مباشرةً لـ Syncthing بدلًا من إخفائه خلف رابط رمزي. من الناحية المفاهيمية، يبدو إدخال compose كما يلي:
volumes:
- type: bind
source: /real/host/path/to/external-drive
target: /sync-driveثم اضبط مسار المجلد في Syncthing على قيمة واضحة، مثل:
/sync-drive/Dev Filesهذا ليس مسارًا سحريًا؛ اختر هدفًا يتوافق مع إعداد compose لديك. المهم أن تتلقى الحاوية الدليل الحقيقي على المضيف كوحدة تخزين محمّلة.
تستخدم صورة Syncthing من LinuxServer النموذج نفسه، وتوثّق تعيينات منفصلة للبيانات من المضيف إلى الحاوية، مثل /path/to/data1:/data1 و/path/to/data2:/data2. كما يوضّح تعيين PUID/PGID في Syncthing كيفية تطابق هوية الحاوية مع ملكية وحدة التخزين على المضيف.
لا تُصلح الملكية والأذونات إلا بعد التأكد من صحة التحميل
تضمّن استكشاف الأخطاء الأصلي اقتراحًا مثل:
sudo chmod -R 770 /path/to/folder770 قد يكونان مناسبين في بعض الإعدادات، لكن ذلك لا يفيد إلا إذا كان Syncthing يعمل فعليًا كمستخدم أو مجموعة تملك ذلك الدليل، أو ينتمي إلى المجموعة التي تملكه. يمرّر تطبيق CasaOS الأمر PUID و PGID إلى صورة LinuxServer. توثّق LinuxServer نفسها بأن ملكية وحدات التخزين على المضيف يجب أن تتطابق مع PUID/PGID المُعدَّدين.
تحقّق من المعرّفات بدلًا من افتراض اسم المستخدم casaos يكفي:
docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-driveإذا لم تتطابق معرّفات UID/GID الرقمية، فغيّر الملكية أو عضوية المجموعة عن قصد. تجنّب chmod -R 777؛ فهو يخفي المشكلة الحقيقية ويضعف التحكم في الوصول.
ما الذي يخبرك به خطأ «الملف موجود» فعليًا؟
الرسالة:
mkdir /DATA/Documents/Syncthing/SyncFiles: الملف موجودلا يثبت أن الدليل النهائي ملفات التطوير الدليل هو المشكلة. يفشل Syncthing أثناء إعداد جذر المجلد. عندما يكون المسار الأب رابطًا رمزيًا أو يُحلّ بشكل مختلف داخل الحاوية، قد يواجه التطبيق كائنًا في نظام الملفات حيث كان يتوقع مسار دليل عاديًا.
لذلك فإن أسرع تشخيص ليس حذف الدليل نفسه وإعادة إنشائه، بل مقارنة ما يلي:
- المسار الذي تم حلّه على المضيف؛
- المسار الظاهر داخل الحاوية؛
- نقاط الربط الخاصة بالحاوية؛
- قيمة PUID/PGID الرقمية مقارنةً بملكية الوجهة.
للحصول على أساس نظيف، يوضّح إعداد Syncthing في CasaOS مسار مزامنة عاديًا يستخدم المسار نفسه قبل تخصيصه لعدة محركات أقراص. وتفيد منصة التطبيقات في ZimaOS عند مقارنة أدوات بديلة للنسخ الاحتياطي أو مزامنة الملفات. وإذا كان الهدف النهائي هو دمج عدة محركات أقراص فعلية بدلًا من الربط بينها عبر روابط رمزية، فإن ZimaCube 2 هو خيار الأجهزة المتخصص في التخزين.
الأسئلة الشائعة
هل ينبغي أن أحلّ هذه المشكلة بتغيير المالك من root إلى casaos؟
ليس بمفرده. لا تصبح الملكية مهمة إلا بعد أن تتمكن الحاوية من رؤية مسار الوجهة الحقيقي. تحقّق أولًا من الربط وبالأخص من قيم PUID/PGID الرقمية.
لماذا يعمل المسار المباشر بينما يفشل الرابط الرمزي لمحرك أقراص آخر؟
يوجد المسار المباشر أسفل دليل مُحمّل إلى الحاوية في كلا نظامي الملفات. أما الرابط الرمزي فقد يُحلّ إلى موقع على المضيف لم يتم تحميله إلى الحاوية، ما يترك Syncthing أمام مسار لا يمكنه اجتيازه.
هل يتبع Syncthing الروابط الرمزية لمزامنة الدليل الهدف؟
لا. توضح وثائق Syncthing أن الروابط الرمزية لا تُتَّبع مطلقًا. استخدم مسار مجلد حقيقيًا يمكن لعملية Syncthing رؤيته.
ما الذي ينبغي أن أغيّره أولًا؟
حلّ الرابط الرمزي، وافحص نقاط تحميل حاوية Syncthing، ثم اربط الدليل الفعلي لمحرك الأقراص الخارجي. بعد ذلك تحقّق من PUID/PGID والأذونات.
