SMB는 일반적으로 파일의 바이트를 변경하지 않고 전송하므로 체크섬 불일치는 비교한 콘텐츠가 변경되었거나, 일관되지 않게 읽혔거나, 동일한 데이터 스트림이 아니었음을 의미합니다.
불일치는 애플리케이션이 쓰기를 완료하기 전에 소스 파일을 해시했거나, 한쪽에서 리소스 포크 또는 대체 스트림을 비교했거나, 미디어 또는 보안 애플리케이션이 대상 파일을 다시 작성했거나, 오래된 클라이언트 캐시를 통해 읽었거나, 스토리지 및 전송 오류가 발생했기 때문에 생길 수 있습니다. 올바른 테스트는 소스를 고정하고, 동일한 도구와 모드로 두 파일을 해시한 다음, SMB 자체를 원인으로 지목하기 전에 통제된 경로를 통해 전송을 반복하는 것입니다.
두 체크섬이 동일한 파일 데이터를 대상으로 하는지 확인
정확한 소스 경로, 대상 경로, 파일 크기, 해시 명령, 알고리즘, 바이너리 또는 텍스트 모드, 각 체크섬이 생성된 시간을 기록합니다. 어느 명령도 바로 가기, 심볼릭 링크 대상, 임시 파일 또는 사이드카 파일을 읽지 않았는지 확인합니다.
SHA-256 유틸리티는 지정한 파일에서 읽은 바이트를 기반으로 다이제스트를 계산합니다. sha256sum 참조 문서를 사용하면 양쪽 엔드포인트에서 동일한 알고리즘과 호출 방식을 적용할 수 있습니다.
크기가 다르면 해시를 비교하기 전에 복사가 완료되지 않았거나 수정된 원인을 진단합니다. 크기는 같지만 해시가 다르면 소스의 안정성, 스트림 범위, 스토리지 읽기, 대상 파일 수정 여부를 계속 확인합니다.
복사 중 소스를 수정할 수 있는 애플리케이션 중지
소스 파일에 쓰는 데이터베이스, 다운로드 클라이언트, 가상 머신, 미디어 편집기, 동기화 도구 및 기타 애플리케이션을 중지합니다. 파일이 닫힌 후에만 새 소스 체크섬을 생성합니다.
Rsync 문서에서는 파일이 완전히 기록된 후 감시 중인 소스 디렉터리로 이동해야 한다고 경고합니다. 변경 중인 소스 파일은 일관되지 않게 전송될 수 있기 때문입니다.
SMB 복사 전과 복사 직후에 소스 체크섬을 비교합니다. 두 소스 해시가 다르면 첫 번째 원인은 SMB가 아닙니다. 테스트 중 소스가 변경된 것입니다.
Oplock, 로컬 기록 작업 및 캐시된 파일 상태 확인
소스와 대상에 접근하는 SMB 열린 핸들과 로컬 프로세스를 나열합니다. 동일한 공유 폴더에 SMB와 NAS 호스트에서 직접 동시에 쓰는 경우를 특히 주의합니다.
Samba는 기회적 잠금(opportunistic lock)을 통해 클라이언트가 파일 변경 사항을 로컬에 캐시하고 필요할 때 서버와 동기화할 수 있다고 설명합니다. 잠금 및 oplock 모델은 무결성 테스트 중 로컬 기록 작업과 SMB 기록 작업을 통제해야 하는 이유를 보여줍니다.
처음부터 서버 전체에서 oplock을 비활성화하지 마십시오. 충돌하는 애플리케이션을 닫고 새 세션을 연 다음 파일 하나를 다시 복사하여 동시 작업이 관련되었는지 확인합니다.
파일 콘텐츠와 확장 속성 및 대체 스트림을 구분
예상 체크섬이 주 파일 데이터만 포함하는지, 아니면 리소스 포크, 확장 속성, 대체 스트림, ACL 및 메타데이터까지 포함하는 아카이브를 대상으로 하는지 결정합니다. 양쪽에서 동일한 범위를 사용합니다.
ArchWiki는 확장 속성을 일반 파일 콘텐츠와 별도로 저장되는 메타데이터라고 설명합니다. 이러한 메타데이터가 손실되거나 변환되면 주 데이터 스트림의 체크섬은 변하지 않아도 아카이브 또는 패키지 해시가 달라질 수 있습니다.
macOS 파일의 경우 주 데이터 포크를 리소스 포크 또는 AppleDouble 사이드카와 별도로 비교합니다. 메타데이터 불일치를 주 파일 바이트가 변경되었다는 증거로 해석하지 마십시오.
재시작 및 로깅을 지원하는 복사 도구 사용
하나의 확인된 복사 방식으로 새 대상 파일 이름을 사용해 전송을 반복합니다. 파일 브라우저의 진행률 대화 상자에 의존하지 말고 재시도, 재시작, 건너뛰기 및 실패 로그를 저장합니다.
Microsoft는 SMB를 애플리케이션이 원격 파일을 읽고, 만들고, 업데이트할 수 있게 하는 프로토콜로 정의합니다. SMB 파일 액세스 모델에 따르면 변경된 체크섬은 예상되는 프로토콜 변환이 아니라 데이터 경로 또는 기록 작업의 문제로 볼 수 있습니다.
로그가 기록되는 명령줄 복사에서는 일치하지만 끌어다 놓기에서는 일치하지 않는다면 SMB 서버를 변경하기보다 애플리케이션, 재시도 동작, 부분 파일 처리, 바이러스 백신 검사 및 복사 후 처리 과정을 비교합니다.
인덱서 또는 애플리케이션이 다시 작성하기 전에 대상 비교
복사 직후 파일이 닫힌 상태에서 해시를 계산하고, 미디어 스캐너, 문서 변환기, 사진 관리자, 바이러스 백신 도구 또는 동기화 클라이언트가 파일을 변경하기 전에 확인합니다.
Oregon State의 Robocopy 가이드는 로깅 및 재시작 가능한 복사를 강조합니다. 이를 통해 전송 완료 시점과 이후 애플리케이션이 대상 파일에 접근한 시점을 명확히 구분할 수 있습니다.
복사 직후에는 대상 해시가 일치하지만 나중에 변경된다면 파일을 쓰기 위해 처음 연 프로세스를 확인합니다. 영구적인 해결책은 해당 애플리케이션의 메타데이터, 최적화 또는 동기화 동작을 수정하는 데 있습니다.
스토리지 및 네트워크 경계를 넘나들며 테스트 반복
동일한 닫힌 테스트 파일을 소스 NAS에서 로컬로, 대상 파일 시스템에서 로컬로, 다른 클라이언트에서 SMB를 통해, 그리고 원래 클라이언트에서 각각 복사합니다. 각 단계 후에 해시를 계산합니다.
ZimaSpace의 NAS 마이그레이션 메타데이터 보존 가이드는 관련 원칙을 제시합니다. 콘텐츠 해시와 메타데이터 필드는 별도의 승인 기준으로 검증해야 합니다.
닫힌 소스 파일의 반복 복사에서 해시가 일치하고 복사 후 서비스가 실행된 뒤에도 변경되지 않으면 문제가 해결된 것입니다. 불일치가 특정 디스크, 컨트롤러, 클라이언트 또는 반복 가능한 파일 오프셋을 따라 발생한다면 마이그레이션을 중지하고 소스를 보호합니다.
지원 및 팁
더 읽어보기

Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

