إذا فقد Plex أو Radarr أو Sonarr أو أي تطبيق Docker آخر إمكانية الوصول إلى وحدة NAS بعيدة عبر SMB بعد كل إعادة تشغيل لـ ZimaOS، فتحقق من تركيب المضيف قبل تغيير التطبيق. لا يمكن للحاوية رؤية مشاركة شبكية إلا إذا نجح ZimaOS في تركيبها وظل مسار الربط في Docker يشير إلى الموقع المركّب.
استعادت حالة مجتمعية تتعلق بمشاركة Synology الوصول إليها في كل مرة عندما أعاد المستخدم تحديد المجلد نفسه في منتقي مسار Docker Compose. يشير ذلك بقوة إلى مشكلة في استمرارية التركيب أو المسار، لكن تفسير المنتدى بأن ZimaOS كان ينشئ دائمًا معرّف تركيب داخليًا جديدًا كان استنتاجًا من المجتمع، وليس سببًا جذريًا أكدته IceWhale. لذلك ينبغي أن يستكشف الدليل عملية التركيب والمسار وترتيب بدء التشغيل كلًّا على حدة.
تحقق أولًا من تركيب مشاركة SMB بعد إعادة التشغيل
قبل فتح Plex أو Radarr، افتح «الملفات» في ZimaOS وتصفّح مشاركة NAS البعيدة. إذا كانت المشاركة نفسها غير متاحة، فلن يكون تطبيق Docker هو المشكلة الأولى.
إذا كانت المشاركة مفقودة
تحقق من أن وحدة NAS البعيدة متصلة بالإنترنت، وأن عنوان IP/اسم المضيف لا يزال يُحل، وأن بيانات الاعتماد المحفوظة لا تزال صالحة. أعد ربط المشاركة من خلال سير عمل «تخزين الشبكة» في ZimaOS إذا لزم الأمر.
إذا كانت المشاركة ظاهرة في «الملفات»
ثم انتقل إلى تعيين Docker. عملية التركيب على المضيف موجودة، لكن قد يظل التطبيق يشير إلى مسار قديم أو غير متاح.
استخدم تخزين الشبكة في ZimaOS بدلًا من إدخال fstab مكتوب يدويًا
فكّر المستخدم المصدر في تعديل /etc/fstab. لا يُعد ذلك أفضل حل أول لنظام تشغيل شبيه بالأجهزة الجاهزة، إذ يدير التخزين الشبكي بالفعل من خلال واجهته.
تُظهر وثائق ZimaOS الحالية إمكانية الوصول المستندة إلى SMB إلى وحدة NAS أخرى باعتبارها جزءًا من سيرَي عمل الترحيل والتخزين الشبكي. استخدم هذا المسار المُدار أولًا حتى يتمكن ZimaOS من إدارة بيانات الاعتماد وحالة التركيب بشكل متسق.
يوفّر دليل ترحيل NAS في ZimaOS المرجع الحالي.
تحقّق من مسار مضيف Docker، وليس مسار الحاوية فقط
تتضمن تعيينات وحدات تخزين Docker جانبين:
- مسار المضيف: المكان الذي يرى فيه ZimaOS مجلد Synology المُحمّل؛
- مسار الحاوية: المسار الثابت الذي يراه Plex أو Radarr أو Sonarr داخل الحاوية.
إذا كان جانب المضيف غير صالح بعد إعادة التشغيل، فقد يبدو مسار الحاوية صحيحًا في واجهة التطبيق بينما يشير إلى لا شيء مفيد.
يوضح دليل مسارات Docker في ZimaOS الحالي هذا الفرق.
أعد تحديد المجلد مرة واحدة كاختبار تشخيصي
إذا كانت المشاركة البعيدة ظاهرة في الملفات لكن التطبيق لا يستطيع الوصول إليها، فافتح إعدادات التطبيق أو Compose وأعد تحديد مجلد المضيف باستخدام منتقي المسارات في ZimaOS.
إذا عادت إمكانية الوصول فورًا من دون تغيير بيانات الاعتماد أو مسارات الحاوية، فهذا دليل قوي على أن الخلل يقع بين نقطة التحميل المُدارة وربط Docker للمجلد.
تحقّق من ترتيب بدء التشغيل بعد كل إعادة تشغيل
تعتمد وحدة تخزين SMB البعيدة على الشبكة، وإمكانية الوصول عبر DNS أو عنوان IP، والمصادقة، وكون جهاز NAS جاهزًا. قد تبدأ حاويات Docker قبل أن تصبح نقطة التحميل البعيدة متاحة.
اختبار بسيط
- أعد تشغيل ZimaOS؛
- انتظر حتى تصبح المشاركة البعيدة قابلة للتصفح في الملفات؛
- أعد تشغيل تطبيق Docker المتأثر فقط؛
- تحقّق مما إذا كانت الوسائط أو التنزيلات قد عادت.
إذا نجح ذلك بشكل موثوق، فقد يكون المسار ثابتًا، وقد تكون المشكلة الحقيقية في توقيت بدء التشغيل بدلًا من تغيّر معرّفات التحميل.
تحقّق من الأذونات على كلا النظامين
يجب أن يكون لحساب Synology المستخدم لتحميل SMB صلاحية الوصول إلى مجلدات الوسائط. بعد ذلك، يجب أن تكون نقطة التحميل في ZimaOS قابلة للوصول من عملية Docker. وأخيرًا، يجب أن يستخدم التطبيق مسار الحاوية الصحيح.
قد تبدو مشكلات الأذونات مشابهة لاختفاء نقطة التحميل، لذا تحقّق من ظهور «تم رفض الإذن» بشكل منفصل عن «المسار غير موجود» أو «لا يوجد ملف كهذا».
لماذا قد تجعل تغييرات fstab اليدوية عملية الاسترداد أكثر صعوبة
قد يؤدي التثبيت المخصص إلى إضافة ملفات بيانات اعتماد، وتبعيات إقلاع، وخيارات توقيت، وسلوكيات فشل لا يديرها ZimaOS في واجهته. وإذا فشل هذا التثبيت المخصص أثناء الإقلاع، فقد تبدأ التطبيقات بالعمل على مجلد فارغ.
استخدم fstab فقط عندما يتعذر على سير عمل التخزين الشبكي المُدار تلبية أحد المتطلبات، وتكون مستعدًا لصيانة التثبيت عبر التحديثات.
كيفية جعل تطبيقات الوسائط أكثر قدرة على التحمّل
- استخدم عنوان IP ثابتًا لجهاز NAS أو اسم DNS محليًا موثوقًا.
- أبقِ المشاركة البعيدة مُهيّأة عبر وحدة التخزين الشبكية.
- اربط مجلدًا ثابتًا واحدًا على المضيف داخل الحاوية.
- استخدم مسار الحاوية نفسه باستمرار عبر Radarr وSonarr وعملاء التنزيل وخوادم الوسائط.
- بعد التحديثات أو تغييرات التخزين، تحقّق من التثبيت قبل تغيير مكتبات التطبيقات.
يساعد دليل استكشاف أخطاء شبكة LAN وإصلاحها على تحديد ما إذا كان العطل يبدأ من طبقة الشبكة، بينما يوفّر دليل أساسيات مسارات Docker سياقًا حول Docker.
الأسئلة الشائعة
لماذا تفقد تطبيقات Docker لديّ مشاركة Synology بعد إعادة تشغيل ZimaOS؟
الطبقات الأكثر احتمالًا هي عدم إعادة تثبيت مشاركة SMB، أو استخدام التطبيق لمسار مضيف قديم، أو بدء تشغيل الحاوية قبل أن تصبح المشاركة البعيدة جاهزة. اختبر هذه الاحتمالات بشكل منفصل.
هل ينبغي تعديل /etc/fstab؟
ليس كحل أول. يُفضّل استخدام وحدة التخزين الشبكية في ZimaOS ليُدير النظام المشاركة. تضيف عمليات التثبيت اليدوية أعباء صيانة وتعقيدًا في ترتيب الإقلاع.
لماذا يؤدي إعادة تحديد المجلد نفسه إلى إصلاح التطبيق؟
إنه يحدّث تعيين الربط من جانب المضيف. وهذا دليل على وجود مشكلة في التثبيت أو المسار، حتى عندما لا يكون اسم المجلد الظاهر قد تغيّر.
هل يمكنني استخدام مشاركة SMB بعيدة مع Plex وتطبيقات Arr؟
نعم، بشرط أن يقوم ZimaOS بتثبيته بشكل موثوق، وأن تكون الأذونات صحيحة، وأن تستخدم جميع الحاويات مسارات متسقة على المضيف وداخل الحاوية.
