Error: digest mismatch, file must be downloaded again
The message
Error: digest mismatch, file must be downloaded againWhat it means
Ollama downloaded a model file, checked its fingerprint against the one the registry published, and they didn't match. It deletes the bad file so the next pull fetches it again.
What to do
Run the pull again. If it fails every time, and especially with a different got value each time, test your RAM and disk, since the fault is on the machine rather than in Ollama.
The pull runs to 100%, the next line says verifying sha256 digest, and then:
Error: digest mismatch, file must be downloaded again: want sha256:1a640cd4d69a5260bcc807a531f82ddb3890ebf49bc2a323e60a9290547135c1, got sha256:5eef5d8ec5ce977b74f91524c0002f9a7adeb61606cdbdad6460e25d58d0f454That line is from issue #941, which has run to 162 comments since 2023. We read the same check in Ollama 0.34.4 and it prints the same words.
What the check does
Every file in an Ollama model is named after its SHA-256 digest, a fingerprint computed from every byte, so the name says what the contents should hash to. After a download, Ollama reads the file back from disk, computes the fingerprint again and compares. want is the published one. got is what your copy produced. If they differ, even by one bit anywhere in a 40 GB file, Ollama deletes the file and stops.
Deleting it is why the message says "must be downloaded again". The next ollama pull starts that file from scratch, and for a one-off glitch that's the whole fix.
When it fails every time
Look at the got value across attempts. If it's different on each try, the bytes are being damaged somewhere between the network and your disk. An Ollama contributor noted exactly that in #8105 (a 42 GB llama3.3 pull): different checksums each time suggested an incomplete download that Ollama hadn't caught.
The #941 thread went further. Several people with repeated mismatches found bad memory. One of them, marked as a contributor on the repo, pulled the faulty stick and the errors stopped, and another found one bit flipping in a 32 MB range of RAM, which was also breaking big downloads outside Ollama. A multi-gigabyte file passes through memory on its way to disk, and a checksum catches a single wrong bit.
In #13775 (January 2026) the same error hit a local GGUF import too. A collaborator showed the hash Ollama computed didn't match the published file, and the point he kept coming back to was "If the file on disk has a different sha256 then it's been corrupted". He suggested a longer memtester run or a full memtest86+ boot. There's a comment from April 2026 that points somewhere else (three machines, no hardware faults found, and it worked on an unmerged branch), so hardware isn't the answer every time.
What to try
Retry once or twice first. Then check the file outside Ollama: download the same model file another way (for a Hugging Face GGUF, straight from the site) and run sha256sum on it twice. If two readings of the same file disagree, the machine is corrupting data, and a memory test is next. Check free disk space and the disk's health while you're at it.
Behind a proxy or antivirus that inspects downloads, try another network, since anything that rewrites the stream will change the hash. And if you're importing your own file and see digest mismatch, expected with a 400, that's a similar check run when the client hands the file to the Ollama server (the blob upload step of ollama create).
Other lines the same feature prints
Match yours against these if the one at the top of the page is not quite it. They come from the same code and mean related things.
digest mismatch, file must be downloaded againError: digest mismatch, file must be downloaded again: want sha256:digest mismatchdigest mismatch, expected