결론: 이 문제는 파일 누락이 아니라 동일 서버 SMB 복사 오프로딩 패턴과 일치합니다
복사가 거의 100%까지 진행된 후 탐색기가 다시 시도하고 항목을 더 이상 찾을 수 없다고 보고합니다. 한편 ZimaOS 파일 앱에서 동일한 데이터를 이동하면 정상적으로 작동합니다. 이러한 조합은 원본 파일이 사라진 것이 아니라 동일한 서버의 두 공유 폴더 간 SMB 전송 경로에 문제가 있음을 나타냅니다.
Windows가 동일 서버 SMB 복사를 다르게 처리하는 이유
원본과 대상이 동일한 SMB 서버에 있을 때 Windows는 서버 측 복사를 요청할 수 있습니다. Microsoft는 이 메커니즘을 FSCTL_SRV_COPYCHUNK로 문서화하고 있습니다. 이 경로가 올바르게 처리되지 않으면 각 공유 폴더에 대한 일반적인 읽기/쓰기 액세스가 정상적으로 작동하더라도 탐색기에서 복사가 실패할 수 있습니다.
탐색기의 동일 서버 최적화에 의존하지 않는 전송 경로 사용
실용적인 방법은 세 가지입니다.
- ZimaOS 파일 앱에서 파일을 이동하거나 복사합니다.
- 공유 폴더 A의 파일을 PC로 복사한 다음, PC에서 공유 폴더 B로 복사합니다.
robocopy를 사용하고 대상 위치를 확인합니다.
Microsoft는 robocopy 참조 문서에서 재시도 및 복사 동작을 설명합니다.
처음부터 권한 문제라고 단정하지 마세요
두 공유 폴더에서 각각 파일을 만들고, 편집하고, 삭제할 수 있다면 기본 자격 증명이 첫 번째 문제 지점일 가능성은 낮습니다. 한 공유 폴더가 읽기 전용이거나 자격 증명이 잘못된 경우에는 최신 ZimaOS SMB 도움말 문서를 참고하는 것이 좋습니다.
확실히 말할 수 있는 것과 없는 것
커뮤니티 사례는 서버 측 복사 호환성 문제와 매우 유사하지만, 현재 공개된 ZimaOS 매뉴얼에는 공유 폴더 간 COPYCHUNK 동작이 지원된다는 보장이 문서화되어 있지 않습니다. 이 패턴을 영구적인 플랫폼 특성으로 단정하지 말고 진단을 위한 지름길로 활용하세요.
일반적인 공유 설정은 NAS 101 파일 공유 가이드와 인증된 ZimaOS SMB 예시를 참고하세요.
