What Causes File Checksums to Change After Copying Through an SMB Share?

SMB normally transports file bytes unchanged, so a checksum mismatch means the compared content changed, was read inconsistently, or was not the same data stream.

The mismatch may come from hashing the source before an application finishes writing, comparing a resource fork or alternate stream on one side, allowing a media or security application to rewrite the destination, reading through stale client cache, or encountering storage and transport errors. The correct test freezes the source, hashes both files with the same tool and mode, and repeats the transfer through a controlled path before blaming SMB itself.

Verify That Both Checksums Cover the Same File Data

Record the exact source path, destination path, file size, hashing command, algorithm, binary or text mode, and time each checksum was generated. Confirm that neither command read a shortcut, symlink target, temporary file, or sidecar.

The SHA-256 utility computes a digest from the bytes it reads from the specified file. The sha256sum reference supports using the same algorithm and invocation on both endpoints.

If sizes differ, diagnose an incomplete or modified copy before comparing hashes. If sizes match but hashes differ, continue with source stability, stream scope, storage reads, and destination modification.

Freeze Applications That Can Modify the Source During the Copy

Stop databases, download clients, virtual machines, media editors, synchronization tools, and any application writing to the source file. Generate a fresh source checksum only after the file is closed.

Rsync’s documentation warns that files should be moved into a watched source directory only after they are fully written, because a changing source file can be transferred inconsistently.

Compare the source checksum before and immediately after the SMB copy. If the two source hashes differ, SMB is not the first cause; the source changed during the test.

Check Oplocks, Local Writers, and Cached File State

List open SMB handles and local processes accessing the source and destination. Pay special attention when the same share is written simultaneously through SMB and directly on the NAS host.

Samba explains that opportunistic locks allow a client to cache file changes locally and synchronize them back to the server when required. Its locks and oplocks model shows why concurrent local and SMB writers must be controlled during integrity testing.

Do not disable oplocks server-wide as the first response. Close the competing applications, open a fresh session, and repeat one file copy to prove whether concurrency was involved.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Separate File Content From Extended Attributes and Alternate Streams

Decide whether the expected checksum covers only the main file data or an archive that also includes resource forks, extended attributes, alternate streams, ACLs, and metadata. Use the same scope on both sides.

ArchWiki describes extended attributes as metadata stored separately from ordinary file contents. Losing or translating that metadata can change an archive or package hash without changing the main data stream’s checksum.

For macOS files, compare the main data fork separately from any resource fork or AppleDouble sidecar. Do not interpret a metadata mismatch as proof that the primary file bytes changed.

Use a Copy Tool With Restart and Logging

Repeat the transfer with one known copy method and a new destination filename. Save its retry, restart, skip, and failure log rather than relying on a file browser progress dialog.

Microsoft defines SMB as a protocol that allows applications to read, create, and update remote files. Its SMB file-access model supports treating a changed checksum as a data-path or writer problem, not an expected protocol transformation.

If a logged command-line copy matches while drag-and-drop does not, compare the application, retry behavior, partial-file handling, antivirus scanning, and post-copy processing rather than changing the SMB server.

Compare the Destination Before Indexers or Applications Rewrite It

Hash the destination immediately after the copy while it is closed and before media scanners, document converters, photo managers, antivirus tools, or synchronization clients can alter it.

Oregon State’s Robocopy guide emphasizes logged and restartable copying, which gives a clearer boundary between the transfer finishing and later applications touching the destination.

If the immediate destination hash matches but changes later, identify the first process that opens the file for writing. The permanent fix belongs to that application’s metadata, optimization, or synchronization behavior.

Repeat the Test Across Storage and Network Boundaries

Copy the same closed test file locally on the source NAS, locally on the destination filesystem, through SMB from another client, and through the original client. Hash after every step.

The ZimaSpace guide to preserving NAS migration metadata provides the adjacent rule: content hashes and metadata fields must be validated as separate acceptance criteria.

The issue is resolved when a closed source file produces matching hashes across repeated copies and remains unchanged after post-copy services run. Stop the migration and protect the source if mismatches follow one disk, controller, client, or repeatable file offset.