이 스레드는 배제에 의한 진단의 좋은 사례입니다. 처음에는 몇 퍼센트만 남기고 실패하는 Windows 복사가 SMB 또는 RAID 쓰기 문제처럼 보였습니다. 커뮤니티는 RAID 상태, SMART, 커널 로그, Robocopy, MTU를 확인했습니다. 사용자는 다른 디스크로 새로운 RAID5 어레이를 구성해 NAS를 다시 구축하기까지 했지만, 동일한 Windows PC에서는 같은 파일이 계속 실패했습니다.
결정적인 테스트는 나중에 이루어졌습니다. 다른 Windows 컴퓨터에서 동일한 파일을 동일한 ZimaOS 공유로 성공적으로 복사할 수 있었습니다. 이는 문제가 ZimaOS 스토리지 어레이가 아니라 원래 Ryzen Windows 11 클라이언트 또는 해당 네트워크 스택/드라이버 경로에 국한됨을 보여 줍니다. 정확한 클라이언트 측 해결 방법은 끝내 확인되지 않았습니다.
탐색기와 Robocopy는 99.9% 부근에서 실패했습니다
문제가 발생한 파일은 TV 녹화 파일이었습니다 .ts 파일은 TV 녹화 파일이었습니다. Windows 탐색기는 마지막 부분에서 실패했고, Robocopy에서도 다음과 같은 동일한 동작이 재현되었습니다.
ERROR 665 / 0x00000299따라서 다른 복사 도구를 사용해도 원래 문제가 해결되지 않았습니다.
SMART 및 RAID 검사에서 디스크 고장은 확인되지 않았습니다
게시된 SMART 스크린샷에서는 확인한 드라이브의 대기, 재할당, 복구 불가능 섹터가 모두 0개로 표시되었고, RAID는 다음과 같이 보고했습니다. [UUUU].
완전히 새로운 RAID와 다른 디스크를 사용해도 동일한 PC에서는 여전히 실패했습니다
Didier는 서로 다른 3TB 드라이브 네 개를 RAID5로 구성해 시스템을 다시 구축했습니다. 동일한 전송 문제가 계속 발생했습니다. 이는 원래 사용한 1TB 디스크나 특정 어레이 하나가 원인일 가능성을 강하게 낮춥니다.
동일한 파일이 다른 Windows PC에서는 정상적으로 작동했습니다
원 게시자는 나중에 다른 컴퓨터에서 동일한 콘텐츠를 테스트했고 정상적으로 복사되었다고 밝혔습니다. 3월에는 다른 Windows 11 Pro PC에서도 실험을 반복했으며 역시 성공했습니다.
이것은 전체 스레드에서 가장 강력한 격리 테스트입니다.
모든 장치의 MTU는 이미 1500이었습니다
커뮤니티는 점보 프레임 불일치 가능성을 배제해 보자고 제안했습니다. 사용자는 모든 장치의 MTU가 1500이라고 확인했으므로, 한 링크만 점보 프레임을 사용하고 다른 링크는 사용하지 않는 상황으로는 원인을 설명할 수 없었습니다.
SMB1은 이미 비활성화되어 있었습니다
또 다른 테스트에서는 오래된 SMB 프로토콜이 관련되어 있을 가능성을 확인했습니다. 사용자는 SMB1이 이미 비활성화되어 있다고 보고했으며, 이는 최신 Windows/ZimaOS 네트워크에 적절한 설정입니다.
서버 로그를 확인할 가치는 있었지만, PC 간 교차 테스트가 더 결정적이었습니다
커뮤니티는 장애 직후 읽기 전용 ZimaOS 로그를 요청했습니다.
dmesg -T | tail -200
journalctl -n 200 --no-pager이러한 로그를 통해 재설정이나 시간 초과를 확인할 수 있습니다. 그러나 다른 PC에서 동일한 파일을 동일한 NAS로 성공적으로 복사했다면, 원래 Windows 클라이언트가 문제 해결을 시작하기에 가장 중요한 지점이 됩니다.
영향받은 Windows PC에서 확인할 항목
- NIC 드라이버 및 펌웨어
- NIC 고급 오프로딩/전원 관리 설정
- VPN/필터/보안 소프트웨어
- Windows 네트워킹 스택 손상
- 특정 이더넷/Wi-Fi 어댑터와 케이블/경로
- 제어된 테스트로 클린 부팅 또는 다른 NIC를 사용해 보세요.
커뮤니티에서는 전체 Windows 재설치를 가장 확실한 초기화 방법으로 제안했지만, 출처의 사용자는 실제로 재설치를 수행했거나 정확한 문제 드라이버를 찾아냈다고 확인하지 않았습니다.
.ts 파일 확장자가 근본 원인은 아니었습니다
원래 PC에서는 일부 트랜스포트 스트림 녹화 파일만 실패했기 때문에 처음에는 파일 형식이 의심스러워 보였습니다. 그러나 다른 Windows 컴퓨터에서는 동일한 파일이 정상적으로 복사되었습니다. 따라서 단순히 파일을 거부하는 ZimaOS 정책이라는 가능성은 배제됩니다. .ts 파일.
Windows를 재설치하기 전에 다른 네트워크 어댑터를 사용해 보세요
동일한 Windows 설치 환경과 파일을 유지한 채 다른 이더넷 어댑터, Wi-Fi 인터페이스, USB NIC, 케이블 또는 스위치 포트를 사용하는 것은 위험이 낮은 다음 테스트입니다. 전송이 성공하면 전체 워크스테이션을 재구축하지 않고도 문제를 원래 NIC/드라이버 경로 쪽으로 좁힐 수 있습니다.
타사 네트워크 필터를 일시적으로 격리하세요
VPN 클라이언트, 엔드포인트 보안, 트래픽 셰이퍼, 가상 스위치, 패킷 캡처 드라이버, 마더보드 네트워크 제품군은 Windows 네트워킹 스택에 필터 드라이버를 삽입할 수 있습니다. 클린 부팅 또는 제어된 비활성화/제거 테스트를 통해 이 계층을 확인할 수 있습니다.
SMB를 작동시키기 위해 엔드포인트 보안을 영구적으로 비활성화하지 마세요. 목표는 진단입니다.
소스의 “디스크 할당 크기” 차이는 불완전한 전송과 일치했습니다
사용자는 나중에 네트워크를 통해 복사된 파일이 원본보다 더 적은 공간을 차지한다는 것을 확인했습니다. 문제가 발생한 PC에서 복사가 반복적으로 마지막 단계에서 중단되었으므로, 대상 파일의 크기가 더 작거나 불완전한 것은 예상되는 결과이며, 그 자체로 ZimaOS가 파일을 압축했거나 손상시켰다는 의미는 아닙니다.
전체 Windows 재설치는 제안되었을 뿐, 입증되지는 않았습니다
커뮤니티에서는 알려지지 않은 클라이언트 네트워킹 문제를 초기화하는 가장 확실한 방법으로 운영 체제를 완전히 새로 설치하는 방법을 제시했습니다. 원 게시자는 완전한 클린 설치를 수행했다고 보고하지 않았으므로, 이는 출처에서 확인된 해결책이 아니라 최후의 수단으로 남겨 두어야 합니다.
SMB 복사 오류 FAQ
소스에서 ZimaOS RAID가 손상되었다는 사실이 입증되었나요?
아니요. RAID/SMART 상태는 정상이었고, 다른 디스크로 새 어레이를 구성해도 동일했으며, 다른 PC에서는 같은 파일이 정상적으로 복사되었습니다.
Robocopy로 문제가 해결되었나요?
아니요. Robocopy에서도 약 99.9% 지점에서 ERROR 665가 재현되었습니다.
최종 증거는 무엇을 원인으로 좁혔나요?
원래 Windows 11 Ryzen PC 또는 해당 네트워크/클라이언트 스택이 원인이었으며, 정확한 클라이언트 측 해결책은 여전히 밝혀지지 않았습니다.
