بدأ هذا المصدر كمشكلة أذونات محبطة، وتحول في النهاية إلى حل قابل للتكرار. كان Syncthing قادرًا على التواصل مع النظير الذي يعمل بنظام Windows، وكان بإمكانه المزامنة إلى موقع AppData الافتراضي، لكن محاولة استخدام مسار NAS مُحمّل مثل /media/raid/NAS/Music نتجت تم رفض الإذن و مسار المجلد مفقود أخطاء.
في أغسطس 2025، نشر أحد مستخدمي المجتمع الأسلوب الذي نجح معه: إعادة تثبيت Syncthing باستخدام التثبيت المخصص، واستخدام PUID/PGID الحقيقيَّين لمستخدم ZimaOS، واختيار جذر مزامنة مناسب، ودَع Syncthing ينشئ مجلد الوجهة الخاص به. وأكد مستخدمان لاحقان صراحةً نجاح ذلك. ويوثّق دليل Syncthing الرسمي الحالي من IceWhale الآن إعدادًا مماثلًا في جوهره.
لم يكن Syncthing الأصلي قادرًا على الكتابة إلا إلى مسار AppData الافتراضي
كان بإمكان المستخدم المصدر ملء:
/DATA/AppData/syncthing/config/Syncلكن تعذّر عليه استخدام مسار الموسيقى المطلوب على القرص الصلب، رغم أن Files وJellyfin وNavidrome تمكّنت من الوصول إليه. وهذا دليل قوي على عدم تطابق هوية الحاوية/الأذونات، وليس على تعطل القرص.
اقتُرح تشغيل Syncthing بصلاحيات الجذر، لكنه ليس الحل الحالي المفضّل
اقترح ردّ مجتمعي مبكر استخدام PUID/GUID بالقيمة 0. يمكن لتشغيل خدمة مزامنة الملفات بصلاحيات الجذر تجاوز كثير من مشكلات الأذونات، لكنه يمنح الحاوية أيضًا صلاحيات كتابة/حذف أوسع بكثير من اللازم.
توصي إرشادات IceWhale الحالية صراحةً باستخدام معرّفات المستخدم الفعلي بدلًا من ذلك.
استخدم التثبيت المخصص
اعثر على PUID وPGID الفعليَّين لمستخدم ZimaOS
تستخدم الإرشادات الرسمية الحالية ما يلي:
id -u username
id -g usernameاستبدل اسم المستخدم باستخدام حساب ZimaOS الذي ينبغي أن يملك الملفات المتزامنة ويديرها، ثم انسخ المعرّفات الرقمية التي تظهر إلى متغيرات بيئة Syncthing.
لا تستخدم جذر قرص مُحمّل كمجلد Syncthing
تنص وثائق IceWhale الحالية على أنه لا ينبغي استخدام جذر قرص مُحمّل أو مجلدات النظام مثل Gallery/Media/Documents مباشرةً كمسار مجلد Syncthing، لأن ذلك يتطلب عادةً امتيازات على مستوى الجذر.
أنشئ مجلدًا فرعيًا مخصصًا مناسبًا أو استخدمه بدلًا من ذلك.
دع Syncthing ينشئ مجلد الوجهة
حذّر الحل المجتمعي المستخدمين تحديدًا من إنشاء الوجهة مسبقًا عبر متصفح الملفات في ZimaOS. وتكرر الوثائق الرسمية الحالية الآن أفضل ممارسة مماثلة: حدّد الوجهة في Syncthing ودَع Syncthing ينشئها.
هذا الإصلاح المجتمعي منعكس الآن في وثائق ZimaOS الرسمية
استخدم إعداد Syncthing الحالي في ZimaOS.
لماذا يحذّر الدليل من أن المعرّفات الخاطئة قد تتطلب إعادة التثبيت
إذا أنشأ التثبيت الأول الإعدادات/المجلدات بهوية خاطئة، فقد يؤدي تغيير قيمة واحدة لاحقًا إلى بقاء الملكية القديمة. لذلك تطلب الإرشادات الحالية من المستخدمين التحقق بعناية من PUID/PGID قبل التثبيت.
انسخ إعدادات Syncthing احتياطيًا إذا كانت تتضمن علاقات أجهزة/مجلدات مهمة، قبل حذف AppData لإجراء إعادة تثبيت نظيفة.
اختبر أولًا باستخدام مجلد صغير يمكن الاستغناء عنه
قبل توجيه Syncthing إلى شجرة كبيرة من الموسيقى أو المستندات، زامن مجلد اختبار صغيرًا، وتحقّق من السلوك ثنائي الاتجاه إذا كان مفعّلًا، وتأكد من الملكية على وحدة التخزين الشبكية، ثم أضف مجلدات الإنتاج.
ينجح الإصلاح لأن جميع طبقات الأذونات أصبحت متوافقة أخيرًا
لكي يتمكن Syncthing من إنشاء الملفات بنجاح، يجب أن تتوافق أربعة أمور: أن يكون مجلد المضيف في ZimaOS موجودًا وقابلًا للكتابة من المستخدم/المجموعة المقصودين، وأن يربط Docker مجلد المضيف هذا بالحاوية، وأن يعمل Syncthing باستخدام PUID/PGID المطابقين، وأن يشير مسار المجلد المُعدّ داخل Syncthing إلى نقطة الربط داخل الحاوية. وقد يبدو عدم التطابق في أي طبقة من هذه الطبقات كأنه العَرَض نفسه، وهو «تم رفض الإذن».
لماذا تُعد جذور الأقراص الموّصلة هدفًا افتراضيًا سيئًا للمزامنة
غالبًا ما يحتوي جذر القرص الموصول على مجلدات تديرها المنظومة وبيانات وصفية للمشاركة أو أذونات مخصّصة لعدة خدمات. ويؤدي منح محرك المزامنة صلاحيات كتابة واسعة هناك إلى زيادة نطاق الضرر الناتج عن الحذف العرضي أو الإعداد الخاطئ. أما المجلد الفرعي المخصّص، فيسهّل بكثير فهم سياسة الملكية والنسخ الاحتياطي.
تحقّق من دلالات الحذف في Syncthing قبل تفعيل المزامنة ثنائية الاتجاه
ينشر Syncthing التغييرات وفقًا لوضع المجلد، بما في ذلك عمليات الحذف في إعدادات الإرسال/الاستقبال. قبل توجيهه إلى مكتبة موسيقى أو مستندات كبيرة، اختبر سلوك الإنشاء/إعادة التسمية/الحذف باستخدام ملفات يمكن الاستغناء عنها، وفكّر في استخدام ميزة إصدارات Syncthing إذا كان استرداد الملفات المحذوفة عن بُعد بالخطأ مهمًا.
الأسئلة الشائعة حول Syncthing على ZimaOS
هل أكد المستخدمون اللاحقون نجاح نهج PUID/PGID؟
نعم. فقد ذكر مشاركان لاحقان على الأقل أن الطريقة المنشورة حلّت مشكلتهما.
هل ينبغي تشغيل Syncthing بصلاحيات الجذر للوصول إلى الأقراص؟
توصي إرشادات IceWhale الحالية باستخدام PUID/PGID الحقيقيين لمستخدم ZimaOS ومجلد فرعي مناسب بدلًا من ذلك.
هل ينبغي أن أنشئ مجلد الوجهة أولًا في «ملفات ZimaOS»؟
تنصّ وثائق IceWhale الحالية على ترك Syncthing ينشئ مجلد الوجهة بنفسه.
