Windows
作者： Jakub Rusinowski · 最后更新： 2026年9月1日
AI 教育者、本地 LLM 部署工作坊讲师
Error: write /Users/you/.ollama/models/blobs/sha256-...: There is not enough space on the disk.| 如果你看到 | 原因是 | 前往 |
|---|---|---|
C: is nearly full and .ollama\models is tens of gigabytes | The default store lives in your user profile on the system drive | Fix 2: move the store and set OLLAMA_MODELS |
| You set OLLAMA_MODELS and nothing changed | Ollama was not fully restarted, so it still holds the old value | Fix 3: quit from the system tray, not the window |
| You uninstalled Ollama and got no space back | The uninstaller does not delete a custom model directory | Fix 5: delete the store yourself |
| The same model appears to be on disk twice | Ollama and LM Studio keep separate stores and do not share | Fix 4: pick one store, or accept the duplication knowingly |
| Ollama itself, not the models, is several gigabytes on C: | The application installs into your profile by default | Fix 6: reinstall with OllamaSetup.exe /DIR |
Model files are the largest thing most people ever download deliberately. A single 70B at Q4 is around 40 GB; four or five mid-sized models will clear 100 GB without feeling like much. On a laptop with a 256 or 512 GB system drive that is the whole free-space budget, and Windows starts complaining about C: long before you connect it to the models you pulled last month.
Ollama on Windows stores models under C:\Users\%username%\.ollama\models — the docs also write this as %HOMEPATH%\.ollama. That is a per-user location on the system drive, chosen because it needs no Administrator rights, and it is not something the installer offers to change. The store is content-addressed: blobs sit in models\blobs named by digest, with small manifest files pointing at them, which is why the directory is opaque and why you must move it whole rather than picking files out of it. The application itself is separate again, roughly 4 GB in %LOCALAPPDATA%\Programs\Ollama. LM Studio keeps its own directory with its own copies and knows nothing about Ollama's, so running both means paying for the same weights twice.
Before moving anything, check the size of the store and what is in it. ollama list shows every model you have pulled with its size — most people find two or three they downloaded once and forgot. Removing those is faster than moving 200 GB to another drive, and it is free.
# PowerShell — how big is the store, and what is in it?
"{0:N1} GB" -f ((Get-ChildItem "$env:USERPROFILE\.ollama\models" -Recurse -File |
Measure-Object Length -Sum).Sum / 1GB)
ollama list
# Remove one you no longer use
ollama rm llama3.1:70bollama list reported for the model you removed.ollama listMove the directory first, then point Ollama at it — doing it the other way round leaves Ollama looking at an empty folder and re-downloading everything. Quit Ollama completely from the system tray before you start; a running process holds file handles inside the store and the move will fail or, worse, half-succeed.
⚠️ Use Move-Item, not a copy-then-delete you finish by hand. If the move is interrupted, verify the destination has everything before deleting anything from the source — a half-moved content-addressed store looks fine and fails on the models whose blobs did not make it.
# PowerShell — quit Ollama from the system tray FIRST
Move-Item "$env:USERPROFILE\.ollama\models" "D:\ollama-models"
# Point Ollama at the new location (persists for your account)
[Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\ollama-models", "User")ollama listThis is where most attempts fail. Ollama reads OLLAMA_MODELS when the application starts, and closing its window leaves the tray process running with the old value. Right-click the tray icon and choose Quit, then start it again from the Start menu. Setting the variable through Settings → Edit environment variables for your account has the same requirement: existing processes never see it.
# PowerShell — confirm the value that will actually be read
[Environment]::GetEnvironmentVariable("OLLAMA_MODELS", "User")
# Confirm nothing is still running before you relaunch
Get-Process ollama*, "ollama app" -ErrorAction SilentlyContinueollama list shows your models and a fresh ollama pull writes into the new drive rather than C:.ollama pull gemma3:1b
Get-ChildItem "D:\ollama-models\blobs" | Select-Object -Last 3LM Studio has its own models directory, configurable in the app under My Models, and the two applications do not share a store. If you have pulled llama3.1:8b in Ollama and downloaded the same weights in LM Studio, you are holding both. There is no supported way to point one at the other's store — the layouts are different, Ollama's being content-addressed by digest and LM Studio's a normal folder tree of .gguf files. The realistic options are to pick one tool for a given model, or to keep both knowingly.
# PowerShell — what each store costs you
"{0:N1} GB Ollama" -f ((Get-ChildItem "$env:USERPROFILE\.ollama\models" -Recurse -File -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum/1GB)
"{0:N1} GB LM Studio" -f ((Get-ChildItem "$env:USERPROFILE\.lmstudio\models" -Recurse -File -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum/1GB)Ollama's own documentation is explicit: if you have changed OLLAMA_MODELS, the installer will not remove your downloaded models when you uninstall through Add or remove programs. People uninstall expecting 200 GB back, get a few, and conclude the numbers were wrong. If you are removing Ollama for good, delete the model directory yourself afterwards.
⚠️ This permanently deletes every model you have pulled, and they are multi-gigabyte re-downloads. Run ollama list and note anything you want back before you do it.
# PowerShell — after uninstalling, and only if you want the models gone
Remove-Item "D:\ollama-models" -Recurse -ForceMoving 200 GB to another drive is worth doing once. Downloading 200 GB you cannot run is worth stopping. Most of the space on a full drive is models too large for the machine's VRAM, kept in the hope they will be usable. Check what your card can actually run before the next pull, and the disk problem stops recurring. If it is the application rather than the models eating C:, OllamaSetup.exe /DIR="d:\some\location" installs it elsewhere at install time.
# PowerShell — install the app itself on another drive
.\OllamaSetup.exe /DIR="d:\Ollama"If the store is on a roomy drive and pulls still fail, the failure is in the download rather than the destination. If Ollama cannot find its models after the move, the environment variable is the thing to check — the same reading applies to every other Ollama setting on Windows.
上报问题时请附上这些信息
[Environment]::GetEnvironmentVariable("OLLAMA_MODELS", "User")ollama list before and after the moveGet-PSDrive C, D)C:\Users\%username%\.ollama\models by default, which the documentation also writes as %HOMEPATH%\.ollama. The store is content-addressed, so blobs are named by digest rather than by model, and it must be moved as a whole directory.
Almost always because Ollama was not fully restarted. It reads the variable at application start, and closing the window leaves the tray process running with the old value. Quit from the system tray, then relaunch from the Start menu.
It generally works, but OLLAMA_MODELS is the supported mechanism and should be your first choice. A junction adds a layer that survives no upgrade guarantees and confuses backup tools. Keep it as a fallback for cases where you cannot set the variable at all.
No. Each keeps its own directory in its own layout, so the same model downloaded in both costs disk space twice. There is no supported way to point one at the other. Pick one tool per model, or budget for the duplication deliberately.
Because the uninstaller does not remove a custom model directory — Ollama documents this explicitly. Delete the directory yourself after uninstalling. Note that this is permanent and every model is a multi-gigabyte re-download.