TL;DR: Ollama downloads every model to your home drive by default, and a couple of 70B pulls can put 100 GB on a disk that was never meant for it. The fix is one environment variable — OLLAMA_MODELS — but it has to be set where the service reads it, not in your shell, and on Linux the target folder must be owned by the ollama user or the service silently fails.

What you’ll be able to do after this guide:

• Point Ollama at a second SSD (or a bigger data drive) so pulls never touch C: again
• Move the models you’ve already downloaded without re-pulling a single gigabyte
• Avoid the two failures that make people think it didn’t work — the shell-export trap and the Linux permission-denied error

Honest take: This is a five-minute fix on macOS and Windows and a ten-minute one on Linux. The only thing that turns it into an afternoon is setting the variable in the wrong place and re-downloading 40 GB you already had.

Where Ollama actually puts your models

Ollama stores everything — model weights, manifests, the lot — under a .ollama/models directory tied to whatever user the service runs as. The exact location depends on your OS and how you installed it:

OS	Default model path
Windows	C:\Users\<username>\.ollama\models
macOS	~/.ollama/models
Linux (system service)	/usr/share/ollama/.ollama/models
Linux (manual / user run)	~/.ollama/models

The Windows and system-Linux defaults are the ones that cause pain. On Windows that path lives on C:, which is usually your smallest, fastest, most-precious drive. On Linux, /usr/share/ollama is on the root partition — and if you installed on a VM or a cloud box with a 40 GB root disk, one ollama pull llama3.3:70b fills it.

How fast does it fill? These are real download (on-disk) sizes for the default Q4_K_M quantization Ollama serves:

Model	Q4_K_M on disk
Llama 3.2 3B	~2 GB
Llama 3.1 8B	~5 GB
Gemma 4 31B	~20 GB
Llama 3.3 70B	~43 GB

Pull a few of those to compare them — the exact thing this site keeps telling you to do — and you’re past 100 GB before you’ve picked a favorite. The models themselves live as sha256-… blobs inside models/blobs/; a single blob for a 70B model is a ~43 GB file. The tiny models/manifests/ tree just points at them. Both need to move together.

The one-variable fix: OLLAMA_MODELS

Ollama reads the OLLAMA_MODELS environment variable at startup and stores everything there instead of the default. Set it to a path on your big drive, restart the service, and every future pull lands on the new disk.

The catch that trips up most people: Ollama’s model serving runs as a background service, not as the shell you typed ollama into. Setting the variable in ~/.bashrc, or with a plain export in your terminal, only affects commands you launch from that terminal — the background service never sees it. You have to set the variable where the service reads it. That’s different on each OS.

Windows

1. Quit Ollama completely — click the tray icon (bottom-right) and choose Quit Ollama. Closing the window isn’t enough; the service keeps running in the tray.

2. Open Settings → System → About → Advanced system settings → Environment Variables (or just search “environment variables” in the Start menu). Under User variables, click New and add:

   • Variable name: OLLAMA_MODELS
   • Variable value: D:\OllamaModels (or wherever you want them)

   The command-line equivalent is setx OLLAMA_MODELS "D:\OllamaModels".

3. Start Ollama again from the Start menu.

If a new pull still lands on C:, reboot — that guarantees the service picks up the new environment. Rebooting is the most reliable way to be sure the variable took effect on Windows.

macOS

macOS uses launchctl to hand environment variables to GUI-launched apps:

launchctl setenv OLLAMA_MODELS "/Volumes/AI/ollama-models"

Then quit and reopen the Ollama app.

The gotcha here is persistence: launchctl setenv is lost on reboot. For a permanent setting, add the variable to a LaunchAgent plist (or, if you run ollama serve manually from a terminal, an export in your shell profile is fine because you are the service in that case). If Ollama “forgets” the custom path after a restart, this is why.

Linux (systemd) — and the permission gotcha

On a package install, Ollama runs as a systemd service under a dedicated ollama user. Edit the service with a drop-in override (update-safe — don’t hand-edit the packaged unit file):

