Ollama: “pull model manifest: file does not exist”

The pull fails before a single byte of weights is requested. That timing is the diagnosis: Ollama asked the registry for a name and the registry does not have one under that name.

The string

pulling manifest
Error: pull model manifest: file does not exist

It appears on ollama pull, on ollama run for a model not yet present, and — confusingly — on ollama run for a model you just created locally with ollama create. That last case is a different cause with the same string and is covered below.

What the message is not: a network error, an authentication error, or a corruption error. Ollama has connectivity, or it would say so; it reached the registry and got back a negative answer. Contrast the failure mode where bytes do arrive and hash wrongly, which is the digest mismatch.

What a manifest is and why it is first

Ollama stores models the way a container registry stores images: a small manifest document lists the layers a model is made of — the weights, the template, the parameters, the licence — each identified by a content digest. Pulling always resolves the manifest first, because only the manifest knows what to download.

So a manifest failure is a lookup failure, and lookups are on names. The name has three parts and any of them can be wrong: an optional namespace, a model name, and a tag after the colon, defaulting to latest.

ollama pull llama3.1:8b-instruct-q4_K_M
#             ^model  ^tag

ollama pull hf.co/user/repo:Q4_K_M
#           ^namespace/host  ^tag

Cause one: the tag does not exist

By far the most common case, and it is rarely a typo in the model name — it is a tag that was never published. Tags encode parameter size and quantization, and the exact set differs per model. A model may publish 8b and 70b but not 13b; it may publish q4_K_M but not q4_0; it may use a different separator than the model you copied the pattern from.

Two checks settle it. First, try the bare name with no tag: if ollama pull mistral works and ollama pull mistral:7b-instruct-q5_1 does not, the tag is the problem and the model is fine. Second, look at the published tag list on the model’s registry page before composing a tag by analogy.

Related traps in this family:

• Case. Repository and tag names are matched as written. A quantization tag published as Q4_K_M is not q4_k_m on hosts that treat them as distinct.
• A missing namespace. Community models live under a user or organisation prefix, and dropping it looks up a different, usually nonexistent, model.
• Hugging Face-hosted GGUFs. These are pulled through a host-prefixed name, and the tag selects which quantization file in the repository to take. A repository with a single unusual filename may not expose the tag you expect. If the repository is also gated, you will get a 403 rather than this error — the two are worth distinguishing before you start editing names.

Cause two: it was there and is not now

A name that worked last month can stop working. Publishers unpublish models, rename them, restructure tags, or retire preview builds; a cloud-hosted variant can be withdrawn while the local-weights variant remains. Reports of this error against specific model names appear and then stop being reproducible precisely because the registry changed underneath.

The tell is that the same command used to work and your network did not change. There is no fix on your side — the name is gone. What you can do is stop it from being a surprise:

• Pin the tag, never latest, in anything automated. latest is a moving pointer and its target can be replaced.
• Keep the blob rather than re-pulling in CI. A model already in the local store does not consult the registry, so a cached layer survives an upstream removal.
• Have a second name that works. Model availability is a dependency like any other; deploying model weights treats it as one.

Cause three: a Modelfile pointing at nothing

This is the case that confuses people most, because the model is local and no registry should be involved. It happens when a Modelfile’s FROM line cannot be resolved as a local path, so Ollama falls back to treating it as a registry name — and there is no such name.

FROM ./mistral-7b-instruct.Q4_K_M.gguf
PARAMETER num_ctx 4096

1. Use an absolute path, or a path with an explicit ./. A bare filename is ambiguous and gets read as a model name.
2. Remember whose filesystem it is. The path is resolved by the Ollama server, which on a service install runs as a different user and, in Docker, inside the container. A path that exists in your shell may not exist there. This is the same client/server split behind the CLI working while the API does not.
3. Check the create actually succeeded with ollama list before running it. A create that reported an error you scrolled past leaves nothing behind, and the run then fails on the name.
4. Check the file is a real GGUF. If it resolves and loads but fails later on its contents, you are looking at an invalid file magic error instead.