استخدم الإعداد المصدر ZimaOS كخادم تطبيقات، مع إبقاء جميع الوسائط على جهاز Unraid NAS موجود مسبقًا. عملت Plex وEmby وOpenWebUI على ZimaOS وتمكنت في البداية من الوصول إلى البيانات البعيدة بنجاح. بعد نحو أسبوع—ومرة أخرى بعد إعادة التشغيل—اختفت مشاركة الشبكة من بيئة التطبيقات. أدت إعادة توصيلها في «الملفات» وإعادة تشغيل التطبيقات إلى استعادة الوصول.
يكشف هذا عن حدّ تصميمي مهم في عمليات النشر التي تتكون من «عقدة حوسبة + جهاز NAS منفصل»: فموقع الشبكة الظاهر في تطبيق «الملفات» ليس تلقائيًا هو نفسه نقطة تحميل دائمة على المضيف يمكن لكل حاوية Docker الاعتماد عليها أثناء عمليات إعادة التشغيل وإعادة الاتصال.
فقدت التطبيقات وسائطها لأن المشاركة البعيدة اختفت
لم يُبلّغ عن حدوث أعطال في قواعد بيانات Plex وEmby. بل فقدتا ببساطة المسارات المؤدية إلى البيانات الموجودة على Unraid. وعندما أعاد المستخدم إضافة المشاركة، بدأت التطبيقات في إعادة بناء المكتبات أو إعادة فحصها.
يشير ذلك إلى مشكلة في إمكانية الوصول إلى التخزين، لا إلى تلف تثبيت Plex أو Emby.
الوصول عبر «الملفات» والوصول إلى وحدات تخزين Docker طبقتان مختلفتان
يمكن لتطبيق «ملفات» في ZimaOS الاتصال بالتخزين المحلي عبر الشبكة باستخدام SMB. يتيح هذا الاتصال للمستخدم تصفح الملفات ونقلها من واجهة الويب.
يحتاج تطبيق Docker إلى مسار على المضيف يظل متاحًا عند بدء الحاوية. فإذا اختفت نقطة تحميل الشبكة الأساسية أو أُعيد إنشاؤها وفق دورة حياة مختلفة، فقد يرى التطبيق مسارًا فارغًا أو مفقودًا، حتى لو تمكن تطبيق «الملفات» من إعادة الاتصال لاحقًا.
نصيحة UUID لا تنطبق على مشاركة SMB عادية
اقترح أحد الردود إجراء التحميل «باستخدام UUID». وأشار مشارك آخر بشكل صحيح إلى أن مشاركة Unraid البعيدة كانت متصلة عبر عنوان IP وSMB، وليست جهاز كتل محليًا.
تفيد UUIDs في تعريف أنظمة الملفات المحلية وأجهزة الكتل. أما مشاركة SMB فتُعرَّف من خلال مسار خادم/مشاركة الشبكة، وبيانات الاعتماد، وإعدادات التحميل.
اقترح أحد أفراد المجتمع استخدام /etc/fstab
ذكر مشارك آخر أن تحميل SMB مستمرًا في /etc/fstab كان مستقرًا لديه. وهذا أسلوب تقليدي في إدارة Linux ويمكن أن ينجح، لكنه كان نصيحة من المجتمع، ولم يؤكد صاحب المنشور الأصلي وجود إعداد نهائي ناجح.
وعلى نظام تشغيل من نمط الأجهزة الجاهزة، يعني إعداد تحميل المضيف يدويًا أيضًا أنك تتحمل مسؤولية ترتيب الإقلاع، وبيانات الاعتماد، وسلوك إعادة الاتصال، والتوافق بين التحديثات.
لا يزال ZimaOS الحالي يدعم التخزين المحلي عبر الشبكة في «الملفات»
توضح وثائق IceWhale الحالية إمكانية إضافة التخزين المحلي عبر الشبكة من الشريط الجانبي لتطبيق «الملفات» عبر إدخال عنوان IP لجهاز NAS البعيد وبيانات الاعتماد. وهذه هي الطريقة المدعومة لتصفح البيانات أو ترحيلها من جهاز NAS آخر.
استخدم سير عمل الاتصال الحالي بالتخزين المحلي عبر الشبكة عندما يكون الهدف هو الوصول إلى الملفات أو ترحيلها.
لم يثبت النقاش وجود طريقة مدعومة لتحميل مشاركة دائمة للتطبيقات
لم يرد أي مطور من IceWhale بإجراء موثق يوضح «تحميل مشاركة SMB هذه بشكل دائم لتطبيقات Docker»، كما ظل صاحب المنشور الأصلي متشككًا في قدرة اتصال «الملفات» على الاستمرار خلال دورة الحياة التي لوحظت.
يجب أن تحافظ المقالة الموثوقة على هذه الحالة غير المحسومة، بدلًا من تقديم اقتراح fstab من المجتمع بوصفه الحل الرسمي.
بالنسبة إلى خادم الوسائط، حدد مكان وجود حدّ التحميل المستقر
إذا كان يجب أن تستعيد Plex وEmby عملهما تلقائيًا بعد انقطاع الطاقة، فيجب تحميل مسار الوسائط البعيد قبل بدء الحاويات، وأن يظل مستقرًا طوال عمليات إعادة الاتصال. ويمكن تحقيق ذلك عبر عدة بنى في Linux، لكن ينبغي اختبار الخيار المحدد على إصدار ZimaOS الحالي.
بالنسبة إلى الإعدادات المهمة التي تعمل على مدار الساعة، تحقّق من إعادة التشغيل البارد، وإعادة تشغيل جهاز NAS البعيد، وإعادة تشغيل المحول الشبكي، وفقدان الشبكة مؤقتًا، قبل اعتبار مسار التخزين جاهزًا للاستخدام الإنتاجي.
تجنب عمليات إعادة فحص الوسائط غير الضرورية
عندما تختفي مشاركة الوسائط مؤقتًا، قد تفسر Plex أو Emby ذلك على أنه إزالة للمحتوى، اعتمادًا على إعدادات المكتبة. تجنب تنظيف المكتبة التلقائي المدمر إلى أن يثبت استقرار سلوك التحميل البعيد.
الأسئلة الشائعة حول تحميل التطبيقات من جهاز NAS بعيد
هل أدت إعادة توصيل المشاركة في «الملفات» إلى استعادة عمل التطبيقات؟
أفاد المستخدمون بأن إعادة توصيل المشاركة وإعادة تشغيل التطبيقات أعادتا الوصول.
هل يمكن تحميل مشاركة SMB باستخدام UUID لنظام الملفات؟
ليس بالمعنى نفسه المستخدم مع القرص المحلي. إذ تستخدم SMB مسار مشاركة شبكية وبيانات اعتماد.
هل نشرت IceWhale إصلاحًا مؤكدًا لتحميل دائم لتطبيقات Docker في هذا النقاش؟
لا. انتهى النقاش العام دون تقديم مثل هذا الإصلاح.
