الخطأ المجلد '/tv/' غير قابل للكتابة بواسطة المستخدم 'abc' وهذا يعني أن Sonarr يستطيع رؤية الدليل المُركّب، لكن العملية التي تعمل داخل الحاوية لا تملك إذن الكتابة فيه. وقد تظهر المشكلة نفسها في Radarr على شكل خطأ في المجلد الجذري للأفلام.
في حالة مجتمع IceWhale في يوليو 2025، جاء التطبيقان من متجر تطبيقات ZimaOS واستخدما الإعداد الافتراضي PUID=1000 PUID PGID=1000. كانت مجلدات وسائط المستخدم موجودة على مجموعة تخزين RAID. واقترح أحد أعضاء فريق IceWhale ضبط كلا المعرّفين على 0، وأكّد صاحب المنشور أن ذلك جعل المجلدات قابلة للكتابة. وهذه نتيجة مهمة من المصدر، لكن تشغيل التطبيق بمعرّفات مكافئة للجذر يمنح وصولًا أوسع بكثير إلى نظام الملفات مما يلزم عادةً. وتوصي وثائق LinuxServer.io الحالية بمطابقة PUID/PGID مع مالك أدلة المضيف أو مجموعتها بدلًا من ذلك.
ما معنى «المجلد غير قابل للكتابة بواسطة المستخدم abc»؟
استخدمت حزمة متجر تطبيقات ZimaOS في النقاش حاويات Sonarr وRadarr بنمط LinuxServer. تشغّل هذه الصور عملية التطبيق كمستخدم داخلي يُعرض عادةً باسم abc، بينما تحقق من القيمة الحالية لـ PUID و اربط تلك العملية الداخلية بأرقام معرّفات المستخدم والمجموعة على نظام ملفات المضيف.
إذا كان الدليل المضيف مملوكًا لمعرّف UID/GID مختلف، ولم تسمح بتات الأذونات الخاصة به للعملية المعيّنة بالكتابة، فيمكن لـSonarr أو Radarr استعراض نقطة التركيب، لكن لا يمكنهما إنشاء الوسائط أو إعادة تسميتها أو نقلها أو استيرادها هناك.
تعيينات متجر تطبيقات ZimaOS الأصلية
تضمّن المنشور لقطات شاشة منفصلة لإعدادات Radarr وSonarr. كان بإمكان التطبيقين رؤية وحدات التخزين المضيفة المُعدّة، لكن إنشاء المجلد الجذري فشل داخل التطبيقين.
أخطاء Sonarr وRadarr
أعاد Sonarr الرسالة التالية:
تعذّر إضافة المجلد الجذري
المجلد '/tv/' غير قابل للكتابة بواسطة المستخدم 'abc'
أظهر Radarr المشكلة المقابلة لمسار الأفلام:
الحل المجتمعي: PUID=0 وPGID=0
وردّ أحد أعضاء فريق IceWhale:
PUID=0
PGID=0غيّر صاحب المنشور الأصلي كلتا القيمتين إلى الصفر، وأفاد بأن المشكلة بدت محلولة. لذلك يُعد هذا الحل المؤكد لذلك الإعداد المحدد لمتجر تطبيقات ZimaOS في يوليو 2025.
ومع ذلك، فإن UID 0 وGID 0 هما هويتان بمستوى الجذر في Linux. وقد يتيح تشغيل Sonarr أو Radarr باستخدام هذين المعرّفين للتطبيق الكتابة في مواقع تتجاوز مكتبة الوسائط المقصودة بكثير إذا كانت تلك المسارات موصولة بالحاوية. استخدم هذا كحل تشخيصي أو للتوافق فقط عندما تفهم الصلاحيات التي يمنحها.
الإصلاح المفضّل: مطابقة PUID وPGID مع ملكية التخزين على المضيف
توضح وثائق LinuxServer.io الحالية الخاصة بـ Sonarr وRadarr التصميم المقصود: عيّن PUID وPGID بما يتطابق مع ملكية التخزين على المضيف تحقق من القيمة الحالية لـ PUID و إلى مستخدم/مجموعة على المضيف يملكان وحدة التخزين المرتبطة أو لديهما صلاحية الكتابة عليها.
توضح إرشادات LinuxServer أن مشكلات الأذونات تنشأ عندما يكون المجلد على المضيف مملوكًا لمعرّفات لا تطابق المعرّفات المقدّمة إلى الحاوية. والنمط الذي توصي به هو:
PUID=1000
PGID=1000فقط عندما يكون UID 1000 وGID 1000 مناسبين فعليًا لمسارات الوسائط. الرقم 1000 ليس صحيحًا بطبيعته؛ بل هو مجرد أول معرّف شائع لمستخدم Linux غير الجذر.
راجع وثائق LinuxServer الحالية حول Sonarr ووثائق LinuxServer الحالية حول Radarr.
كيفية فحص مالك التخزين والأذونات
إذا لم تعرض واجهة ملفات ZimaOS قيم المالك/المجموعة الرقمية في Linux التي تحتاج إليها، فافحص مسار المضيف الفعلي من طرفية مصرّح بها.
حدّد أولًا دليل المضيف الحقيقي المرتبط بـ /tv أو /moviesثم افحصه:
ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATHيساعدك الناتج الرقمي على تحديد UID وGID اللذين يملكان الدليل حاليًا. لا تُشغّل هذه الأوامر على المسار الخاص بالحاوية فقط /tv من المضيف، ما لم يكن ذلك بالفعل هو مسار المضيف.
إذا كان حساب إدارة الوسائط المقصود متاحًا على المضيف، فيمكنك فحص معرّفاته باستخدام:
id USERNAMEثم عيّن Sonarr/Radarr تحقق من القيمة الحالية لـ PUID و إلى المعرّفات التي تتوافق مع نموذج الوصول الذي تريده عمدًا.
لا تنفذ chown على /tv داخل الحاوية دون تفكير
اقترح رد آخر من المجتمع:
sudo chown abc:abc /tv/تُعد هذه النصيحة محفوفة بالمخاطر عند نسخها دون سياق. إذ تُمثَّل ملكية الدليل الموصول في النهاية بمعرّفات رقمية على المضيف. أما الاسم abc يوجد داخل حاويات LinuxServer، وقد لا يكون موجودًا كحساب ذي معنى على المضيف. وقد يؤدي تغيير الملكية بشكل متكرر إلى التأثير في مكتبة وسائط كاملة على نحو غير متوقع.
قبل استخدام chown، فتأكد من:
- مسار المضيف الدقيق الذي سيُغيَّر؛
- معرّف المستخدم ومعرّف المجموعة المطلوبان على المضيف؛
- ما إذا كانت خدمات أخرى مثل qBittorrent أو SABnzbd أو Jellyfin أو مستخدمو SMB تحتاج إلى الوصول إلى الملفات نفسها؛
- ما إذا كانت المجموعة المشتركة أنسب من تغيير الملكية.
انسخ إعداداتك المهمة احتياطيًا، وتجنب إجراء تغييرات متكررة على الأذونات حتى تفهم تأثيرها.
خطّط لأذونات الوسائط المشتركة عبر حزمة ARR بأكملها
نادرًا ما يعمل Sonarr وRadarr بمفردهما. ينشئ عميل التنزيل الملفات أولًا، ثم يستوردها Sonarr أو Radarr، وقد يقرأ Jellyfin النتيجة. وإذا استخدمت كل حاوية معرّفات وعمليات تركيب غير مرتبطة، فقد ينشئ أحد التطبيقات ملفات لا يستطيع تطبيق آخر تعديلها.
يتمثل التصميم الأنظف في منح التطبيقات مجموعة مشتركة أو تعيين PUID/PGID متوافقًا لمجموعة البيانات المشتركة. كما توصي LinuxServer بمسارات مجلدات مُخطط لها جيدًا حتى يتمكن عملاء التنزيل وتطبيقات ARR من استخدام الروابط الصلبة أو عمليات النقل الذرية عند الاقتضاء.
على سبيل المثال، بدل التعامل مع التنزيلات والوسائط باعتبارها عمليات تركيب معزولة وغير مترابطة، يمكن لشجرة بيانات واحدة مشتركة على المضيف أن تجعل فهم الأذونات واتساق المسارات أسهل:
/data
├── downloads
├── media
│ ├── movies
│ └── tvيعتمد مسار ZimaOS الدقيق على مخزن التخزين لديك، ولا ينبغي نسخه دون تحقق.
متى يكون الحل البديل باستخدام معرّفات الجذر مفيدًا؟
تعيين PUID/PGID إلى 0 قد يكون مفيدًا كاختبار تشخيصي سريع:
- إذا اختفى الخطأ فورًا، فمن المحتمل أن يكون تركيب الحاوية نفسه صحيحًا.
- من المرجح أن تكون المشكلة المتبقية في ملكية المضيف أو تعيين الأذونات.
بعد التأكيد، يتمثل الهدف الأكثر أمانًا على المدى الطويل في منح الحاوية الأذونات اللازمة فقط لمسارات الوسائط والتنزيل. وإذا جعل نموذج تخزين ZimaOS لديك تعيينًا بغير صلاحيات الجذر غير عملي، فوثّق سبب الحاجة إلى معرّفات الجذر، وقيّد الأدلة الموصولَة بعناية.
Restart the Apps After Changing PUID or PGID
أعد تشغيل التطبيقات بعد تغيير PUID أو PGID
- يتم تطبيق PUID وPGID عند بدء تشغيل الحاوية. بعد تغييرهما في ZimaOS:
- احفظ إعدادات التطبيق.
- أعد تشغيل حاوية Sonarr/Radarr أو أنشئها من جديد عبر ZimaOS.
- افتح إعدادات المجلد الجذر مرة أخرى.
اختبر إنشاء المجلد المرتبط أو تحديده.
إذا ظل المجلد غير قابل للكتابة، فقارن الملكية الرقمية ووضع الأذونات لدليل المضيف بالمعرّفات التي تستخدمها الحاوية حاليًا.
- قائمة التحقق من أذونات Sonarr/Radarr في ZimaOS
- تأكد من تحميل مسار الوسائط على المضيف داخل Sonarr أو Radarr.
- تأكد من أن مسار الحاوية هو المسار المحدد داخل التطبيق.
- افحص UID وGID وبتات الأذونات لمسار المضيف.
تحقق من القيمة الحالية لـPUIDوPGID - في إعدادات تطبيق ZimaOS.
- فضّل المعرّفات التي تطابق المالك/المجموعة المقصودين على المضيف.
- أعد تشغيل الحاوية بعد تغيير المعرّفات.
- استخدم PUID/PGID 0 فقط مع فهمك لصلاحيات الوصول على مستوى الجذر التي يمنحها ذلك.
تجنب الأذونات التكرارية الواسعةأو استخدام chmod 777 بشكل أعمىchownالإصلاحات. - تأكد من أن عملاء التنزيل وخوادم الوسائط يستخدمون نموذجًا متوافقًا للأذونات المشتركة.
الأسئلة الشائعة حول أذونات Sonarr وRadarr
من هو المستخدم abc؟
abc abc هو اسم مستخدم الخدمة الداخلي الشائع الاستخدام في حاويات LinuxServer.io. ويحدد PUID وPGID هوية المضيف الرقمية التي تستخدمها تلك العملية للوصول إلى وحدات التخزين المرتبطة.
لماذا يفشل PUID=1000 وPGID=1000؟
تعمل هذه القيم فقط عندما يكون لدى UID/GID 1000 صلاحية الوصول المطلوبة إلى مجلد الوسائط على المضيف. وإذا كان مجلد RAID في ZimaOS مملوكًا لمستخدم أو مجموعة أخرى، فقد تتمكن الحاوية من رؤيته لكنها لن تتمكن من الكتابة فيه.
هل يحل PUID=0 وPGID=0 المشكلة؟
لقد عالج ذلك الحالة الأصلية في المجتمع، كما أكد المؤلف. لكنه يمنح أيضًا صلاحية وصول مكافئة لصلاحيات الجذر داخل نظام الملفات المرتبط، لذلك لا ينبغي اعتماده تلقائيًا كتهيئة دائمة مفضلة.
هل ينبغي أن أستخدم chmod 777 لمجلد الوسائط؟
لا، ليس كحل افتراضي. فالأذونات القابلة للكتابة من قِبل الجميع واسعة أكثر من اللازم وقد تخفي عدم تطابق الملكية الفعلي. بدلًا من ذلك، طابق هوية الحاوية وأذونات المجموعة المشتركة بشكل مقصود.
هل ينبغي أن يستخدم Sonarr وRadarr وعميل التنزيل نفس PUID/PGID؟
لا يلزم أن تكون معرّفات المستخدمين متطابقة دائمًا، لكن يجب أن يتوافق نموذج الملكية/المجموعة بينهما مع أي ملفات ومجلدات يتشاركانها. ويُعد استخدام مجموعة مشتركة موحّدة طريقة شائعة لتجنب حالات فشل الاستيراد وإعادة التسمية.
