Deze thread is een goed voorbeeld van diagnose door uitsluiting. Aanvankelijk leek een Windows-kopieeractie die in de laatste paar procent mislukte op een SMB- of RAID-schrijfprobleem te wijzen. De community controleerde de RAID-gezondheid, SMART, kernel-logboeken, Robocopy en MTU. De gebruiker bouwde de NAS zelfs opnieuw op als een nieuwe RAID5-array met andere schijven — en dezelfde bestanden mislukten nog steeds vanaf dezelfde Windows-pc.
De beslissende test kwam later: exact dezelfde bestanden werden vanaf andere Windows-machines wel succesvol naar dezelfde ZimaOS-share gekopieerd. Daarmee wordt het bronprobleem gelokaliseerd bij de oorspronkelijke Ryzen Windows 11-client of het netwerkstack-/driverpad daarvan, niet bij de ZimaOS-opslagarray. De exacte oplossing aan clientzijde is nooit vastgesteld.
Verkenner en Robocopy faalden rond 99,9%
De getroffen bestanden waren tv-opnamen .ts bestanden. Windows Verkenner faalde bijna aan het einde en Robocopy reproduceerde hetzelfde gedrag met:
ERROR 665 / 0x00000299Het gebruik van een andere kopieertool loste het oorspronkelijke probleem dus niet op.
SMART- en RAID-controles toonden geen schijfdefect
De geplaatste SMART-schermafbeeldingen toonden nul in afwachting zijnde, opnieuw toegewezen en onherstelbare sectoren op de gecontroleerde schijven, en de RAID meldde [UUUU].
Een volledig nieuwe RAID met andere schijven mislukte nog steeds vanaf dezelfde pc
Didier bouwde het systeem opnieuw op met vier verschillende schijven van 3 TB in RAID5. Hetzelfde overdrachtsprobleem bleef bestaan. Dat is sterk bewijs tegen de oorspronkelijke schijven van 1 TB of één specifieke array als oorzaak.
Dezelfde bestanden werkten vanaf andere Windows-pc's
De oorspronkelijke poster testte later dezelfde inhoud vanaf andere machines en zei dat deze normaal werd gekopieerd. In maart herhaalde hij het experiment vanaf een andere Windows 11 Pro-pc en slaagde hij opnieuw.
Dit is de meest overtuigende isolatietest in de hele thread.
Overal was MTU al 1500
De community stelde voor een mismatch in jumbo frames uit te sluiten. De gebruiker bevestigde dat alle apparaten MTU 1500 gebruikten, waardoor de oorspronkelijke situatie niet kon worden verklaard door één verbinding die jumbo frames gebruikte terwijl een andere dat niet deed.
SMB1 was al uitgeschakeld
Bij een andere test werd gecontroleerd of een oud SMB-protocol mogelijk een rol speelde. De gebruiker meldde dat SMB1 al was uitgeschakeld, wat passend is voor moderne Windows/ZimaOS-netwerken.
Serverlogboeken waren nog steeds het controleren waard, maar de test tussen pc's was overtuigender
De community vroeg om alleen-lezen ZimaOS-logboeken onmiddellijk na de fout:
dmesg -T | tail -200
journalctl -n 200 --no-pagerDaarmee kunnen resets en time-outs aan het licht komen. Maar zodra andere pc's dezelfde bestanden met succes naar dezelfde NAS hadden gekopieerd, werd de oorspronkelijke Windows-client de belangrijkste plek om problemen op te lossen.
Wat je moet controleren op de betreffende Windows-pc
- NIC-driver en firmware;
- geavanceerde offload-/energiebesparingsinstellingen van de NIC;
- VPN-/filter-/beveiligingssoftware;
- corruptie van de Windows-netwerkstack;
- de specifieke Ethernet-/wifi-adapter en kabel/het pad;
- een clean boot of een andere NIC als gecontroleerde test.
De community stelde een volledige herinstallatie van Windows voor als de meest zekere reset, maar de gebruiker uit de bron bevestigde niet dat die was uitgevoerd of dat de exacte defecte driver was gevonden.
De extensie .ts was niet de hoofdoorzaak
Alleen sommige transportstreamopnamen mislukten vanaf de oorspronkelijke pc, waardoor het bestandstype aanvankelijk verdacht leek. Maar precies dezelfde bestanden werden vanaf een andere Windows-machine wel succesvol gekopieerd. Daarmee wordt uitgesloten dat ZimaOS simpelweg .ts bestanden.
Probeer een andere netwerkadapter voordat je Windows opnieuw installeert
Omdat het uiteindelijke bewijs naar één pc wijst, is een volgende test met weinig risico het gebruik van een andere Ethernetadapter, wifi-interface, USB-NIC, kabel of switchpoort, terwijl dezelfde Windows-installatie en hetzelfde bestand behouden blijven. Als de overdracht slaagt, kan het probleem worden vernauwd tot het pad van de oorspronkelijke NIC/driver, zonder het hele werkstation opnieuw op te bouwen.
Isoleer netwerkfilters van derden tijdelijk
VPN-clients, endpointbeveiliging, verkeersbeheerders, virtuele switches, packet-capturedrivers en netwerksoftware van moederbordfabrikanten kunnen filterdrivers in de Windows-netwerkstack plaatsen. Met een clean boot of een gecontroleerde test waarbij deze laag tijdelijk wordt uitgeschakeld of verwijderd, kan dit worden vastgesteld.
Schakel endpointbeveiliging niet permanent uit alleen om SMB te laten werken; het doel is diagnose.
Het verschil in ‘Grootte op schijf’ van de bron was consistent met een onvolledige overdracht
De gebruiker merkte later dat de netwerkkopie minder ruimte innam dan het origineel. Omdat de betreffende pc herhaaldelijk tijdens de laatste fase stopte, is een kleiner/onvolledig doelbestand te verwachten. Dat wijst op zichzelf niet op compressie of beschadiging van het bestand door ZimaOS.
Een volledige herinstallatie van Windows werd voorgesteld, maar niet bewezen
De community noemde een schone herinstallatie van het besturingssysteem de meest zekere manier om een onbekend netwerkprobleem aan de clientzijde te resetten. De oorspronkelijke poster meldde niet dat er een volledige schone installatie was uitgevoerd. Daarom moet dit een laatste redmiddel blijven en niet worden beschouwd als de door de bron bevestigde oplossing.
Veelgestelde vragen over SMB-kopieerfouten
Bewees de bron dat de RAID van ZimaOS beschadigd was?
Nee. RAID/SMART waren in orde, een nieuwe array met andere schijven gedroeg zich hetzelfde en andere pc's kopieerden dezelfde bestanden zonder problemen.
Heeft Robocopy het probleem opgelost?
Nee. Robocopy reproduceerde ERROR 665 rond 99,9%.
Wat isoleerde het uiteindelijke bewijs?
De oorspronkelijke Windows 11 Ryzen-pc of de netwerk-/clientstack, terwijl de exacte oplossing aan de clientzijde onopgelost bleef.
