Ollama keeps every model it pulls in one folder: C:\Users\<you>\.ollama\models on Windows, /usr/share/ollama/.ollama/models under the Linux service, and ~/.ollama/models on macOS. On this PC that folder is 32 GB for five models, which is why the most common question about it is how to move it to another drive. The answer is one environment variable, OLLAMA_MODELS, plus two rules that this post proves by breaking them: quit Ollama before you move the folder, and move the files before you point the variable at the new place.

Everything below was run on Ollama 0.40.11 for Windows and 0.40.13 on Ubuntu 24.04 in WSL. The moves and the mistakes were made on a second Ollama server started for the test, so the PC's own models were never touched; the outputs are quoted as captured.

Steps to move the models folder
  1. Quit Ollama: right-click the tray icon and choose Quit; on Linux sudo systemctl stop ollama. Nothing may be serving from the old folder.
  2. Move the whole folder, with its blobs, manifests, manifests-v2 and metadata subfolders, to the new place.
  3. Set OLLAMA_MODELS to the new path: a user environment variable on Windows, an Environment= line under [Service] in the systemd override on Linux.
  4. On Linux, sudo chown -R ollama:ollama the new folder, or pulls and copies will fail with permission denied.
  5. Start Ollama again, from the Start menu or sudo systemctl restart ollama, in a new terminal.
  6. Check: ollama list shows the models, and ollama show <model> --modelfile prints a FROM line under the new folder.

What is in the folder

Four subfolders, not the two that older write-ups describe. This is the PC's own folder, read only: 

Mode   LastWriteTime       Length Name
----   -------------       ------ ----
d----- 22-10-2026 18:05:18        blobs
d----- 18-09-2026 12:13:16        manifests
d----- 09-10-2026 13:54:35        manifests-v2
d----- 22-10-2026 18:04:56        metadata

blobs holds the weights and every other layer, each file named sha256- plus the SHA-256 of its own content; manifests holds one small JSON file per pulled model, naming its layers by digest and size; manifests-v2 is the newer manifest kind, written alongside the old one by a fresh pull; metadata keeps one small JSON per weights blob. Here the folder held 44 files and 32,422,284,878 bytes, of which the blobs were all but 28 KB. The quickest proof of which folder a running server uses is the FROM line of a modelfile, which points straight at the weights blob: 

PS> ollama show qwen2.5:3b --modelfile | Select-Object -First 6
# Modelfile generated by "ollama show"
# To build a new Modelfile based on this, replace FROM with:
# FROM qwen2.5:3b

FROM C:\Users\...\.ollama\models\blobs\sha256-5ee4f07cdb9beadbbb293e85803c569b01bd37ed059d2715faa7bb405f31caa6

The second proof is the server's own log, %LOCALAPPDATA%\Ollama\server.log on Windows or journalctl -u ollama on Linux, whose server config line at every start prints the effective value as OLLAMA_MODELS:C:\\Users\\...\\.ollama\\models. The variable itself is documented in ollama serve --help: 

      OLLAMA_MODELS                 The path to the models directory
      OLLAMA_NOPRUNE                Do not prune model blobs on startup

Moving it, step by step on a test server

The test started a second ollama serve on 127.0.0.1:15195 with OLLAMA_MODELS on a folder called models-a that did not exist yet; the server created it. A pull of the smallest useful model took 19 seconds: 

pulling manifest
pulling c5396e06af29: 100% ▕██████████████████▏ 397 MB
pulling 005f95c74751: 100% ▕██████████████████▏  490 B
verifying sha256 digest
success
NAME            ID              SIZE      MODIFIED
qwen2.5:0.5b    a8b0c5157701    397 MB    About a minute ago

Then the server was stopped and the folder renamed to models-b. On the same drive a move is a rename, so it took 12.5 milliseconds for 398 MB: 

PS> Test-Path .\models-b; Measure-Command { Move-Item .\models-a .\models-b } | Select-Object -ExpandProperty TotalMilliseconds; Test-Path .\models-a; Test-Path .\models-b
False
12.5332
False

Started again with OLLAMA_MODELS on models-b, the server listed the model and answered a prompt from a cold start without a single pulling line, because the manifests and blobs are the same files under a new path: 

PS> ollama list
NAME            ID              SIZE      MODIFIED
qwen2.5:0.5b    a8b0c5157701    397 MB    2 minutes ago
PS> ollama run qwen2.5:0.5b "Name the capital of France in one word."
Paris

The two mistakes, made on purpose

Pointing the variable at an empty folder first. Set OLLAMA_MODELS to a new folder before the files are moved there, and Ollama does not look for them anywhere else. ollama list prints only its header, and the next ollama run quietly starts downloading the model again into the empty folder: 

