Quick fix
# Say the new dir is /data/ollama-models (create it first)
# 1) Stop the service
sudo systemctl stop ollama # systemd install
# snap: sudo systemctl stop snap.ollama.service
# 2) Move the dir (copy first if you want a rollback path)
sudo mv ~/.ollama/models /data/ollama-models
# snap: sudo mv /var/snap/ollama/common/models /data/ollama-models
# 3) Point Ollama at the new dir
# systemd: edit /etc/systemd/system/ollama.service, under [Service] add
# Environment="OLLAMA_MODELS=/data/ollama-models"
sudo systemctl daemon-reload
# Linux standard installer (deb/rpm, service runs as user ollama): chown the new dir first
sudo chown -R ollama:ollama /data/ollama-models
# 4) Start + verify
sudo systemctl start ollama
ollama list # models should be there, same names and sizes
- Snap: different mechanism,
sudo snap set ollama models=/data/ollama-models(see step 3 below). - Docker: add
-e OLLAMA_MODELS=/models -v /data/ollama-models:/models. - Windows native: add a user env var
OLLAMA_MODELS=D:\ollama-modelsand restart the tray app.
What you will run into
Ollama stores models in a default directory: ~/.ollama/models on Linux, C:\Users\you\.ollama\models on Windows, /var/snap/ollama/common/models for snap installs. Models are huge (a 7B model is 4–5GB), and the system drive fills up fast.
You want to move them to another drive, but advice is inconsistent: change OLLAMA_MODELS?
Move the whole .ollama dir? Reinstall? The mechanism is simple: where Ollama reads models is entirely decided by the OLLAMA_MODELS env var — move the dir + set the var. No reinstall, no re-download.
Why this happens
- At startup Ollama uses
OLLAMA_MODELSto decide the model directory; when unset it falls back to the platform default (Linux/macOS~/.ollama/models, Windows%USERPROFILE%\.ollama\models, snap/var/snap/ollama/common/models). - A model =
manifests/(index) +blobs/(weights), both inside the models dir; the whole dir can be relocated, nothing depends on absolute paths. - Common trap: moving the dir without changing the env var → Ollama recreates an empty default dir, and models look "gone" (they are not — put the var back or the dir back and they reappear).
- Don't confuse
OLLAMA_MODELS(model dir) withOLLAMA_HOST(server address). If Open WebUI can't connect, that's the latter — see open-webui-ollama-connect.
The model directory resolution is "env var first, default as fallback": ollama reads OLLAMA_MODELS at every startup to decide the models directory;
if unset it uses the platform default (Linux ~/.ollama/models, Windows %USERPROFILE%\.ollama\models, snap /var/snap/ollama/common/models).
Inside, the models directory is manifests/ (model index, recording layers and digests) + blobs/ (the weight files themselves) — you can move the whole directory; there is no absolute-path dependency between the two.
The trap comes from the "resolution timing": if you mv the directory without changing the env var, the next startup creates a fresh empty directory at the default path and it looks like "all models are gone" — they are still where you left them.
Deterministic takeaway: migration is three steps — set OLLAMA_MODELS to the new directory → move manifests+blobs → restart the service (the variable is only read at startup);
OLLAMA_MODELS and OLLAMA_HOST are two different variables (model directory vs server address) — editing the wrong one changes nothing.
Step by step
1. See where models are and how big — Required
ollama list # which models
# Linux default ~/.ollama/models; snap /var/snap/ollama/common/models
du -sh ~/.ollama/models # size
2. Stop the service — Required
sudo systemctl stop ollama # curl-script install
sudo systemctl stop snap.ollama.service # snap install
pgrep -af ollama should show no serve process anymore.
3. Set the new dir per install type — Required
systemd (official script) — edit /etc/systemd/system/ollama.service, under [Service]:
Environment="OLLAMA_MODELS=/data/ollama-models"
then sudo systemctl daemon-reload.
Linux standard installer (deb/rpm) differs from the curl script: the standard installer keeps models at /usr/share/ollama/.ollama/models and runs the service as the ollama user.
The new directory must therefore be owned by that user: sudo chown -R ollama:ollama <new-dir>. Otherwise ollama cannot write to it, and models "disappear" (confirmed by an official maintainer in GitHub issue #9677).
The curl-script install uses the current user's ~/.ollama/models.
snap (config mechanism verified locally) — the snap launcher reads snapctl get models, so:
sudo snap set ollama models=/data/ollama-models
sudo systemctl restart snap.ollama.service
Docker — mount + env:
docker run -d -v /data/ollama-models:/models \
-e OLLAMA_MODELS=/models \
-p 11434:11434 ollama/ollama
Windows native — Settings → System → About → Advanced system settings → Environment Variables, add a user variable OLLAMA_MODELS=D:\ollama-models, then quit and reopen the tray app.
4. Move the dir — Required
# Safe: copy first, verify, then delete the old one (slow for big models, but reversible)
sudo cp -a ~/.ollama/models /data/ollama-models
# or, when confident:
sudo mv ~/.ollama/models /data/ollama-models
5. Start + verify — Required
sudo systemctl start ollama
ollama list # names/sizes must match exactly
ollama run <an-existing-model> "hi" # actually run it, not just list
6. Confirm new downloads land in the new dir — Required
ollama pull <a-small-model> # e.g. all-minilm:l6-v2 (45MB)
ls /data/ollama-models/blobs # new files appear here
How to confirm it works
ollama listmatches the pre-migration state exactly (same names and sizes).- An existing model actually generates output — not just manifests readable, weights load too.
- After a new
ollama pull, new files appear in the newblobs/; the old dir stops growing. - Rename the old dir temporarily and
ollama liststill works (if you set the env wrong, this is where you'll see models "missing").
Other environments
- Linux curl install: default
~/.ollama/models; addEnvironmentto/etc/systemd/system/ollama.service. - Snap install: default
/var/snap/ollama/common/models; configure viasnap set ollama models=...(launcher:OLLAMA_MODELS=$(snapctl get models)), not by editing service files. - Docker:
-e OLLAMA_MODELS=/models+ volume mount; the volume name is arbitrary — the key is mounting the host dir at the container path the env var points to. - macOS native:
launchctl setenv OLLAMA_MODELS /Volumes/xxx/ollama-models(or the app default~/.ollama/models). - Windows: set a user env var
OLLAMA_MODELS, then fully quit and reopen the tray app after changing it. - Windows caveats: the newer tray GUI's model-path setting does not match what the CLI reads (GitHub issue #12154) — always trust the env var. Uninstalling Ollama does not delete models under
OLLAMA_MODELS. - Windows official GUI path: Settings (Win11) / Control Panel (Win10) -> search "environment variables" -> "Edit environment variables for your account" -> add/edit the user variable
OLLAMA_MODELS=D:\ollama-models(docs.ollama.com/windows). - Open WebUI users: moving the model dir does not affect connectivity (that's
OLLAMA_HOST/OLLAMA_BASE_URL); as long asollama listis normal after restart, models appear in the WebUI as before.
Symptom
- System drive full; after
mvthe models dir,ollama listis empty. - Can't find the right way to change it for snap / docker / Windows.
- After the change, new downloads still go to the old path.
Cause
- When
OLLAMA_MODELSis unset, the platform default dir is used; moving only the dir recreates an empty default dir, so models look lost (they aren't). The env-var entry point differs per install type (systemd/snap/docker/Windows).
Solution
- Stop the service → copy/move the models dir → set
OLLAMA_MODELSper install type (systemdEnvironment, snapsnap set ollama models=, docker-e, Windows user env var) → restart → verify withollama listplus a real run → pull a small model to confirm new downloads land in the new dir.
Verification Evidence
- Reproduced with independent containers (
ollama/ollama:latest; the machine's snap instance was untouched): - Copied the local model (qwen2.5-0.5b, 469M) to a new dir
/tmp/ollama-models; - Container A with
OLLAMA_MODELS=/models(mounted to the new dir) →ollama listshows qwen2.5-0.5b 491MB immediately (no re-download); - Container B without
OLLAMA_MODELS→ default~/.ollama/modelsexists but is empty,ollama listempty (contrast); ollama show qwen2.5-0.5bfine;ollama run qwen2.5-0.5b "say hi"generates on CPU;ollama pull all-minilm:l6-v2→ success, new dir blobs 2→6,ollama listshows both models;- Snap mechanism verified:
/snap/ollama/current/bin/snap_launcher.shhasOLLAMA_MODELS=$(snapctl get models);snap get ollamaexposes themodelskey → snap changes dir viasudo snap set ollama models=<path>; - Test containers and temp dir removed.
local repro log 2026-08-30
References
- Ollama official docs (Windows: install location / model directory / env vars) — <https://docs.ollama.com/windows>
- GitHub issue ollama/ollama#9677 (Linux standard installer needs chown ollama:ollama) — <https://github.com/ollama/ollama/issues/9677>
- GitHub issue ollama/ollama#12154 (GUI model-path change inconsistent with CLI; trust the env var) — <https://github.com/ollama/ollama/issues/12154>
Related canonicals
Read in order: precondition -> same root / same domain / related:
- Related (similar errors, different cause):
- Open WebUI RAG retrieval not working / embedding misconfig (embedding models live in the same model dir — move them together)
- ollama pull hangs/times out (new downloads land in the new dir; slow pulls see this page)
- ollama won't install — official installer unreachable (install type decides the default dir and config entry)
Applicable tools (2)
This problem is linked from the tool pages below — reachable from either side.
ollamadockerSource & evidence
← Local LLM domain | Problem Catalog Experience | Facing another issue? Go to the Helpdesk