بدأ هذا النقاش في مايو 2026 بوصفه انطباعًا أوليًا محبطًا بعد ليلة طويلة مع ZimaOS. بدا أن AdGuard Home وPi-hole يعملان داخل شبكات Docker معزولة بدلًا من شبكة LAN الخاصة بالمستخدم 192.168.60.0/24، ولم يعمل Jellyfin إلا بعد عدة محاولات، كما فشلت نسخ Time Machine الاحتياطية من جهاز MacBook Pro. لكن بعد إجراء مزيد من الاختبارات، تغيّر استنتاجان من الاستنتاجات الأصلية: أصبح AdGuard Home يعمل، كما أن مشكلة Time Machine انتقلت مع جهاز MacBook إلى مشاركة على TrueNAS، ما يشير إلى أن ZimaOS لم يكن السبب.
لذلك، يُعدّ هذا النقاش أكثر فائدة بوصفه دراسة حالة لاستكشاف الأخطاء وإصلاحها، لا حكمًا نهائيًا على نظام التشغيل. فهو يوضح سبب ضرورة عزل مشكلات شبكات Docker، وقوالب التطبيقات، وسلوك النسخ الاحتياطي من جهة العميل قبل إلقاء اللوم على منصة NAS نفسها.
عرض معالج إعداد AdGuard عناوين Docker بدلًا من عنوان LAN
بعد التثبيت القياسي، عرضت شاشة إعداد AdGuard Home للمستخدم عناوين مثل 127.0.0.1 و172.17.0.2. وكان المستخدم يتوقع رؤية عنوان LAN الثابت للمضيف الذي يعمل عليه ZimaOS، وهو 192.168.60.241.
لم يكن التبديل إلى شبكة المضيف حلًا مثاليًا
عثر المستخدم على حل بديل متداول في المجتمع غيّر وضع شبكة Compose إلى host. وبعد تغيير إعدادات التطبيق أيضًا، أصبح التثبيت غير قابل للوصول. وتكتسب هذه النتيجة السلبية أهمية لأنها تعني أن استخدام شبكة المضيف يغيّر ملكية المنافذ والافتراضات التي يعتمد عليها قالب من متجر التطبيقات.
لا تتعامل مع network_mode: host بوصفه حلًا شاملًا لحاويات DNS. فقد يكون مفيدًا عندما يحتاج التطبيق فعلًا إلى رؤية مستوى شبكة المضيف، لكنه قد يؤدي أيضًا إلى تعارضات في المنافذ مع لوحة معلومات ZimaOS أو محلل DNS آخر أو حاوية أخرى.
تمكن المستخدم في النهاية من تشغيل AdGuard باستخدام إصدار مختلف من التطبيق
حدّث صاحب الموضوع مشاركته لاحقًا بعد العثور على تعليمات تستخدم إصدار Network من تطبيق AdGuard بدلًا من الحزمة الافتراضية، مع إضافة تعيينات المنافذ المطلوبة لواجهة الويب. وقال إن مساعد الإعداد لم يعرض العنوان المتوقع 192.168.60.x، لكن AdGuard كان يعمل.
ويؤكد ذلك مبدأً تشخيصيًا مهمًا: لا تحتاج الحاوية إلى عرض عنوان LAN الخاص بالمضيف في معالج الإعداد حتى تتمكن من الاستجابة لطلبات DNS من عملاء LAN. المهم هو إمكانية الوصول إلى منافذ DNS والويب المنشورة من الشبكة.
كان لدى مضيف ZimaOS نفسه إعداد شبكة ثابت صالح
تحتاج حاويات DNS إلى المنافذ الصحيحة أكثر من حاجتها إلى عنوان يبدو صحيحًا في المعالج
يُعد AdGuard Home وPi-hole أكثر حساسية للشبكات من تطبيق ويب عادي، لأن العملاء يحتاجون إلى الوصول إلى DNS عبر المنفذ 53، عادةً باستخدام UDP وTCP معًا. وتستخدم واجهة الإدارة منافذ ويب منفصلة.
إذا ظهر تطبيق DNS بحالة سليمة، لكن تعذر على عملاء LAN استخدامه، فتحقق من المنافذ المنشورة فعليًا، ومن عدم وجود خدمة أخرى تستخدم المنفذ 53 بالفعل، قبل تغيير عنوان IP الثابت للمضيف.
ساعد عمل Jellyfin في استبعاد وجود عطل كامل في Docker أو التخزين
ذكر المستخدم أن Jellyfin عمل في النهاية. ولم يثبت ذلك أن شبكة AdGuard كانت صحيحة، لكنه أظهر أن ZimaOS يستطيع تشغيل تطبيقات Docker والوصول إلى تخزين الوسائط ضمن التثبيت نفسه. لذلك كان من الممكن أن يظل استكشاف الأخطاء وإصلاحها مركزًا على إعدادات الشبكة الخاصة بالتطبيق، بدلًا من اعتبار حزمة الحاويات بأكملها غير صالحة للاستخدام.
انتقل فشل Time Machine مع جهاز MacBook إلى TrueNAS
جاء التصحيح الأهم في النقاش في اليوم التالي. فقد مسح المستخدم ZimaOS وأعاد تثبيته، ثم اختبر Time Machine مجددًا. وتمكن جهاز Mac mini الأقدم الذي يعمل بنظام Monterey من إجراء النسخ الاحتياطي بنجاح، بينما ظل جهاز MacBook الأحدث يفشل.
ثم جرّب المستخدم مشاركة Time Machine على TrueNAS، وفشل جهاز MacBook هناك أيضًا. وقد نقل هذا الاختبار المتقاطع السبب المرجح من ZimaOS إلى جهاز MacBook أو إلى سلوك macOS/SMB لديه.
لماذا يُعد اختبار جهاز NAS آخر عبر المقارنة مفيدًا جدًا؟
إذا فشل العميل نفسه في الاتصال بمنصتين مستقلتين لـ NAS، بينما يعمل جهاز Mac آخر مع هدف ZimaOS، فلم تعد الأدلة تؤيد أن «Time Machine على ZimaOS معطّل» بوصفه التفسير الأبسط.
وهذه قاعدة عامة مفيدة عند استكشاف أخطاء NAS وإصلاحها: غيّر طرفًا واحدًا من الاتصال في كل مرة. فقد يكشف خادم ثانٍ أو عميل ثانٍ بسرعة ما إذا كان الفشل يتبع الخادم أو العميل أو تركيبة معينة منهما.
ينبغي تقييم ZimaOS الحالي باستخدام إعدادات التخزين والتطبيقات الحالية
يعكس موضوع المصدر حالة ZimaOS في مايو 2026. وقد استمرت المنصة في التغير منذ ذلك الحين، بما في ذلك إعدادات التطبيقات، وتحرير YAML، وإدارة التخزين، وسلوك النسخ الاحتياطي. وعند إجراء تثبيت جديد، ابدأ من نموذج الميزات والتخزين الحالي في ZimaOS بدلًا من افتراض أن كل قالب في متجر التطبيقات من عام 2026 لم يتغير.
تسلسل أفضل للاختبار بعد التثبيت الجديد
- أعد إعداد موقع التخزين وبيانات التطبيقات قبل تثبيت العديد من التطبيقات.
- تحقق من تطبيق بسيط واحد، مثل Jellyfin أو خدمة ويب أخرى.
- بالنسبة إلى تطبيقات DNS، تحقّق من المنفذ 53 بصورة منفصلة عن واجهة الويب.
- لا تنتقل إلى استخدام شبكة المضيف قبل فهم الجسر الحالي وتعيين المنافذ.
- بالنسبة إلى Time Machine، اختبر جهاز Mac آخر أو هدف SMB آخر لـ Time Machine متى أمكن.
- لا تعتبر أحد المكونات السبب الجذري المرجح إلا بعد أن يتبع الفشل ذلك المكوّن.
الأسئلة الشائعة حول استكشاف أخطاء ZimaOS وإصلاحها بعد التثبيت الجديد
هل كان AdGuard Home يعمل في النهاية لدى المستخدم المذكور في المصدر؟
نعم. قال المستخدم إن إصدار تطبيق Network، إلى جانب إعداد منافذ إضافي، نجح.
هل عرض معالج إعداد AdGuard العنوان المتوقع 192.168.60.x في أي وقت؟
لا، لكن التطبيق ظل يعمل. كان المعالج يعرض الواجهات المرئية داخل الحاوية.
هل ثبت أن ZimaOS هو سبب فشل Time Machine؟
لا. فقد فشل جهاز MacBook أيضًا مع مشاركة Time Machine على TrueNAS، بينما نجح جهاز Mac mini أقدم مع ZimaOS.
