إن نقل مجلد وسائط إلى محرك أقراص آخر في ZimaOS لا يُحدّث تلقائيًا كل تطبيقات Docker التي كانت تستخدم المسار القديم. وهذا بالضبط ما حدث في المصدر: نُقلت ملفات الأفلام إلى وحدة NVMe جديدة، وعكس Radarr موقع التخزين الجديد، لكن Jellyfin ظل يشير إلى نقطة الربط القديمة ولم يعد قادرًا على العثور على الفيلم.
يتمثل الحل في تحديث مسار وحدة التخزين على المضيف للتطبيق، مع الإبقاء على مسار ثابت داخل الحاوية مثل /movies أو /media. وقد عرض Zima-Giorgio كلاً من اكتشاف المسار عبر CLI ومنتقي المجلدات في الواجهة الرسومية، وأكد المستخدم فورًا أن طريقة الواجهة الرسومية حلّت المشكلة.
يحتوي Docker على مسار مضيف ومسار حاوية
يبدو التعيين من حيث المبدأ هكذا:
/real/path/on/ZimaOS → /path/inside/appيجب أن يشير الجانب الأيسر إلى جهاز التخزين والمجلد اللذين توجد فيهما الملفات فعليًا. أما الجانب الأيمن فهو المسار الذي يراه Jellyfin أو Radarr داخل الحاوية.
لا يوجد جهاز تخزين ZimaOS ثانٍ تلقائيًا ضمن /DATA
/DATA/... إلى إنشاء مجلد على وحدة التخزين الخاطئة.كان ذلك هو مصدر الالتباس الأساسي. إذ يشير /DATA/extra-movies إلى منطقة بيانات النظام أو المنطقة الافتراضية، وليس تلقائيًا إلى المجلد الموجود على محرك NVMe الجديد.
اقترح Zima-Giorgio التحقق من /media
للتعرّف يدويًا على مسار المضيف، اقترح Giorgio استخدام:
ls /mediaفي ذلك الوقت، ظهرت وحدات التخزين المستقلة أو المركّبة ضمن /media. وقد يختلف المسار الدقيق وفقًا لإدارة التخزين الحالية وأسماء الأجهزة، لذا استخدم المسار الذي تعرضه الواجهة الحالية بدلًا من التخمين.
كان منتقي المجلدات في الواجهة الرسومية هو الحل المؤكد في المصدر
يدعم ZimaOS الحالي صراحةً تحديث مسارات وحدات التخزين بعد نقل البيانات
تنص وثائق IceWhale الحالية لمسارات التطبيقات الآن على أنه إذا امتلأ محرك أقراص، يمكنك نقل بيانات التطبيق إلى محرك آخر وتحديث المسار من إعدادات التطبيق دون إعادة تثبيت التطبيق.
استخدم سير عمل مسارات Docker الحالي في ZimaOS.
حافظ على ثبات مسار الحاوية متى أمكن
إذا كان Jellyfin يستخدم بالفعل /Media داخليًا، فغيّر جانب المضيف فقط إلى المجلد الفعلي الجديد. فالحفاظ على ثبات مسار الحاوية يمنع قاعدة بيانات التطبيق أو مكتبته من رؤية سلسلة مسار مختلفة تمامًا.
حدّث كل تطبيق يعيّن المجلد المنقول
قد يكون لكل من Radarr وSonarr وqBittorrent وJellyfin وPlex وأدوات الاستيراد تعيين خاص به لوحدة التخزين. رؤية أحد التطبيقات للمجلد الجديد لا تُحدّث التطبيقات الأخرى.
تحقق قبل حذف المجلد القديم
افتح فيلمًا في Jellyfin، ودَع Radarr يفحص المجلد الجذر، واختبر مسارات استيراد qBittorrent إذا كان ذلك مناسبًا، وتحقق من الأذونات. احتفظ بالمجلد المصدر القديم إلى أن تستخدم جميع التطبيقات تعيين المضيف الجديد بنجاح.
يختلف نقل الوسائط عن نقل بيانات التطبيق
تُعد مجلدات الأفلام والبرامج التلفزيونية مكتبات محتوى عادية. أما بيانات التطبيق فقد تحتوي على قواعد بيانات SQLite أو PostgreSQL، وصور مصغرة، وفهارس، وحالة التطبيق، وقد تتطلب إيقاف التطبيق أو استخدام ترحيل البيانات في ZimaOS لضمان الاتساق. لا تتعامل مع كل وحدة تخزين على أنها مجلد وسائط يمكن سحبه وإفلاته ببساطة.
أعِد التحقق من الأذونات على وحدة التخزين الجديدة
قد يفشل مسار المضيف الجديد الصحيح إذا كانت هوية الحاوية قادرة على القراءة من محرك الأقراص القديم دون الجديد. بعد إعادة التعيين، تحقق من قدرة التطبيق على قراءة المجلد المستهدف، والكتابة فيه عند الحاجة، دون منح أذونات كتابة عامة غير ضرورية.
الأسئلة الشائعة حول مسار الوسائط المنقول
لماذا فقد Jellyfin الملفات بعد نقلها؟
كانت نقطة ربط Docker الخاصة به لا تزال تشير إلى مجلد المضيف القديم.
هل أكد المستخدم في المصدر أن منتقي الواجهة الرسومية ساعده؟
نعم. فقد رد فورًا بأنه لم يكن يعلم بوجود منتقي المسار، وأنه حلّ المشكلة التي واجهها.
هل ينبغي أن أكتب /DATA لكل محرك تخزين جديد؟
لا. استخدم مسار المضيف الفعلي الذي يعرضه ZimaOS أو تحدده لهذا الجهاز التخزيني.
