يوضح موضوع النقاش الأصلي سبب عدم وجوب اعتبار عبارة «لا يستطيع التطبيق الكتابة إلى RAID» على الفور مشكلة أذونات واحدة في ZimaOS. فقد زعم أول رد من المجتمع أن حاويات متجر التطبيقات تتمتع عادةً بوصول للقراءة فقط خارج مجلد AppData الخاص بها، ما لم يتم إنشاء مجلد أو «لمسه» عبر تطبيق الملفات. جرّب صاحب المنشور الأصلي ذلك بالضبط، لكنه ظل غير قادر على إنشاء مجلدات SFTPGo أو حذف الموسيقى من Navidrome.
بعد ظهور هذه الأمثلة المضادة، عدّل المجيب تفسيره: فملكية نظام الملفات ليست سوى طبقة واحدة. لكل تطبيق أيضًا مستخدم حاوية خاص به، ومسارات داخلية متوقعة، وحدود للميزات. وهذا التصحيح اللاحق هو الدرس الأكثر موثوقية.
هناك ثلاث طبقات مختلفة للأذونات
- تخزين مضيف ZimaOS: مجلد RAID أو القرص الحقيقي وملكِيته ووضع أذوناته.
- تعيين وحدة تخزين Docker: ما إذا كان مجلد المضيف موصولًا بالحاوية وما إذا كان التوصيل للقراءة فقط.
- سلوك التطبيق: المستخدم الذي يعمل التطبيق بصلاحياته، وما إذا كان البرنامج نفسه يدعم إنشاء الملفات أو حذفها أو إعادة تسميتها.
قد يبدو الفشل في أي طبقة من هذه الطبقات كأنه «تم رفض الإذن».
لم يكن إنشاء المجلد في تطبيق الملفات حلًا شاملًا
كان الاقتراح الأول هو إنشاء المجلد الهدف أو نقله عبر تطبيق ملفات ZimaOS حتى تُطبَّق ملكيته بشكل صحيح. أنشأ صاحب المنشور الأصلي srv/data على RAID، ووجّه SFTPGo إليه، لكنه استمر في تلقي أخطاء رفض الإذن.
لذلك لا يمكن اعتبار طريقة تطبيق الملفات حلًا مضمونًا لجميع التطبيقات.
يحتاج SFTPGo إلى مسار قابل للكتابة يتوافق مع مستخدم وقت التشغيل وإعداداته
يعمل SFTPGo بصلاحياته الخاصة وبقواعد المجلدات الافتراضية ومجلد المنزل. وقد يكون دليل المضيف موجودًا ومرئيًا، لكنه يظل غير قابل للكتابة من جانب عملية SFTPGo.
في عملية نشر حالية، تحقّق معًا من مجلد المضيف، ووضع توصيل Docker، ومعرّف UID/GID للحاوية، ومجلد المنزل أو المجلد الافتراضي المهيأ لمستخدم SFTPGo.
يُعد Navidrome أساسًا خادمًا لمكتبة الوسائط
ذكر المجيب الأصلي أنه ينبغي التعامل مع Navidrome على أنه للقراءة فقط فيما يخص إدارة المكتبة، وأن حذف المقاطع من داخل Navidrome لم يكن مدعومًا في سياقه. لذلك فإن عدم قدرة المستخدم على حذف أغنية لم يكن دليلًا جيدًا على تعطل أذونات RAID بشكل عام.
أدر ملفات الموسيقى المصدر باستخدام تطبيق الملفات أو أداة أخرى لإدارة الملفات، ما لم يوثّق الإصدار الحالي المحدد من Navidrome ميزة مدعومة لتعديل الملفات.
تحقّق مما إذا كانت وحدة تخزين Docker موصولة بوضع القراءة فقط
يمكن لتعيين وحدة التخزين استخدام وضع القراءة فقط صراحةً. وإذا كان من المفترض أن يعدّل التطبيق الملفات، فيجب تعيين مجلد المضيف بوضع القراءة والكتابة، كما يجب أن تكون لهوية العملية صلاحية الكتابة على نظام ملفات المضيف.
يتيح ZimaOS الحالي للمستخدمين فحص تعيينات وحدات تخزين التطبيقات وتعديلها من إعدادات التطبيق.
يجعل ZimaOS الحالي مسارات المضيف والحاوية أكثر وضوحًا
توثّق IceWhale الآن العلاقة بين المسارات داخل التطبيق، مثل /config أو /media، ومجلدات التخزين الحقيقية التي تدعمها.
استخدم نموذج مسارات التطبيقات الحالي في ZimaOS قبل استخدام chmod/chown التكراريين كاستجابة أولى.
لا تستخدم chmod 777 كاختصار للتشخيص
قد تخفي أذونات الكتابة الواسعة المشكلة الحقيقية، كما قد تكشف البيانات المشتركة أمام عمليات غير ذات صلة. وهي لا تصلح أيضًا مشكلة تطبيق يفتح وحدة التخزين عمدًا بوضع القراءة فقط أو يرفض مسارًا من خلال إعداداته الخاصة.
غيّر الحد الأدنى فقط من أذونات الملكية أو المجموعة التي يحتاج إليها التطبيق.
تسلسل تشخيص أفضل
- أكّد مجلد المضيف المحدد في ZimaOS.
- أكّد أن وحدة تخزين التطبيق تعيّن ذلك المجلد إلى مسار الحاوية المتوقع.
- تحقّق مما إذا كان التعيين للقراءة فقط.
- حدّد UID/GID أو المستخدم الذي تعمل به الحاوية.
- تحقّق من قدرة تلك الهوية على الكتابة إلى مجلد المضيف.
- أكّد أن التطبيق نفسه يدعم العملية التي تحاول تنفيذها.
الأسئلة الشائعة حول أذونات تخزين التطبيقات
هل أدى إنشاء المجلد مجددًا في تطبيق ملفات ZimaOS إلى حل حالة SFTPGo الأصلية؟
لا. جرّبه صاحب المنشور الأصلي، لكنه استمر في تلقي رسالة رفض الإذن.
هل يتحول مجلد RAID القابل للقراءة تلقائيًا إلى مجلد قابل للكتابة داخل كل تطبيق؟
لا. يظل وضع توصيل Docker، وUID/GID للحاوية، وسلوك التطبيق عوامل مهمة.
هل ينبغي استخدام Navidrome كمدير عام للملفات؟
لا. تعامل مع مصدر الموسيقى خارج Navidrome، ما لم يدعم التطبيق الحالي تعديل الملفات صراحةً.
