Den här tråden är ett bra exempel på diagnos genom uteslutning. Till en början såg en Windows-kopiering som misslyckades under de sista procenten ut som ett SMB- eller RAID-skrivproblem. Gemenskapen kontrollerade RAID-hälsa, SMART, kärnloggar, Robocopy och MTU. Användaren byggde till och med om NAS-enheten som en ny RAID5-array med andra diskar – och samma filer misslyckades fortfarande från samma Windows-dator.
Det avgörande testet kom senare: exakt samma filer kopierades framgångsrikt till samma ZimaOS-delning från andra Windows-datorer. Det isolerar problemet till den ursprungliga Ryzen-baserade Windows 11-klienten eller dess nätverksstack/drivrutinsväg, inte till ZimaOS-lagringsarrayen. Den exakta klientreparationen fastställdes aldrig.
Explorer och Robocopy misslyckades nära 99,9 %
De berörda filerna var TV-inspelningar .ts filer. Windows Explorer misslyckades nära slutet, och Robocopy återskapade samma beteende med:
ERROR 665 / 0x00000299Att använda ett annat kopieringsverktyg löste därför inte det ursprungliga problemet.
SMART- och RAID-kontroller visade inget diskfel
De publicerade SMART-skärmbilderna visade noll väntande, omallokerade och okorrigerbara sektorer på de kontrollerade diskarna, och RAID-en rapporterade [UUUU].
En helt ny RAID med andra diskar misslyckades fortfarande från samma dator
Didier byggde om systemet med fyra olika 3 TB-enheter i RAID5. Samma överföringsproblem kvarstod. Det är starka bevis mot att de ursprungliga 1 TB-diskarna eller en specifik array var orsaken.
Samma filer fungerade från andra Windows-datorer
Den ursprungliga skribenten testade senare samma innehåll från andra datorer och uppgav att det kopierades normalt. I mars upprepade de experimentet från en annan Windows 11 Pro-dator och lyckades igen.
Detta är det starkaste isoleringstestet i hela tråden.
MTU var redan 1500 överallt
Gemenskapen föreslog att man skulle utesluta en felaktig konfiguration av jumbo frames. Användaren bekräftade att alla enheter hade MTU 1500, så problemet i ursprungsfallet förklarades inte av att en länk använde jumbo frames medan en annan inte gjorde det.
SMB1 var redan inaktiverat
Ett annat test undersökte om ett gammalt SMB-protokoll kunde vara inblandat. Användaren uppgav att SMB1 redan var inaktiverat, vilket är lämpligt för moderna Windows-/ZimaOS-nätverk.
Serverloggarna var fortfarande värda att kontrollera, men testet över flera datorer var starkare
Gemenskapen bad om skrivskyddade ZimaOS-loggar direkt efter felet:
dmesg -T | tail -200
journalctl -n 200 --no-pagerDe kan avslöja återställningar eller tidsgränsöverskridanden. Men när andra datorer lyckades kopiera samma filer till samma NAS blev den ursprungliga Windows-klienten den mest värdefulla platsen att felsöka.
Vad du bör kontrollera på den berörda Windows-datorn
- drivrutin och inbyggd programvara för nätverksadaptern;
- avancerade inställningar för nätverksadapterns avlastning och energisparfunktioner;
- VPN-, filter- och säkerhetsprogram;
- korruption i Windows nätverksstack;
- den specifika Ethernet-/Wi-Fi-adaptern och kabeln eller nätverkssökvägen;
- en ren uppstart eller en annan nätverksadapter som ett kontrollerat test.
En fullständig ominstallation av Windows föreslogs av communityn som den säkraste återställningen, men användaren bekräftade inte att någon sådan hade genomförts eller att den exakta felande drivrutinen hade hittats.
Filtillägget .ts var inte grundorsaken
Det var bara vissa transportströmsinspelningar som misslyckades från den ursprungliga datorn, vilket först fick filtypen att verka misstänkt. Men exakt samma filer kopierades utan problem från en annan Windows-dator. Det utesluter en ZimaOS-policy som helt enkelt avvisar .ts filer.
Prova en annan nätverksadapter innan du installerar om Windows
Eftersom de slutliga bevisen pekar på en enda dator är ett lågrisktest att använda en annan Ethernet-adapter, Wi-Fi-enhet, USB-nätverksadapter, kabel eller switchport, samtidigt som samma Windows-installation och fil behålls. Om överföringen lyckas kan problemet avgränsas mot den ursprungliga nätverksadapterns eller drivrutinens sökväg utan att hela arbetsstationen behöver byggas om.
Isolera nätverksfilter från tredje part tillfälligt
VPN-klienter, endpoint-säkerhet, trafikformare, virtuella switchar, paketfångstdrivrutiner och moderkortets nätverkssviter kan lägga in filterdrivrutiner i Windows nätverksstack. En ren uppstart eller ett kontrollerat test med tillfällig inaktivering eller avinstallation kan identifiera detta lager.
Inaktivera inte endpoint-säkerheten permanent bara för att få SMB att fungera; målet är felsökning.
Skillnaden i ”Storlek på disk” för källan stämde överens med en ofullständig överföring
Användaren lade senare märke till att nätverkskopian tog mindre plats än originalet. Eftersom den felande datorn upprepade gånger stannade i det sista steget är en mindre eller ofullständig målfil förväntad och innebär inte i sig att ZimaOS komprimerade eller skadade filen.
En fullständig ominstallation av Windows föreslogs, men bevisades inte
Communityn ansåg att en ren ominstallation av operativsystemet var det säkraste sättet att återställa ett okänt nätverksproblem på klienten. Den ursprungliga skribenten rapporterade inte att en fullständig ren installation hade genomförts, så detta bör förbli ett sista alternativ snarare än den lösning som bekräftats av källan.
Vanliga frågor om SMB-kopieringsfel
Visade källan att ZimaOS-RAID var korrupt?
Nej. RAID/SMART var felfria, en ny array med andra diskar betedde sig likadant och andra datorer kopierade samma filer utan problem.
Löste Robocopy problemet?
Nej. Robocopy återskapade ERROR 665 nära 99,9 %.
Vad isolerade de slutliga bevisen?
Den ursprungliga Windows 11 Ryzen-datorn eller dess klient- och nätverksstack, medan den exakta lösningen på klientsidan fortfarande var olöst.
