تحقّق من أن المشاركات الوهمية تأتي من الخادم
ظلّ مالك ZimaCube قادرًا على رؤية مشاركات SMB الفارغة وتركيبها، والتي نتجت عن محاولتين فاشلتين لإعداد RAID5. كان بالإمكان إضافة المشاركات الحالية في ZimaOS 1.2.2 وإزالتها بشكل طبيعي، لكن الأسماء الأقدم بقيت في أداة اختيار مشاركات الشبكة.
عرض جهاز Mac لم يتصل بـ ZimaCube من قبل الأسماء القديمة نفسها. وقد استبعد ذلك أن تكون المشكلة مقتصرة على ذاكرة التخزين المؤقت في جهاز واحد، وأكد أن الحالة القديمة موجودة على جانب الخادم.
كرّر هذا الفحص منخفض المخاطر قبل تغيير الخادم: قارن القائمة من جهاز جديد أو ملف تعريف نظيف بقائمة المشاركات النشطة الظاهرة في ملفات ZimaOS. سجّل أي الإدخالات حقيقية وأيها يُركَّب كمشاركات فارغة.
لا تُعِد بناء RAID العامل لإزالة أسماء المشاركات
أوضح الفريق أن مبدأ الإصلاح لديه هو تجنّب إجبار المستخدمين على إعادة بناء بيانات RAID أو إعادة تحميلها ما لم يكن ذلك ضروريًا. وأكد لاحقًا أن مشكلة المشاركات لن تؤثر في بيانات RAID الحالية.
وهذا يفصل بين سلامة التخزين وتنظيف قائمة المشاركات. تحقّق أولًا من المصفوفة الحالية والمشاركات الحقيقية. إذا كانت مصفوفة RAID سليمة وظلت البيانات قابلة للوصول، فالأسماء الوهمية لا تعني أن المصفوفة تحتاج إلى إعادة إنشائها.
إذا كانت المصفوفة نفسها متدهورة أو مفقودة، فتوقّف وتعامل مع ذلك كحادث استرداد منفصل. لا تدمج إصلاح التخزين مع تنظيف SMB، لأن ذلك يلغي القدرة على تحديد التغيير الذي أثّر في كل مشكلة.
أكد الفريق وجود خلل في إدارة المشاركات
أكد أحد أعضاء فريق ZimaOS أن عمليات الملفات والتخزين لم تكن مرتبطة آنذاك بتنظيف المشاركات. وأبلغ مستخدم آخر عن عرض مرتبط بالمشكلة: إذ أدى تغيير اسم مجلد مشترك أو حذفه إلى بقاء اسم SMB القديم نشطًا.
بدأت المشكلة الأصلية بعد أن أخفق ZimaOS 1.2 في الحفاظ على إعداد RAID عبر دورات انقطاع الطاقة. وأوقف التحديث إلى الإصدارين 1.2.1 و1.2.2 مشكلة عدم استمرارية إعداد RAID، لكن سجلات المشاركات القديمة بقيت.
لم يُزل ZimaOS 1.2.3 هذه السجلات. وقال الفريق إن الإصلاح كان مخططًا له في الإصدار 1.2.4، وعرض تقديم المساعدة عن بُعد قبل ذلك، لكن الموضوع لا يتضمن منشورًا لاحقًا يؤكد أن الإصدار 1.2.4 أزال إدخالات الكاتب. حافظ على هذا الحد الفاصل بين الإصدارات.
تجنّب التعديل اليدوي لملفات Samba المُنشأة تلقائيًا
عثر الكاتب على تعريفات قديمة في /etc/samba/smb.casa.conf. ولم يستمر تعديل الملف أو حذفه أو استبداله بعد إعادة التشغيل، كما أن قائمة الشبكة كانت تحتوي أحيانًا على أسماء أكثر مما يحتويه الملف نفسه.
يشير هذا السلوك إلى أن مكوّنًا آخر كان يعيد إنشاء حالة المشاركات أو يوفّرها. وقد تؤدي التعديلات اليدوية المتكررة إلى اختلاف الحالة عن إدارة ZimaOS من دون تحقيق إصلاح دائم.
استعد أي تغييرات تجريبية، واترك RAID النشط دون تغيير، واستخدم واجهة المستخدم المدعومة أو مسار التحديث أو عملية الدعم عن بُعد. يجب التحقق من الاسترداد من جهاز جديد بعد إعادة التشغيل، وليس بمجرد فحص ملف إعداد واحد.
صعّد المشكلة مع جرد قابل لإعادة الإنتاج للمشاركات
إذا لم يُزل تحديث مدعوم الإدخالات الوهمية، فسجّل إصدار ZimaOS، وقائمة المشاركات في الملفات، وأداة اختيار المشاركات لدى العميل، والأسماء التي تُركَّب كمشاركات فارغة. واذكر أن القائمة نفسها تظهر على جهاز جديد.
اطلب معالجة حالة المشاركات من دون الموافقة على إعادة بناء RAID، ما لم تتطلب الأدلة المتعلقة بالتخزين ذلك بشكل مستقل. وقد عرض الفريق المساعدة عن بُعد تحديدًا لإزالة المشاركات الوهمية قبل التحديث المخطط له.
بعد المعالجة، أعد التشغيل مرة واحدة، ثم أعد الاتصال من جهاز حالي وجهاز جديد، وتحقّق من ظهور المشاركات النشطة فقط وفتحها للمسارات المتوقعة. يثبت هذا الاختبار الكامل نجاح الاسترداد.
الأسئلة الشائعة
هل مشاركات SMB الوهمية مجرد مشكلة في ذاكرة التخزين المؤقت لنظام macOS؟
ليس في هذه الحالة. فقد رأى جهاز Mac لم يسبق له الاتصال بـ ZimaCube الإدخالات نفسها.
هل أزال ZimaOS 1.2.3 المشاركات القديمة؟
لا. أبلغ الكاتب صراحةً بأن الإصدار 1.2.3 لم يُصلحها.
هل أكد الموضوع أن ZimaOS 1.2.4 أصلح الخلل؟
خطط الفريق لإصلاح الخلل في الإصدار 1.2.4، لكن الموضوع لا يتضمن تحققًا نهائيًا من المستخدم.
