كانت المشكلة الأساسية أخطر من اختفاء المسار. بعد إعادة التشغيل، كان بإمكان SABnzbd أن يبدأ قبل تركيب مشاركة Synology SMB فعليًا. وكان الحاوي لا يزال يرى مجلدًا في مسار المضيف المتوقع، لذلك كان من الممكن أن يكتمل التنزيل ويبدو أنه نُقل بنجاح، بينما كان يُحفظ فعليًا على وحدة التخزين المحلية في ZimaOS بدلًا من NAS البعيد.
تمكّن المجتمع في النهاية من إنشاء حل يدوي فعّال باستخدام CIFS وfstab، وأكد صاحب المنشور الأصلي أن التركيب استمر بعد إعادة التشغيل. لكنه أوضح أيضًا المخاطر: فقد تؤدي إدخالة fstab غير صالحة إلى منع الإقلاع العادي، كما أن نقطة تركيب تحتوي على مسافة غير مُهربة كانت تؤدي إلى تعطل الإعداد. تعامل مع الأوامر على أنها إدارة مجتمعية مؤكدة المصدر، وليست إجراءً رسميًا حاليًا للتخزين الشبكي في ZimaOS.
كان توقيت التركيب هو سبب العطل الأساسي
كان مسار المصدر يبدو كما يلي:
/media/192.168.2.125/Moviesبعد إعادة التشغيل، لم تكن مشاركة SMB جاهزة عند بدء SABnzbd. وقد أدت إعادة إضافة وحدة التخزين نفسها بعد استقرار النظام إلى عملها مجددًا، مما يدعم بقوة أن المشكلة كانت في التوقيت وترتيب التشغيل، لا في تغيّر معرّف التركيب.
قد يتحول غياب التركيب البعيد إلى فخ يتمثل في مجلد محلي
إذا تلقى Docker مسار مجلد مضيف موجودًا محليًا بينما نظام الملفات البعيد غير متاح، فقد يكتب التطبيق داخل ذلك المجلد المحلي. وقد يظل السجل يقول إن الملف نُقل إلى /movies، بينما لا يظهر أي شيء على Synology.
قبل بدء التنزيلات الكبيرة، تحقّق من أن نظام الملفات البعيد المتوقع مركّب فعلًا، لا من مجرد وجود مجلد نقطة التركيب.
نقل المجتمع نقطة التركيب إلى مسار ثابت هو /DATA
كان التصميم المقترح هو تركيب مشاركة SMB في مسار محلي ثابت مثل:
/DATA/Media/Moviesثم ربط مسار المضيف الثابت هذا بـ SABnzbd. ويحافظ ذلك على قابلية التنبؤ بمسار الحاوي، بينما تتم إدارة نظام الملفات البعيد على مستوى المضيف.
أكد المستخدم المصدر أن /etc/fstab استمر بعد إعادة التشغيل
استخدم مثال المجتمع خيارات CIFS تتضمن _netdev، وإصدارًا محددًا من بروتوكول SMB، وقيم UID/GID/الوضع. وقال المستخدم إن إدخالة fstab استمرت وعملت بعد إعادة التشغيل.
لا تنسخ بيانات الاعتماد مباشرةً إلى إعدادات يمكن قراءتها عالميًا من دون التفكير في استخدام ملف بيانات اعتماد محمي.
أصبح nofail ضروريًا بعد أن منعت إدخالة معيبة الإقلاع
اكتشف المستخدم المصدر أن التركيب غير الصالح أو غير المتاح قد يتداخل مع عملية الإقلاع. واقترح الرد استخدام nofail كي يتمكن ZimaOS من متابعة الإقلاع إذا كانت وحدة NAS البعيدة غير متاحة.
كما يوضح _netdev لنظام التركيب أن هذا المورد يعتمد على الشبكة.
يجب التعامل مع المسافات في نقاط التركيب بصورة صحيحة
فشلت إدخالة ثانية في fstab لأن نقطة التركيب تضمنت TV Shows. ففي fstab تفصل المسافات بين الحقول، ولذلك يجب تهريب المسافة بطريقة مناسبة أو تجنبها باستخدام مجلد أبسط مثل TV_Shows.
استخدم صاحب المنشور لاحقًا مجلدًا منفصلًا بلا مسافات ونجح في ذلك.
اختبر دائمًا باستخدام mount -a قبل إعادة التشغيل
كانت الخطوة الأكثر أمانًا الواردة في المصدر هي:
sudo mount -aإذا أعاد الأمر خطأً، فأصلح بناء جملة fstab أو المسار قبل إعادة التشغيل. وتحقق أيضًا من أن نظام الملفات المركّب يحتوي على الملفات البعيدة المتوقعة.
فضّل التخزين الشبكي الحالي في ZimaOS عندما يلبي حالة الاستخدام
يمكن لإصدار ZimaOS الحالي الاتصال بوحدات تخزين SMB/LAN من خلال مسارات العمل الخاصة بالملفات/التخزين الشبكي. استخدم الواجهة المُدارة أولًا عندما توفر سلوك الاستمرارية وترتيب التشغيل الذي يتطلبه تطبيقك.
راجع مسار العمل الحالي للاتصال بـ Synology SMB.
يجب ألا يكتب الحاوي المتين فعلًا قبل التحقق من التركيب البعيد
حتى مع استخدام fstab، قد تكون وحدة NAS الشبكية غير متصلة لاحقًا. وبالنسبة إلى مسارات التنزيل/الاستيراد المهمة، أضف فحصًا للصحة أو بدء التشغيل، أو إجراءً تشغيليًا، يؤكد تركيب الوجهة البعيدة قبل أن يعالج SABnzbd المهام.
الأسئلة الشائعة حول تركيب SMB في SABnzbd
هل أثبت المصدر أن معرّف تركيب SMB تغيّر بعد إعادة التشغيل؟
لا. كانت الأدلة تدعم مشكلة في توقيت التركيب.
هل استمر fstab لدى المستخدم المصدر؟
نعم، لكن الإدخالات المشوهة أو غير المتاحة تسببت أيضًا في مشكلات بالإقلاع حتى تم تصحيحها.
لماذا قد يبدو التنزيل ناجحًا بينما لا يوجد ملف على Synology؟
يمكن للتطبيق الكتابة إلى مجلد نقطة التركيب المحلي عندما لا يكون نظام ملفات SMB البعيد مركّبًا فعليًا.
