يُعد هذا الموضوع مثالًا جيدًا على التشخيص بالاستبعاد. في البداية، بدا أن فشل نسخ Windows في النسب المئوية القليلة الأخيرة قد يكون مشكلة في SMB أو في كتابة RAID. فحص المجتمع سلامة RAID وSMART وسجلات النواة وRobocopy وMTU. بل أعاد المستخدم بناء جهاز NAS كمصفوفة RAID5 جديدة باستخدام أقراص مختلفة، ومع ذلك ظلت الملفات نفسها تفشل من جهاز Windows نفسه.
جاء الاختبار الحاسم لاحقًا: نُسخت الملفات نفسها بنجاح إلى مشاركة ZimaOS نفسها من أجهزة Windows أخرى. وهذا يعزل المشكلة إلى عميل Windows 11 الأصلي الذي يعمل بمعالج Ryzen أو إلى مسار مكدس الشبكة/برنامج التشغيل فيه، وليس إلى مصفوفة تخزين ZimaOS. ولم يُحدَّد الإصلاح الدقيق من جهة العميل قط.
فشل Explorer وRobocopy عند نحو 99.9%
كانت الملفات المتأثرة تسجيلات تلفزيونية .ts الملفات. فشل مستكشف Windows قرب النهاية، وأعاد Robocopy إنتاج السلوك نفسه مع:
ERROR 665 / 0x00000299لذلك لم يؤدِّ استخدام أداة نسخ مختلفة إلى حل المشكلة الأصلية.
لم تُظهر فحوصات SMART وRAID تعطل أي قرص
أظهرت لقطات SMART المنشورة صفرًا من القطاعات المعلّقة والمعاد تخصيصها وغير القابلة للتصحيح على الأقراص التي جرى فحصها، كما أفاد RAID بأن [UUUU].
ظل نظام RAID جديد بالكامل بأقراص مختلفة يفشل من جهاز الكمبيوتر نفسه
أعاد Didier بناء النظام باستخدام أربعة أقراص مختلفة بسعة 3 تيرابايت في RAID5. واستمرت مشكلة النقل نفسها. وهذا دليل قوي ضد كون أقراص 1 تيرابايت الأصلية أو مصفوفة محددة هي السبب.
عملت الملفات نفسها من أجهزة كمبيوتر أخرى تعمل بنظام Windows
اختبر صاحب المنشور الأصلي المحتوى نفسه لاحقًا من أجهزة أخرى، وقال إنه نُسخ بصورة طبيعية. وفي مارس، كرر التجربة من جهاز كمبيوتر آخر يعمل بنظام Windows 11 Pro ونجح مرة أخرى.
هذا هو أقوى اختبار للعزل في الموضوع بأكمله.
كان MTU مضبوطًا على 1500 في كل مكان
اقترح المجتمع استبعاد عدم تطابق الإطارات العملاقة. أكد المستخدم أن جميع الأجهزة كانت مضبوطة على MTU 1500، لذا لم تكن الحالة الأصلية ناجمة عن استخدام وصلة واحدة لإطارات عملاقة دون الأخرى.
كان SMB1 معطلًا بالفعل
تحقق اختبار آخر مما إذا كان بروتوكول SMB قديمًا قد يكون متورطًا. أفاد المستخدم بأن SMB1 كان معطلًا بالفعل، وهو الإعداد المناسب لشبكات Windows/ZimaOS الحديثة.
كان لا يزال من المفيد التحقق من سجلات الخادم، لكن اختبار أجهزة الكمبيوتر المتعددة كان أقوى
طلب المجتمع سجلات ZimaOS للقراءة فقط فور حدوث العطل:
dmesg -T | tail -200
journalctl -n 200 --no-pagerقد تكشف هذه الأمور عمليات إعادة ضبط أو انقضاء مهلات. لكن بعد نجاح حواسيب أخرى في نسخ الملفات نفسها إلى وحدة NAS نفسها، أصبح عميل Windows الأصلي المكان الأعلى أولوية لاستكشاف الأخطاء وإصلاحها.
ما ينبغي فحصه على حاسوب Windows المتأثر
- برنامج تشغيل NIC والبرامج الثابتة؛
- إعدادات إلغاء التحميل المتقدمة/الطاقة في NIC؛
- برامج VPN/الترشيح/الحماية؛
- تلف مكدس الشبكات في Windows؛
- محول Ethernet/Wi‑Fi والكابل/المسار المحدد؛
- إقلاع نظيف أو محول NIC مختلف كاختبار مضبوط.
اقتَرَح المجتمع إعادة تثبيت Windows بالكامل باعتبارها إعادة الضبط الأكثر تأكيدًا، لكن مستخدم المصدر لم يؤكد إجراء ذلك أو العثور على برنامج التشغيل المتسبب في العطل تحديدًا.
لم يكن امتداد الملف .ts هو السبب الجذري
فشلت بعض تسجيلات دفق النقل فقط من الحاسوب الأصلي، ما جعل نوع الملف يبدو مريبًا في البداية. لكن الملفات نفسها تمامًا نُسخت بنجاح من حاسوب Windows آخر. وهذا يستبعد سياسة في ZimaOS ترفض ببساطة .ts الملفات.
جرّب محول شبكة مختلفًا قبل إعادة تثبيت Windows
بما أن الأدلة النهائية تشير إلى حاسوب واحد، فإن الاختبار التالي منخفض المخاطر هو استخدام محول Ethernet آخر أو واجهة Wi‑Fi أخرى أو بطاقة شبكة USB أو كابل أو منفذ مبدّل آخر، مع الإبقاء على تثبيت Windows والملف نفسيهما. فإذا نجح النقل، يمكن تضييق نطاق المشكلة نحو مسار بطاقة الشبكة/برنامج التشغيل الأصلي، من دون إعادة بناء محطة العمل بأكملها.
اعزل مؤقتًا مرشحات الشبكة التابعة لجهات خارجية
يمكن لعملاء VPN وبرامج حماية نقاط النهاية ومُنظِّمات حركة المرور والمبدلات الافتراضية وبرامج تشغيل التقاط الحزم وحزم الشبكة الخاصة باللوحة الأم إدراج برامج تشغيل ترشيح ضمن مكدس الشبكات في Windows. ويمكن لبدء تشغيل نظيف أو اختبار تعطيل/إلغاء تثبيت مضبوط تحديد هذه الطبقة.
لا تعطّل حماية نقاط النهاية نهائيًا لمجرد تشغيل SMB؛ فالهدف هو التشخيص.
كان اختلاف «الحجم على القرص» في المصدر متسقًا مع نقل غير مكتمل
لاحظ المستخدم لاحقًا أن النسخة المنقولة عبر الشبكة تشغل مساحة أقل من الأصل. وبما أن الحاسوب المتعطل كان يتوقف مرارًا في المرحلة الأخيرة، فمن المتوقع وجود ملف وجهة أصغر/غير مكتمل، ولا يشير ذلك بحد ذاته إلى أن ZimaOS ضغط الملف أو أتلفه.
اقتُرحت إعادة تثبيت Windows بالكامل، لكن لم يُثبت أنها الحل
اعتبر المجتمع أن إعادة تثبيت نظام التشغيل تثبيتًا نظيفًا هي الطريقة الأكثر تأكيدًا لإعادة ضبط مشكلة غير معروفة في شبكة العميل. ولم يُفِد صاحب المنشور الأصلي بأنه أجرى تثبيتًا نظيفًا كاملًا، لذا ينبغي أن يظل ذلك خيار الملاذ الأخير، لا الحل الذي يؤكده المصدر.
الأسئلة الشائعة حول أخطاء نسخ SMB
هل أثبت المصدر أن RAID في ZimaOS تالفة؟
لا. كانت RAID/SMART سليمة، وتصرفت مصفوفة جديدة بأقراص مختلفة بالطريقة نفسها، بينما نجحت حواسيب أخرى في نسخ الملفات نفسها.
هل حلّ Robocopy المشكلة؟
لا. أعاد Robocopy إنتاج الخطأ ERROR 665 عند نحو 99.9٪.
ما الذي عزلته الأدلة النهائية؟
حاسوب Windows 11 Ryzen الأصلي أو حزمة الشبكة/العميل فيه، بينما ظل الإصلاح الدقيق من جانب العميل غير محسوم.
