Dieser Thread ist ein gutes Beispiel für eine Diagnose durch Ausschluss. Zunächst sah ein Windows-Kopiervorgang, der in den letzten Prozent fehlschlug, wie ein SMB- oder RAID-Schreibproblem aus. Die Community prüfte den RAID-Zustand, SMART, Kernelprotokolle, Robocopy und MTU. Der Nutzer baute das NAS sogar als neues RAID5-Array mit anderen Laufwerken neu auf – und dieselben Dateien schlugen auf demselben Windows-PC weiterhin fehl.
Der entscheidende Test kam später: Genau dieselben Dateien wurden von anderen Windows-Rechnern erfolgreich auf dieselbe ZimaOS-Freigabe kopiert. Dadurch lässt sich das Problem der ursprünglichen Ryzen-Windows-11-Clientmaschine oder ihrem Netzwerk-Stack bzw. Treiberpfad zuordnen, nicht dem ZimaOS-Speicherarray. Die genaue clientseitige Behebung wurde nie festgestellt.
Explorer und Robocopy schlugen bei etwa 99,9 Prozent fehl
Bei den betroffenen Dateien handelte es sich um TV-Aufnahmen .ts Dateien. Der Windows-Explorer schlug kurz vor dem Ende fehl, und Robocopy reproduzierte dasselbe Verhalten mit:
ERROR 665 / 0x00000299Die Verwendung eines anderen Kopierprogramms löste das ursprüngliche Problem daher nicht.
SMART- und RAID-Prüfungen zeigten keinen Laufwerksausfall
Die veröffentlichten SMART-Screenshots zeigten auf den überprüften Laufwerken null ausstehende, neu zugewiesene und nicht korrigierbare Sektoren, und das RAID meldete [UUUU].
Ein vollständig neues RAID mit anderen Laufwerken schlug auf demselben PC weiterhin fehl
Didier baute das System mit vier anderen 3-TB-Laufwerken im RAID5 neu auf. Das gleiche Übertragungsproblem blieb bestehen. Dies spricht stark gegen die ursprünglichen 1-TB-Laufwerke oder ein bestimmtes Array als Ursache.
Dieselben Dateien funktionierten von anderen Windows-PCs aus
Der ursprüngliche Verfasser testete denselben Inhalt später von anderen Geräten und berichtete, dass er sich problemlos kopieren ließ. Im März wiederholte er das Experiment von einem anderen Windows-11-Pro-PC und hatte erneut Erfolg.
Dies ist der aussagekräftigste Isolierungstest im gesamten Thread.
MTU war überall bereits auf 1500 eingestellt
Die Community schlug vor, eine Abweichung bei Jumbo-Frames auszuschließen. Der Nutzer bestätigte, dass alle Geräte auf MTU 1500 eingestellt waren. Somit ließ sich der Ausgangsfall nicht dadurch erklären, dass eine Verbindung Jumbo-Frames verwendete und eine andere nicht.
SMB1 war bereits deaktiviert
Ein weiterer Test prüfte, ob ein altes SMB-Protokoll beteiligt sein könnte. Der Nutzer berichtete, dass SMB1 bereits deaktiviert war, was für moderne Windows-/ZimaOS-Netzwerke angemessen ist.
Die Serverprotokolle waren weiterhin eine Prüfung wert, aber der Test mit mehreren PCs war aussagekräftiger
Die Community forderte unmittelbar nach dem Fehler schreibgeschützte ZimaOS-Protokolle an:
dmesg -T | tail -200
journalctl -n 200 --no-pagerDiese können Resets/Timeouts aufdecken. Sobald jedoch andere PCs dieselben Dateien erfolgreich auf dasselbe NAS kopiert hatten, war der ursprüngliche Windows-Client der wichtigste Ansatzpunkt für die Fehlersuche.
Was auf dem betroffenen Windows-PC zu prüfen ist
- NIC-Treiber und Firmware;
- erweiterte NIC-Offload-/Energieeinstellungen;
- VPN-/Filter-/Sicherheitssoftware;
- Beschädigung des Windows-Netzwerk-Stacks;
- den spezifischen Ethernet-/WLAN-Adapter und den Kabel-/Verbindungspfad;
- einen Clean Boot oder einen anderen NIC als kontrollierten Test.
Eine vollständige Windows-Neuinstallation wurde von der Community als sicherster Reset vorgeschlagen, aber der Benutzer bestätigte weder, eine solche durchgeführt zu haben, noch den genauen fehlerhaften Treiber gefunden zu haben.
Die Dateierweiterung .ts war nicht die eigentliche Ursache
Nur einige Transport-Stream-Aufnahmen schlugen auf dem ursprünglichen PC fehl, wodurch der Dateityp zunächst verdächtig erschien. Dieselben Dateien wurden jedoch von einem anderen Windows-Rechner erfolgreich kopiert. Das schließt eine ZimaOS-Richtlinie aus, die einfach .ts Dateien.
Vor einer Windows-Neuinstallation einen anderen Netzwerkadapter ausprobieren
Da die endgültigen Beweise auf einen einzelnen PC hindeuten, besteht ein risikoarmer nächster Test darin, einen anderen Ethernet-Adapter, eine andere WLAN-Schnittstelle, eine USB-Netzwerkkarte, ein anderes Kabel oder einen anderen Switch-Port zu verwenden und dabei dieselbe Windows-Installation und dieselbe Datei beizubehalten. Wenn die Übertragung erfolgreich ist, lässt sich das Problem auf den ursprünglichen NIC-/Treiberpfad eingrenzen, ohne die gesamte Workstation neu aufzusetzen.
Netzwerkfilter von Drittanbietern vorübergehend isolieren
VPN-Clients, Endpoint-Sicherheitssoftware, Traffic-Shaper, virtuelle Switches, Paketaufzeichnungstreiber und Netzwerk-Suiten des Mainboards können Filtertreiber in den Windows-Netzwerk-Stack einfügen. Ein Clean Boot oder ein kontrollierter Deaktivierungs-/Deinstallationstest kann diese Ebene identifizieren.
Deaktiviere die Endpoint-Sicherheit nicht dauerhaft, nur damit SMB funktioniert; Ziel ist die Diagnose.
Der Unterschied bei „Größe auf Datenträger“ der Quelle war mit einer unvollständigen Übertragung vereinbar
Der Benutzer bemerkte später, dass die Netzwerkkopie weniger Speicherplatz belegte als das Original. Da der betroffene PC wiederholt in der letzten Phase abbrach, ist eine kleinere/unvollständige Zieldatei zu erwarten und weist für sich genommen nicht darauf hin, dass ZimaOS die Datei komprimiert oder beschädigt hat.
Eine vollständige Windows-Neuinstallation wurde vorgeschlagen, aber nicht bewiesen
Die Community bezeichnete eine saubere Neuinstallation des Betriebssystems als sicherste Methode, ein unbekanntes Client-Netzwerkproblem zurückzusetzen. Der ursprüngliche Verfasser berichtete nicht, eine vollständige saubere Installation durchgeführt zu haben. Daher sollte sie als letzter Ausweg gelten und nicht als von der Quelle bestätigte Lösung.
FAQ zu SMB-Kopierfehlern
Hat die Quelle bewiesen, dass das ZimaOS-RAID beschädigt war?
Nein. RAID/SMART waren fehlerfrei, ein neues Array mit anderen Laufwerken verhielt sich genauso, und andere PCs kopierten dieselben Dateien erfolgreich.
Hat Robocopy das Problem gelöst?
Nein. Robocopy reproduzierte ERROR 665 bei nahezu 99,9 %.
Was konnten die endgültigen Beweise eingrenzen?
Der ursprüngliche Windows-11-Ryzen-PC oder dessen Netzwerk-/Client-Stack, während die genaue clientseitige Lösung ungeklärt blieb.
