Local LLM · recorded 2026-08-30 · applies to 2 tool(s) ✓ Verified

Problem: Models keep filling up the system drive — how to move the Ollama model directory —— Trove problem library

Verified 2026-08-30models fill the C drive — stop the service (systemctl stop ollama), move the model dir to another drive (copy first, delete old after verifying), restart.

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-models and 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

  1. At startup Ollama uses OLLAMA_MODELS to 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).
  2. A model = manifests/ (index) + blobs/ (weights), both inside the models dir; the whole dir can be relocated, nothing depends on absolute paths.
  3. 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).
  4. Don't confuse OLLAMA_MODELS (model dir) with OLLAMA_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 list matches 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 new blobs/; the old dir stops growing.
  • Rename the old dir temporarily and ollama list still works (if you set the env wrong, this is where you'll see models "missing").

Other environments

  • Linux curl install: default ~/.ollama/models; add Environment to /etc/systemd/system/ollama.service.
  • Snap install: default /var/snap/ollama/common/models; configure via snap 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 as ollama list is normal after restart, models appear in the WebUI as before.

Symptom

  • System drive full; after mv the models dir, ollama list is 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_MODELS is 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_MODELS per install type (systemd Environment, snap snap set ollama models=, docker -e, Windows user env var) → restart → verify with ollama list plus 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 list shows qwen2.5-0.5b 491MB immediately (no re-download);
  • Container B without OLLAMA_MODELS → default ~/.ollama/models exists but is empty, ollama list empty (contrast);
  • ollama show qwen2.5-0.5b fine; ollama run qwen2.5-0.5b "say hi" generates on CPU;
  • ollama pull all-minilm:l6-v2 → success, new dir blobs 2→6, ollama list shows both models;
  • Snap mechanism verified: /snap/ollama/current/bin/snap_launcher.sh has OLLAMA_MODELS=$(snapctl get models); snap get ollama exposes the models key → snap changes dir via sudo 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:

Applicable tools (2)

This problem is linked from the tool pages below — reachable from either side.

ollamadocker

Source & evidence

Recorded Verified ✓ VerifiedApplies to 2 tool(s)
Entries contain locally measured or reviewable-source solutions; unmeasured items are explicitly labeled.

← Local LLM domain | Problem Catalog Experience | Facing another issue? Go to the Helpdesk