Ten wątek jest dobrym przykładem diagnozowania przez eliminację. Początkowo kopiowanie w systemie Windows, które kończyło się niepowodzeniem w ostatnich kilku procentach, wyglądało na problem z zapisem SMB lub RAID. Społeczność sprawdziła stan macierzy RAID, SMART, logi jądra, Robocopy i MTU. Użytkownik przebudował nawet serwer NAS jako nową macierz RAID5, używając innych dysków — a te same pliki nadal nie kopiowały się z tego samego komputera z systemem Windows.
Rozstrzygający test pojawił się później: dokładnie te same pliki zostały pomyślnie skopiowane do tego samego udziału ZimaOS z innych komputerów z systemem Windows. To ogranicza problem po stronie źródła do pierwotnego klienta Ryzen z Windows 11 lub ścieżki sieciowej/sterownika, a nie do macierzy pamięci masowej ZimaOS. Dokładna naprawa po stronie klienta nigdy nie została ustalona.
Eksplorator i Robocopy kończyły pracę przy około 99,9%
Dotyczyło to plików z nagraniami telewizyjnymi .ts plików. Eksplorator Windows kończył pracę pod koniec kopiowania, a Robocopy odtworzyło to samo zachowanie:
ERROR 665 / 0x00000299Użycie innego narzędzia do kopiowania nie rozwiązało więc problemu po stronie źródła.
Kontrole SMART i RAID nie wykazały awarii dysku
Opublikowane zrzuty ekranu SMART pokazywały zero sektorów oczekujących na realokację, realokowanych i nienaprawialnych na sprawdzonych dyskach, a macierz RAID zgłaszała [UUUU].
Całkowicie nowa macierz RAID z innymi dyskami nadal nie działała z tego samego komputera
Didier przebudował system, używając czterech różnych dysków 3 TB w macierzy RAID5. Ten sam problem z transferem nadal występował. To silny dowód przeciwko temu, że przyczyną były pierwotne dyski 1 TB lub konkretna macierz.
Te same pliki działały poprawnie na innych komputerach z systemem Windows
Oryginalny autor wątku później przetestował te same dane na innych komputerach i poinformował, że kopiowanie przebiegło normalnie. W marcu powtórzył eksperyment na innym komputerze z Windows 11 Pro i ponownie zakończył go powodzeniem.
To najsilniejszy test izolacyjny w całym wątku.
MTU wszędzie wynosiło już 1500
Społeczność zasugerowała wykluczenie niezgodności ramek jumbo. Użytkownik potwierdził, że wszystkie urządzenia miały MTU 1500, więc problemu nie wyjaśniało użycie ramek jumbo przez jedno łącze, gdy inne ich nie używało.
SMB1 było już wyłączone
Kolejny test sprawdzał, czy przyczyną może być stary protokół SMB. Użytkownik poinformował, że SMB1 było już wyłączone, co jest właściwe w nowoczesnych sieciach Windows/ZimaOS.
Logi serwera nadal warto było sprawdzić, ale test na różnych komputerach był bardziej miarodajny
Społeczność poprosiła o logi ZimaOS tylko do odczytu, dostępne natychmiast po awarii:
dmesg -T | tail -200
journalctl -n 200 --no-pagerMogą one ujawnić resety lub przekroczenia limitu czasu. Jednak gdy inne komputery pomyślnie skopiowały te same pliki na ten sam serwer NAS, pierwotny klient z systemem Windows stał się najważniejszym miejscem dalszej diagnostyki.
Co należy sprawdzić na komputerze z systemem Windows, którego dotyczy problem
- sterownik i oprogramowanie układowe karty sieciowej;
- zaawansowane ustawienia offloadingu i oszczędzania energii karty sieciowej;
- oprogramowanie VPN/filtrujące/zabezpieczające;
- uszkodzenie stosu sieciowego systemu Windows;
- konkretna karta Ethernet/Wi-Fi oraz kabel/ścieżka;
- czysty rozruch lub inną kartę sieciową jako kontrolowany test.
Społeczność zasugerowała pełną ponowną instalację systemu Windows jako najpewniejszy sposób na zresetowanie systemu, ale użytkownik będący źródłem nie potwierdził jej przeprowadzenia ani znalezienia dokładnego wadliwego sterownika.
Rozszerzenie pliku .ts nie było przyczyną problemu
Tylko niektóre nagrania w formacie transport stream nie powiodły się na pierwotnym komputerze, przez co początkowo typ pliku wydawał się podejrzany. Jednak dokładnie te same pliki zostały pomyślnie skopiowane z innego komputera z systemem Windows. Wyklucza to politykę ZimaOS, która po prostu odrzuca .ts plików.
Wypróbuj inną kartę sieciową przed ponowną instalacją systemu Windows
Ponieważ ostateczne dowody wskazują na jeden komputer, niskiego ryzyka kolejnym testem jest użycie innej karty Ethernet, interfejsu Wi-Fi, karty sieciowej USB, kabla lub portu przełącznika przy zachowaniu tej samej instalacji systemu Windows i tego samego pliku. Jeśli transfer się powiedzie, problem można zawęzić do oryginalnej karty sieciowej lub ścieżki sterownika bez przebudowy całej stacji roboczej.
Tymczasowo odizoluj filtry sieciowe innych firm
Klienci VPN, zabezpieczenia punktu końcowego, regulatory ruchu, przełączniki wirtualne, sterowniki przechwytywania pakietów i pakiety sieciowe płyt głównych mogą wstawiać sterowniki filtrujące do stosu sieciowego systemu Windows. Czysty rozruch lub kontrolowany test wyłączenia/odinstalowania może pomóc zidentyfikować tę warstwę.
Nie wyłączaj trwale zabezpieczeń punktu końcowego tylko po to, by uruchomić SMB; celem jest diagnostyka.
Różnica w wartości „Rozmiar na dysku” źródła była zgodna z niepełnym transferem
Użytkownik później zauważył, że kopia sieciowa zajmowała mniej miejsca niż oryginał. Ponieważ wadliwy komputer wielokrotnie zatrzymywał się na końcowym etapie, mniejszy/niepełny plik docelowy jest spodziewany i sam w sobie nie oznacza, że ZimaOS skompresował lub uszkodził plik.
Zasugerowano pełną ponowną instalację systemu Windows, ale jej nie potwierdzono
Społeczność uznała czystą ponowną instalację systemu operacyjnego za najpewniejszy sposób zresetowania nieznanego problemu z siecią klienta. Autor pierwotnego wpisu nie poinformował o przeprowadzeniu pełnej czystej instalacji, dlatego powinna ona pozostać rozwiązaniem ostatecznym, a nie rozwiązaniem potwierdzonym przez źródło.
FAQ dotyczące błędów kopiowania SMB
Czy źródło dowiodło, że RAID w ZimaOS był uszkodzony?
Nie. RAID/SMART działały prawidłowo, nowa macierz z innymi dyskami zachowywała się tak samo, a inne komputery pomyślnie kopiowały te same pliki.
Czy Robocopy rozwiązał problem?
Nie. Robocopy odtworzył błąd ERROR 665 przy około 99,9%.
Co wyodrębniły ostateczne dowody?
Oryginalny komputer z systemem Windows 11 i procesorem Ryzen lub jego stos sieciowy/kliencki, podczas gdy dokładna poprawka po stronie klienta pozostała nierozwiązana.
