Ollama: “digest mismatch, file must be downloaded again”

#ai #debugging #llm #machinelearning

The progress bar reaches “verifying sha256 digest” and then fails. This is the download working correctly: something arrived that is not what was asked for, and Ollama is refusing to install it.

The string

pulling manifest
pulling 8934d96d3f08... 100%  4.7 GB
verifying sha256 digest
Error: digest mismatch, file must be downloaded again: want sha256:8de95da68dc485c0889c205384c24642f83ca18d089559c977ffc6a3972a71a8, got sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Two digests: what the manifest said the blob should hash to, and what the bytes on disk actually hash to. Both are worth reading rather than skipping past — the second one in particular can identify the failure on its own.

What a digest mismatch proves

Ollama stores models as content-addressed blobs. The manifest lists a SHA-256 for each layer, the file is written under that name, and after the transfer completes Ollama hashes what it has and compares. A mismatch is not a heuristic and not a warning — it is proof that the bytes differ from the bytes the publisher signed off on.

What it proves is narrow, though, and the narrowness is useful:

It proves the local file is wrong. It does not tell you whether the network mangled it, the disk dropped it, or the file was never fully written.
It does not mean the model is broken upstream. A registry serving a genuinely bad blob would fail for everyone identically; the far more common case is a local transfer that went wrong once.
It is not a retry-worthy transient. Running ollama pull again without removing the bad blob frequently reproduces the same failure, because the resume logic finds a file of the expected size already sitting there. This is the single reason people report the error as unfixable.

The digest that means an empty file

One value is worth memorising, because it turns a mystery into a one-line answer:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

That is the SHA-256 of zero bytes. You can confirm it in a shell in a second:

printf '' | sha256sum

When the got side of the error is that value, no data reached disk at all despite whatever the progress bar showed. That points at a write that never happened rather than at bytes that were altered in flight: a full disk, a read-only or full volume behind the blob directory, a permissions problem on the store, an antivirus or endpoint agent that quarantined the file after it was written, or a container volume that was not mounted where Ollama thinks it is. Checking free space is the first move, and it resolves a meaningful share of these on its own.

Any other got value means bytes did arrive and were wrong, which is the next section.

What corrupts a blob in practice

Something in the middle rewriting the response. Corporate TLS-inspecting proxies, captive portals and some content filters return a modified body, an error page, or a truncated stream with a 200 status. The transfer looks complete and the content is not. If you are on a managed network, test the same pull on a different connection before anything else — this is the most common cause of a reproducible mismatch on one machine and not another.
An interrupted transfer that was resumed badly. Sleep, a dropped VPN, a flaky link. Multi-gigabyte downloads have a lot of opportunity for this.
A disk that filled during the pull. Model blobs are large and the store may not be on the volume you assume; on Linux the default lives under the service user’s home rather than yours.
Genuinely faulty storage or memory. Rare, and worth considering only if it recurs across different models and different networks. A repeated mismatch on a machine where nothing else is wrong is a reason to run a memory test.

There is a diagnostic in the digests themselves that separates the first two. A proxy that substitutes an error page produces a small file and therefore a digest that is stable across attempts — pull twice and you get the identical got value both times, because you are being handed the identical wrong document. A transfer corrupted by noise or truncation produces a different got value on each attempt, because the damage lands in a different place. Two runs and a comparison of the two got values is a five-minute experiment that tells you which half of the list above to read.

It is also worth being clear about what the layer digest covers. Each layer is verified independently, so a model can fail on one layer and have every other layer already correct on disk. That is why the error names one digest rather than the model, and why deleting exactly that blob is enough — the multi-gigabyte weights layer usually does not need re-fetching when it is the small template or parameters layer that failed, and vice versa. Read which digest is in the message before you decide how much you are about to re-download.

Clearing the blob and pulling again

Remove the model, which is the supported path. This drops the manifest and unreferenced blobs together:
```
ollama rm llama3.1:8b
ollama pull llama3.1:8b
```
If it recurs, remove the specific blob. Blobs live under the models directory — commonly /usr/share/ollama/.ollama/models/blobs for a Linux service install and ~/.ollama/models/blobs for a user install — named after their digest. Delete the file whose name matches the want digest in the error, then pull again.
```
ls -l ~/.ollama/models/blobs | grep 8de95da6
rm ~/.ollama/models/blobs/sha256-8de95da68dc485c0889c205384c24642f83ca18d089559c977ffc6a3972a71a8
```
Check free space on the volume that actually holds it before retrying: df -h on the blobs directory, not on your home directory.
Change networks if the same digest fails twice. Two identical failures across two attempts is a proxy signature, not bad luck.

Ollama’s store layout is an implementation detail and has moved between releases. ollama rm is the interface; reach into the blobs directory only when that has not worked, and delete a file whose digest you have matched against the error rather than clearing the directory wholesale.

A related but distinct failure: if the pull fails before any blob is fetched, with a complaint about the manifest, that is the manifest error and it is about names, not bytes. And if a corrupt file gets past verification — which happens with GGUFs imported by hand rather than pulled — the failure surfaces later as an invalid file magic error.