You run ollama pull llama3.2:3b and the progress bar completes with no errors. Then you run ollama list and the model isn’t there. Or it was there yesterday and has disappeared after a system restart. Running ollama run llama3.2:3b produces “Error: model ‘llama3.2:3b’ not found.” The blobs are on disk — you can see them in ~/.ollama/models/blobs/ — but the manifest that tells Ollama what those blobs compose is either missing or Ollama is looking in the wrong directory. This is a filesystem or environment variable configuration issue, not a download failure.
Common causes
Ordered by hit rate, highest first.
1. OLLAMA_MODELS environment variable set inconsistently
If you set OLLAMA_MODELS=/custom/path in your shell profile but the Ollama system service doesn’t have that variable (because systemd services don’t inherit user shell variables), the service stores models in the default ~/.ollama/models/ while the CLI reads from /custom/path. You pull into one location and list from another.
How to spot it: Run systemctl show ollama | grep Environment and compare the OLLAMA_MODELS value against echo $OLLAMA_MODELS in your terminal. If they differ, that’s the root cause.
2. Manifest directory exists but manifests are corrupted or zero-byte
After an interrupted pull, Ollama may have written the blob files but left the manifest file empty or partially written. The CLI checks manifest existence first; if the manifest is zero bytes or invalid JSON, the model is silently omitted from ollama list.
How to spot it: Run ls -la ~/.ollama/models/manifests/registry.ollama.ai/library/. If a directory for your model exists, check whether the version file (e.g., latest) is non-zero and valid JSON.
3. Model pulled with one user account, listed with another
On a shared Linux machine, if ollama pull was run as root (e.g., with sudo) and ollama list is run as a regular user, the models live in /root/.ollama/models/ while the user’s Ollama service reads from ~/.ollama/models/.
How to spot it: Run sudo ls /root/.ollama/models/manifests/ and compare with ls ~/.ollama/models/manifests/. If the model appears only in the root path, it was pulled as root.
4. Ollama service not restarted after changing OLLAMA_MODELS
Ollama caches the model registry in memory at startup. If you change OLLAMA_MODELS after the service started, models pulled into the new path won’t appear until the service is restarted.
How to spot it: Check the service uptime: systemctl status ollama | grep Active. If the service started before you changed OLLAMA_MODELS, restart it.
5. Model tag alias not recognized
Pulling ollama pull llama3 without a tag uses the latest alias. If the Ollama registry resolves latest to a different underlying model than what you expect, or if you later try ollama run llama3.3:latest (a different model), it will not be found because you pulled llama3 not llama3.3.
How to spot it: Run ollama list and look at the exact NAME:TAG column. The tag you pulled must exactly match the tag you run. llama3:latest and llama3.3:latest are different models.
6. macOS case-sensitivity issue on HFS+ volumes
macOS default HFS+ volumes are case-insensitive but case-preserving. Ollama expects manifest directories at exactly registry.ollama.ai/library/modelname/latest. On some configurations, a casing mismatch in the directory name can cause ollama list to find zero manifests even though the files exist.
How to spot it: Run ls -la ~/Library/Caches/ and check if there are any unexpected Ollama directories. Also run ls ~/.ollama/models/manifests/registry.ollama.ai/library/ and verify model names match their exact lowercase spelling.
Shortest path to fix
Step 1: Check where the Ollama service is actually reading models from
# Check service environment
systemctl show ollama | grep OLLAMA_MODELS
# Or
sudo cat /etc/systemd/system/ollama.service | grep OLLAMA_MODELS
# Check current terminal environment
echo $OLLAMA_MODELS
# Check default location
ls ~/.ollama/models/manifests/registry.ollama.ai/library/Step 2: Verify and repair the manifest for the missing model
MODEL="llama3.2"
TAG="3b"
MANIFEST_PATH=~/.ollama/models/manifests/registry.ollama.ai/library/$MODEL/$TAG
# Check if manifest exists and is valid
ls -la "$MANIFEST_PATH"
cat "$MANIFEST_PATH" | python3 -m json.tool
# If corrupted or zero-byte, remove it and re-pull
rm -f "$MANIFEST_PATH"
ollama pull $MODEL:$TAGStep 3: If OLLAMA_MODELS is inconsistent, set it in the systemd unit
# Edit the service file
sudo systemctl edit ollama
# Add under [Service]:
# Environment="OLLAMA_MODELS=/your/custom/models/path"
# Then reload and restart
sudo systemctl daemon-reload
sudo systemctl restart ollama
# Verify
systemctl show ollama | grep OLLAMA_MODELSStep 4: Move models from root to user if pulled as root
# Copy manifests and blobs from root to user
sudo cp -r /root/.ollama/models/manifests ~/.ollama/models/
sudo cp -r /root/.ollama/models/blobs ~/.ollama/models/
# Fix ownership
sudo chown -R $USER:$USER ~/.ollama/
# Restart service and verify
sudo systemctl restart ollama
ollama listStep 5: Refresh the model list after changing paths
# Always restart the service after any path change
sudo systemctl restart ollama
# Wait for the service to be ready
until curl -s http://localhost:11434/api/version > /dev/null; do sleep 1; done
# Verify
ollama listStep 6: Re-pull with the exact tag if the alias is ambiguous
# Instead of pulling an alias, use an explicit tag
ollama pull llama3.2:3b
# Verify the exact tag in the list
ollama list | grep llama3.2
# Run with the exact same tag
ollama run llama3.2:3b "say hello"Prevention
- Set
OLLAMA_MODELSin both your shell profile (~/.bashrc/~/.zshrc) and the systemd unit file (/etc/systemd/system/ollama.service) to the same value. - Never run
ollama pullwithsudounless the Ollama service is also running as root. - After pulling a model, always verify with
ollama listbefore running it — catch missing-manifest issues immediately while the download is fresh. - Use explicit version tags (
llama3.2:3b) rather thanlatestaliases to avoid tag resolution surprises across Ollama versions. - After any Ollama upgrade or OS update, restart the Ollama service to clear the in-memory model registry.
- Keep the manifest path on a local, non-encrypted filesystem — encrypted home directories (some Ubuntu default configs) can cause manifest read failures until the volume is fully decrypted.
FAQ
Q: Can I manually register a GGUF file I downloaded directly (not via ollama pull) so it appears in ollama list?
A: Yes. Create a Modelfile that references the GGUF path, then run ollama create mymodel -f Modelfile. The model will appear in ollama list and can be run normally. Example Modelfile: FROM /path/to/model.gguf.
Q: Blobs exist on disk but ollama show modelname says “model not found” — can I recover without re-downloading?
A: Yes, if you have the model’s manifest JSON. The manifest maps the model name to the blob SHA256 hashes. If you have a backup of the manifest directory, restore it to ~/.ollama/models/manifests/registry.ollama.ai/library/modelname/latest and restart Ollama. The blobs will be recognized without re-downloading.
Q: How do I move my Ollama model library from one machine to another?
A: Copy the entire ~/.ollama/models/ directory (both blobs and manifests subdirectories) to the target machine’s corresponding path. Set OLLAMA_MODELS on the target if using a non-default path, then restart the Ollama service. Run ollama list to confirm all models are recognized.
Q: After upgrading Ollama from 0.3 to 0.4, some models disappeared from ollama list — why?
A: Ollama 0.4 changed the manifest format for some model families. Models pulled with 0.3 may need to be re-pulled. Run ollama pull modelname:tag for any missing models — Ollama will only re-download layers whose blobs are missing or have changed checksums.