عندما لا يستطيع Jellyfin أو Emby أو Plex رؤية سوى ZimaOS-HD، ولا يرى القرص الصلب أو NVMe أو RAID الذي توجد عليه وسائطك فعليًا، فالمشكلة عادةً ليست أن Docker «يفتقر إلى صلاحية الوصول إلى NAS». لا تستطيع الحاوية تصفح مجلدات المضيف إلا تلك التي يعيّنها ZimaOS لها كوحدات تخزين.
كان هذا هو الحل الأساسي في موضوع المصدر في يونيو 2024. أخبر ETWang1991 المستخدمين بفتح إعدادات التطبيق وإضافة وحدة التخزين الجديدة كوحدة تخزين. وردّ صاحب المنشور الأصلي بأن الأمر نجح بعد ذلك «بشكل رائع»، ثم توصل مستخدم آخر لـ Jellyfin إلى النتيجة نفسها لاحقًا بعد رؤية لقطات الشاشة.
تطبيق Docker لا يرى نظام ملفات مضيف ZimaOS بأكمله
العزل بين الحاويات مقصود. يستطيع Jellyfin رؤية /Media داخل حاويته فقط إذا كان ذلك المسار معيّنًا إلى دليل مضيف حقيقي يحتوي على الوسائط.
لا يعني ظهور محرك أقراص في ملفات ZimaOS تلقائيًا أنه سيظهر داخل كل حاوية في متجر التطبيقات.
افتح إعدادات التطبيق وحرّر وحدات التخزين
اختر مجلد الوسائط الحقيقي على المضيف
اختر الدليل الموجود على مساحة التخزين الفعلية والذي يحتوي على مكتبتك، بدلًا من كتابة مسار علوي مُخمَّن مثل /Main-Storage.
للمسارات على المضيف والحاوية وظائف مختلفة
يجب أن يكون المسار داخل الحاوية بسيطًا وثابتًا، مثل /media أو /Media. داخل Jellyfin، أضف المكتبات باستخدام مسار الحاوية هذا، وليس مسار المضيف الخام.
أكد عدة مستخدمين أن تعيين وحدات التخزين كان الخطوة المفقودة
ذكر صاحب المنشور الأصلي أن التغيير نجح. ورأى مستخدم آخر لديه وحدة تخزين رئيسية بتكوين RAID 5 قرصَ نظام التشغيل فقط في البداية، ثم رد قائلًا إن لقطات الشاشة ألهمته: «كان عليّ إضافة وحدات التخزين إلى Jellyfin.»
وهذا حل مؤكد المصدر، وليس حلاً التفافيًا تخمينيًا لمشكلة الأذونات.
كانت الأقراص المضافة فرديًا نقطة إزعاج في واجهة المستخدم عام 2024
واجه بعض المشاركين صعوبة في تحديد الأقراص المفعّلة فرديًا أو مساحة تخزين RAID في أداة الاختيار القديمة. وردّ موظفو IceWhale بأن الأقراص الفردية كان يمكن تفعيلها واستخدامها، ثم ذكروا لاحقًا أن الواجهة قد تحسّنت.
تنتمي تلك القيود لعام 2024 إلى الإصدارات الأولى من ZimaOS. أما ZimaOS الحالي، فتُظهر إعدادات التخزين والتطبيقات فيه التخزين المُدار بوضوح أكبر.
يوثّق ZimaOS الحالي مسارات تخزين التطبيقات بوضوح
توضح وثائق IceWhale الحالية الآن أن حاويات متجر التطبيقات تحفظ البيانات المستمرة في مجلدات حقيقية على المضيف، وأنه يمكن فحص تعيينات المجلدات لكل تطبيق وتغييرها من إعداداته.
استخدم نموذج مسارات تطبيقات Docker الحالي في ZimaOS عند تعيين Jellyfin أو Emby أو Plex أو أي تطبيق آخر.
موقع AppData وموقع الوسائط منفصلان
يمكن حفظ ملفات إعدادات التطبيق وقاعدة البيانات ضمن موقع بيانات التطبيقات المُكوَّن، بينما تُحفظ ملفات الوسائط الكبيرة على مجموعة RAID أو HDD أخرى. لا تُعيّن مجلد إعدادات التطبيق إلى مجلد الأفلام، ولا تفترض أن نقل AppData ينقل كل مكتبة وسائط.
يمكن لـ ZimaOS الحالي نقل بيانات التطبيقات المُدارة
يمكن لترحيل البيانات الحالي نقل صور Docker وبيانات تطبيقات Docker إلى مساحة تخزين أخرى. وهذا يحل مشكلة مختلفة عن إضافة مجلد وسائط: فأحدهما يحدد مكان حفظ التطبيق نفسه لحالته المستمرة، بينما يمنح الآخر الحاوية إمكانية الوصول إلى وسائط المستخدم.
اطّلع على سير عمل ترحيل بيانات التطبيقات المُدارة الحالي.
اختر عمليات تثبيت الوسائط للقراءة فقط عندما لا يحتاج التطبيق إلى تعديل الملفات
يحتاج خادم الوسائط عادةً إلى قراءة الأفلام والموسيقى، لكنه لا يحتاج بالضرورة إلى أذونات حذف مكتبة المصدر أو إعادة تنظيمها. عندما تسمح حزمة التطبيق الحالية بذلك، يقلل ربط الوسائط بوضع القراءة فقط من الضرر الذي قد تُحدثه حاوية مخترقة أو مُهيأة بشكل غير صحيح.
تحتاج التطبيقات التي تعيد تسمية الملفات أو تنقلها أو تستوردها عمدًا—مثل بعض حِزم التنزيل أو إدارة الصور—إلى نموذج مختلف لأذونات الكتابة.
ربط وحدات التخزين وأذونات نظام الملفات عمليتان منفصلتان للتحقق
تُعد إضافة مجلد المضيف الصحيح المتطلب الأول. ويجب أيضًا أن تكون لدى عملية الحاوية أذونات كافية في نظام الملفات لقراءة ذلك المجلد أو الكتابة فيه. إذا ظهر مجلد مُربط لكنه بدا فارغًا أو أعاد أخطاء أذونات، فحدّد معرّف المستخدم/المجموعة للحاوية وملكية المضيف قبل استخدام أذونات واسعة. chmod 777 حلول بديلة.
كانت المشكلة في المصدر من عام 2024 تتمثل أساسًا في فقدان ربط وحدة التخزين؛ ولا ينبغي تشخيص مشكلات الأذونات اللاحقة إلا بعد تركيب المسار الصحيح فعليًا.
الحفاظ على ثبات المسار داخل الحاوية عبر عمليات إعادة التثبيت
إذا أُنشئت مكتبة Jellyfin باستخدام /Media، وتغيير مسار الحاوية إلى /mnt/media2 أثناء إعادة التثبيت قد يجعل المكتبة الحالية تبدو مفقودة، رغم أن ملفات المضيف لم تنتقل قط.
حافظ على المسار نفسه داخل الحاوية متى أمكن، أو حدّث إعداد مكتبة التطبيق عمدًا بعد تغيير الربط.
الواجهة الحالية أفضل من منتقي عام 2024، لكن قاعدة Docker لم تتغير
أقرت IceWhale في المصدر بأن منتقي التخزين القديم كان مربكًا، ثم حسّنت الواجهة لاحقًا. يعرض ZimaOS الحالي الآن موقع بيانات التطبيق، ومسارات المضيف/الحاوية، وترحيل التخزين، واستخدام ذاكرة التخزين المؤقت للتطبيق بشكل أكثر وضوحًا.
تظل قاعدة Docker الأساسية كما هي: لا ترى الحاوية سوى ما يتم تركيبه فيها.
الأسئلة الشائعة حول الوصول إلى تخزين التطبيقات
لماذا يمكن لـ «ملفات ZimaOS» رؤية محرك أقراص بينما لا يستطيع Jellyfin ذلك؟
تعمل «الملفات» على مستوى المضيف؛ بينما يعمل Jellyfin داخل حاوية ولا يرى سوى وحدات التخزين المُربطة.
هل تم تأكيد نجاح إضافة وحدة التخزين في سلسلة النقاش الأصلية؟
نعم. أبلغ عدة مستخدمين عن نجاح العملية بعد إضافة وحدة تخزين التخزين/الوسائط.
هل ينبغي لـ Jellyfin تصفح مسار المضيف الخام؟
لا. ينبغي أن يتصفح Jellyfin المسار داخل الحاوية المعيّن لمجلد المضيف المُربط.