PS> ollama list
NAME    ID    SIZE    MODIFIED
pulling manifest
pulling c5396e06af29:  17% ▕███               ▏  66 MB/397 MB   57 MB/s      5s

That download was stopped after five seconds. It left a file named sha256-c5396e06...-partial that already had the full 397,807,936 bytes, because Ollama preallocates the file; a half-finished download looks complete in Explorer, and the -partial suffix is the only tell.

Moving the folder while the server runs. Windows did not refuse the move: nothing held the folder open, and Move-Item succeeded with the model loaded. The running server kept its old path, so it lost everything: 

PS> ollama show qwen2.5:0.5b
Error: model 'qwen2.5:0.5b' not found

The API answered the same words with HTTP 404, and the server recreated the old folder with empty manifests and manifests-v2 inside it. A plain ollama run at that point would have started the download from the first mistake. Quit first, move second, set the variable third.

Windows: the permanent setting

The tray app reads OLLAMA_MODELS from your user environment, so the steps are the ones the Ollama FAQ gives for any setting: "First Quit Ollama by clicking on it in the task bar", open Settings and search for environment variables, click on "Edit environment variables for your account", create OLLAMA_MODELS with the new folder as its value, save, and "Start the Ollama application from the Windows Start menu". The Windows page adds that "If Ollama is already running, Quit the tray application and relaunch it from the Start menu, or a new terminal started after you saved the environment variables". Terminals opened before the change keep the old environment, so open a new one before ollama list. This step was described from the documentation and not performed on the test PC, whose own variable stayed unset; what the test proved is the server half of it, above. One limit of the test: the PC has a single drive, so the move was a rename; a move to another drive copies the blobs, which takes as long as the gigabytes suggest.

Linux: the service, the override and the owner

The installer creates a user and a service, and the service's own log names the folder: 

ollama:x:999:989::/usr/share/ollama:/bin/false
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama

The documented way to set the variable is sudo systemctl edit ollama, which opens an editor on an override file. It needs a terminal: run from a script it stops with Cannot edit units if not on a tty. In the editor, under the marker line, the two lines to add are: 

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

systemctl then reports Successfully installed edited file '/etc/systemd/system/ollama.service.d/override.conf'., and sudo systemctl restart ollama brings the service up on the new folder. Writing that file by hand and running systemctl daemon-reload does the same without an editor, which is what the Linux page offers as the alternative.

The owner matters, and the test shows exactly how. The copy was made as root, so root owned every file. The service still started, listed the model and answered a prompt, because reading needs no special owner. Writing did: 

ollama cp qwen2.5:0.5b qwen2.5:copytest; echo "exit $?"
Error: open /data/ollama/models/manifests-v2/ollama.com/library/qwen2.5/.manifest-1991427715: permission denied
chown -R ollama:ollama /data/ollama/models
ollama cp qwen2.5:0.5b qwen2.5:copytest; echo "exit $?"
copied 'qwen2.5:0.5b' to 'qwen2.5:copytest'
success

No restart was needed between the chown and the working copy. The FAQ states the rule in one sentence: on Linux with the standard installer, the ollama user "needs read and write access to the specified directory". So a folder that only reads fine will fail at the next ollama pull. One more Linux detail: the manifests-v2 entries are relative symbolic links into blobs, where Windows keeps plain files, so move with mv, or copy with cp -a or rsync -a, which keep the links.

Frequently asked

Where does Ollama store models on Windows?
In C:\Users\<you>\.ollama\models, in four subfolders: blobs with the weights, manifests and manifests-v2 with one small JSON per model, and metadata. The server log's server config line and ollama show --modelfile both print the folder a running server uses.
How do I move Ollama models to another drive?
Quit Ollama, move the whole models folder, set the OLLAMA_MODELS environment variable to the new path (a user variable on Windows, an Environment line in the systemd override on Linux), then start Ollama again and check with ollama list. In the test the moved folder worked unchanged and needed no new download.
Why does ollama list show nothing after I set OLLAMA_MODELS?
The variable points at a folder that does not hold the models yet, usually because it was set before the files were moved, or the folder was moved while Ollama was running. Ollama only looks in that one folder; the next ollama run downloads the model again there. Quit Ollama, move the files into the folder the variable names, and start it again.

Installing Ollama in WSL in the first place is in How to Install Ollama on WSL and Linux, the port and OLLAMA_HOST have their own post in Ollama Default Port 11434, and a model folder that was copied badly ends in the error decoded in read GGUF metadata: offset+size exceeds file size.