sudo systemctl edit ollama.service

Add this under the [Service] section:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama/models"

Then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Now the part that eats people’s afternoons. The ollama service user must own the target directory. World-writable (drwxrwxrwx) is not enough — the service will fail to create its subdirectories with:

Error: mkdir /mnt/data/ollama/models: permission denied

The fix is to hand ownership to the ollama user:

sudo mkdir -p /mnt/data/ollama/models
sudo chown -R ollama:ollama /mnt/data/ollama

The reason this is confusing: if you test the path by running OLLAMA_MODELS=/mnt/data/ollama/models ollama serve by hand, it works — because your user owns the folder. The moment systemd starts the service under the ollama user, it can’t write there. Ownership, not permission bits, is what matters.

If your data drive is mounted at a path guarded by SELinux (Fedora/RHEL) or the mount options strip write access, you may also need to relabel or remount — but chown clears the problem for the overwhelming majority of Ubuntu/Debian installs.

Moving the models you already downloaded

Changing the variable only redirects future pulls. Anything you already downloaded stays on the old drive. Don’t re-pull — move it.

Stop Ollama first (tray → Quit on Windows/macOS, sudo systemctl stop ollama on Linux), then move the contents:

Windows (PowerShell):

Move-Item "$env:USERPROFILE\.ollama\models\*" "D:\OllamaModels\"

macOS / Linux:

