الاستنتاج الأساسي: إذا كان بإمكان Syncthing قراءة مجلد لكنه لا يستطيع نشر عمليات الحذف أو التعديلات، فاختبر إذن الكتابة من داخل حاوية Syncthing. فتركيب الربط القابل للقراءة لا يكون قابلًا للكتابة تلقائيًا.
تحقق من وضع المجلد أولًا
ينبغي أن يستخدم المجلد ثنائي الاتجاه أوضاع مجلدات Syncthing المناسبة لاستقبال التغييرات. ولن يعمل وضع الإرسال فقط مثل وضع الإرسال والاستقبال.
أثبت قدرة الحاوية على الكتابة
docker exec -it syncthing sh
touch /DATA/Gallery/.write-test
rm /DATA/Gallery/.write-testإذا فشل أي من الأمرين، فأصلح أذونات التخزين قبل تغيير إعدادات Syncthing.
طابق PUID وPGID
يُمرّر تكوين CasaOS لـ Syncthing الرسمي القيمتَين PUID/PGID ويربط /DATA داخل الحاوية. وتوضح LinuxServer ملكية PUID/PGID لوحدات التخزين على المضيف.
docker exec syncthing id
stat -c '%u:%g %a %n' /DATA/Galleryقارن المعرّفات الرقمية. لا يكفي تغيير الملكية إلى اسم مستخدم إذا كانت الحاوية تعمل باستخدام UID/GID مختلفين.
تتطلب عمليات الحذف أذونات على الدليل الأب
يتطلب حذف ملف أو إعادة تسميته إذنَي الكتابة والتنفيذ على الدليل الأب. وهذا يفسر لماذا قد تبدو القراءة/المزامنة عاملة جزئيًا بينما تفشل عمليات الحذف عن بُعد.
قارن مجلدًا يعمل
قارن docker inspect syncthing عمليات الربط، stat الوضع/معرّف المستخدم/معرّف المجموعة، وقوائم التحكم بالوصول (ACLs) مع getfacl، حالة نظام الملفات للقراءة فقط، وأنماط التجاهل. لا تنتقل إلى chmod 777.
يوفر إعداد Syncthing في CasaOS نقطة أساس نظيفة. وتساعد منصة تطبيقات ZimaOS على مقارنة البدائل، بينما يناسب ZimaCube 2 أعباء عمل التخزين متعدد الأقراص.
تحقق من قوائم التحكم بالوصول عندما تبدو بتّات وضع Unix صحيحة
التقليدية chmod قد تبدو المخرجات سليمة مع استمرار وجود ACL يغيّر الأذونات الفعلية. قارن بين دليل يعمل ودليل يفشل:
getfacl /DATA/Gallery
getfacl /DATA/Documentsإذا كان أحد المسارين يحتوي على إدخالات ACL إضافية، فأصلحها عمدًا بدلًا من فتح الأذونات بشكل متكرر في كل مكان.
تحقق مما إذا كان نظام الملفات للقراءة فقط
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /DATA/Galleryقرص موصول roقد تؤدي أخطاء نظام الملفات أو محرك أقراص خارجي متدهور إلى ظهور العرض نفسه «يمكن القراءة لكن لا يمكن التغيير». وإذا كان الربط نفسه للقراءة فقط، فلن تتمكن إعدادات Syncthing من إصلاح ذلك.
اقرأ خطأ Syncthing الكامن وراء حالة «خارج المزامنة»
افتح واجهة Syncthing على الويب وافحص خطأ المجلد، ثم قارن سجلات الحاوية:
docker logs --tail 200 syncthingابحث عن تم رفض الإذن, العملية غير مسموح بهاأو أخطاء عدم العثور على المسار، أو فشل عمليات إعادة التسمية/الحذف. «خارج المزامنة» حالة؛ وعادةً ما يحتوي السجل على السبب الأساسي المتعلق بنظام الملفات.
لا تستخدم خيار «تجاهل الأذونات» كحل شامل
قد يساعد تجاهل بيانات أذونات الملفات عندما تمثل نظاما ملفات بتّات وضع Unix بطرق مختلفة، لكنه لا يمنح العملية إذن الكتابة. إذا لم تتمكن الحاوية من حذف ملف اختباري، فلن يؤدي تغيير سلوك Syncthing الخاص ببيانات الأذونات إلى جعل دليل المضيف قابلًا للكتابة.
استخدم اختبار كتابة مضبوطًا
أنشئ دليلًا صغيرًا مؤقتًا، واربطه بـ Syncthing، وتحقق من عمليات الإنشاء ← التحرير ← إعادة التسمية ← الحذف من كلا الجهازين. بعد نجاح ذلك، طبّق نمط الملكية والربط نفسه على المجلد الفعلي. يؤدي هذا إلى عزل سلوك المزامنة عن شجرة أدلة موجودة ومعقدة.
الأسئلة الشائعة
لماذا يستطيع Syncthing الإضافة لكنه لا يستطيع الحذف؟
يمكن لأذونات الدليل الأب السماح بالقراءة مع حظر عمليات إعادة التسمية أو الحذف.
هل ينبغي أن أستخدم chmod 777؟
لا. أثبت مسار الفشل وهوية الحاوية أولًا.