# Adjust the source to /usr/share/ollama/.ollama/models on a Linux service install
mv ~/.ollama/models/* /mnt/data/ollama/models/

On Linux, re-run the chown afterward so the moved blobs/ and manifests/ folders are owned by ollama:

sudo chown -R ollama:ollama /mnt/data/ollama

Start Ollama again and run ollama list. Every model should still be there — because the files are physically in the new location and the service is now looking there. If the list is empty, the service is reading a different path than where you moved the files; re-check the variable.

The external-drive trap

The obvious move is “throw the models on a cheap USB drive.” It works, but understand the trade-off before you do it: a model has to be read off disk into VRAM/RAM every time it cold-starts, and drive speed sets how long that takes.

Do the arithmetic. A 43 GB 70B model off a Gen4 NVMe SSD (~7,000 MB/s) loads in roughly 6 seconds. Off a USB 3.0 SATA SSD (~500 MB/s) that same load is closer to 85 seconds — every time the model gets evicted and reloaded. If you’re bothered by Ollama reloading the model constantly, a slow model drive makes each reload dramatically worse.

The verdict: put your model library on an internal NVMe SSD, not a bus-powered USB drive. A 2 TB drive holds 40+ Q4 models comfortably. As of July 2026 the Samsung 990 Pro 2TB runs about $390 (dropping to ~$370 on sale) at ~7,450 MB/s sequential read, and the WD Black SN850X 2TB is roughly $40 cheaper at similar ~7,300 MB/s speeds. Either is plenty for a model library — this is bulk sequential reads, not the random-IOPS torture test that separates premium drives. We go deeper on why your NVMe drive matters for model loading in a dedicated guide.

If you only occasionally need a huge model and don’t want to buy storage for it at all, renting a cloud GPU with fast local disk — RunPod instances come with NVMe scratch space — is cheaper than a dedicated drive for one-off jobs.

The symlink alternative (and when to use it)

If you’d rather not touch environment variables at all, you can move the models folder and drop a symbolic link (Linux/macOS) or junction (Windows) where Ollama expects it:

Windows (run as Administrator, after moving the folder to D:\OllamaModels):

mklink /J "%USERPROFILE%\.ollama\models" "D:\OllamaModels"

Linux / macOS:

ln -s /mnt/data/ollama/models ~/.ollama/models

This works because Ollama follows the link transparently. When is it the better choice? When something other than Ollama also expects the default path — a backup script, another tool, a tutorial you’re following that hard-codes ~/.ollama/models. The OLLAMA_MODELS variable is cleaner for a fresh setup; a symlink is the escape hatch when a default path is baked in somewhere you can’t easily change.

Verify it worked

After any of these methods, confirm the redirect took:

1. ollama list — your existing models should still appear.
2. ollama pull llama3.2:3b — a small, ~2 GB pull.
3. Check the new directory grew and C: (or your root partition) did not. On Windows, watch D:\OllamaModels\blobs; on Linux, du -sh /mnt/data/ollama/models.

If the pull landed on the old drive, the service isn’t reading your variable — you set it in a shell instead of the service (Linux/macOS) or didn’t fully restart the tray app (Windows).

Common failures after moving

• ollama list is empty after moving files. The service is reading a different path than where you moved the blobs. Re-check the variable value matches the destination exactly, including trailing structure.
• Pulls still hit C: on Windows. You closed the window but the tray service kept running with the old environment. Fully Quit from the tray, or reboot.
• permission denied / mkdir … permission denied on Linux. The ollama user doesn’t own the target. Run sudo chown -R ollama:ollama /your/path.
• Path forgotten after macOS reboot. launchctl setenv is not persistent; move it into a LaunchAgent plist.
• Ollama can’t find models after a NAS mount drops. If you pointed OLLAMA_MODELS at network storage, a dropped mount takes your whole library offline. That’s usually the wrong call — see when not to use a NAS for local LLMs.

Once storage is sorted, the next thing worth doing is making sure you’re not going to lose it — a moved model library is still a single drive away from gone. Our guide on backing up your local AI setup covers exactly which folders to snapshot. And if models are landing on the right drive but still loading onto the CPU instead of the GPU, that’s a separate problem — fix Ollama not using your GPU first.

FAQ

Does moving models break anything? No. The blobs and manifests are just files; Ollama doesn’t care where they live as long as OLLAMA_MODELS points at them. Nothing in the model needs re-registering.

Can I set OLLAMA_MODELS in .bashrc? Only for models you run by launching ollama serve yourself in that terminal. For the background systemd service (the normal Linux install), it does nothing — use systemctl edit.

Will a second drive make inference faster? No. Decode speed is bound by memory bandwidth (your GPU’s VRAM, or system RAM for CPU offload), not disk. A faster drive only shortens the one-time load delay when a model cold-starts. If tokens/sec is your problem, see how to speed up Ollama.

What about LM Studio and other tools? LM Studio has its own model directory setting in-app, and llama.cpp takes a path argument per run — this guide is Ollama-specific. If you also code against local models, aicoderscope.com covers the tooling side, and aifoss.dev tracks the open-source stack.

Can I keep some models on C: and some on D:? Not through OLLAMA_MODELS alone — it’s a single location. You’d need per-model symlinks inside the blobs directory, which is fragile. Simpler to put the whole library on the big drive.

Recommended Gear

Products mentioned in this guide, for a fast Ollama model library:

• Samsung 990 Pro 2TB — ~$390, ~7,450 MB/s read; premium pick for a dedicated model drive.
• WD Black SN850X 2TB — ~$40 cheaper, ~7,300 MB/s read; the value choice, more than fast enough for sequential model loads.

Sources

• Ollama Model Storage Path Guide: Windows, macOS, Linux, and Moving Models — knightli.com
• Where Does Ollama Store Models on Windows? Location & Move Guide — ai-ollama.github.io
• permission denied when setting OLLAMA_MODELS in service file (Issue #2147) — GitHub / ollama
• Move Ollama Models to a different location — Rost Glukhov
• Ollama VRAM & disk requirements table (1B–405B) — Local AI Master
• Samsung 990 PRO 2TB NVMe SSD — Amazon
• WD_BLACK SN850X 2TB NVMe SSD — Amazon
• Samsung 990 PRO 2TB deal extended beyond Prime Day 2026 — Neowin

Last updated July 5, 2026. Prices and specs change; verify current rates before purchasing.