Ollama Not Working? Match the Error to the Real Fix

Published April 11, 2026 · Updated November 2, 2026 · 14 min read

Quick answer: Ollama rarely fails for a vague reason — it fails with a specific string, and that string decides everything else. Confirm the binary exists with ollama --version, confirm the server answers with curl http://localhost:11434/api/tags, then find your exact error text in the index below. The most-reported failure of all, llama runner process has terminated, is not a single bug: the exit status printed after it is the real diagnosis, and people skip straight past it.

This page is an index, not a manual. Every error gets the short version here — what it means and the first thing to change — then a link to the page that takes it apart properly. If you already know your error string, go straight to the table.

---

Which Ollama error do you actually have?

The "reported" column counts open and closed issues on github.com/ollama/ollama with that phrase in the issue title, searched 22 August 2026. It is a rough measure of how often each one bites, not a severity ranking, and it drifts with every release.

---

Exact error message → fix

The strings below are the ones people paste into a search box word for word. The ones Ollama prints are quoted exactly as the current source has them (the CLI strings live in cmd/ on the main branch, read 2 November 2026); the rest come from your shell, macOS or the GPU runtime. Each has a one-line answer and the page that covers it in full.

---

Four checkpoints that narrow it down fast

If you do not have an error string yet — Ollama is just "not working" — walk these in order. Each failure points at one row of the table above.

1. Is the binary there? ollama --version. Command not found is a PATH or install problem, not an Ollama problem.

2. Is the server answering? curl http://localhost:11434/api/tags. Connection refused means nothing is listening on that address; JSON back means the server is healthy and your problem is downstream.

3. Can you pull? ollama pull llama3.2:3b. Stalls, digest mismatches and EOFs all live in the download path.

4. Can you run? ollama run llama3.2:3b "Say hello". Whatever it prints now is your error string — take it back to the table.

---

Why does Ollama say llama runner process has terminated?

Because the Go parent process launched a child (llama-server), the child died before it started answering health checks, and the parent gave up. The phrase itself carries no information; the exit status after it does, and it means three completely different things on three platforms. A Windows hex code such as 0xc0000409 is an NTSTATUS value set by the operating system, signal: aborted (core dumped) means the runner killed itself on a failed assertion, and a bare exit status 2 means nothing at all on its own.

Full breakdown of every code, signal and the stderr filter that decides whether you get a useful tail: llama runner process has terminated, decoded by exit code.

---

Why does Ollama refuse connections on port 11434?

Nine times out of ten the server is running perfectly and listening only on 127.0.0.1, so anything coming from another host, another container or a bridged Docker network gets refused before Ollama ever sees it. Setting OLLAMA_HOST=0.0.0.0:11434 fixes that case — but only if the process that reads the variable is the one you restarted, which on Linux means the systemd unit rather than your terminal.

The other causes (a second instance holding the port, a firewall, a proxy rewriting the Host header) are separated out in Ollama connection refused on port 11434. If you are exposing the server deliberately, read securing an Ollama server first — 0.0.0.0 with no auth in front of it is an open API.

---

Why does ollama serve say address already in use on 11434?

Because an Ollama server is already running and holds the port. On Linux the install script registers a systemd service that starts at boot; on macOS and Windows the desktop app starts one in the background. Typing ollama serve then starts a second server, which fails with Error: listen tcp 127.0.0.1:11434: bind: address already in use. In most cases the fix is to do nothing: the first server is working, and ollama run will talk to it.

Find out what holds the port:

# Linux
sudo ss -ltnp | grep 11434
systemctl status ollama

# macOS
lsof -i :11434

# Windows (PowerShell or cmd)
netstat -ano | findstr :11434
tasklist | findstr ollama

Then pick one of three fixes:

• Use the server that is already running. Run ollama run <model> and skip ollama serve. If you wanted ollama serve to pick up an environment variable, set it on the service instead (sudo systemctl edit ollama on Linux), as described in the systemd service fix.
• Stop the running one first. sudo systemctl stop ollama on Linux, quit Ollama from the menu bar on macOS, or quit it from the system tray on Windows. Then ollama serve can take the port.
• Run the second server on another port. OLLAMA_HOST=127.0.0.1:11435 ollama serve, and point clients at that port with the same variable. OLLAMA_HOST is the documented setting for the bind address and port.

If the process holding 11434 is not Ollama, that other program is the one to move.

---

Why does Ollama say the model requires more system memory?

Because the comparison is against available RAM, not installed RAM. Close the browser and the chat apps first; that alone often moves enough. If it does not, the model genuinely does not fit and the honest fix is a smaller one.

You can estimate before you download. A Q4_K_M quantisation lands near 0.6 GB per billion parameters, so an 8B model is roughly 8 × 0.6 ≈ 4.8 GB of weights, a 14B is ~8.4 GB, and a 70B is ~42 GB — then add the KV cache and whatever the OS is already holding. Exact per-model figures, including the VRAM split, are in the Ollama RAM and VRAM table by model size; if you are still choosing hardware, start at Ollama system requirements.

The GPU-side twin of this error, cudaMalloc failed: out of memory, is not the same failure. Nothing swaps for VRAM, so closing apps does not help — you shrink the context, drop to a smaller quantisation, or move layers to CPU.

---

Why does ollama pull stall, restart, or fail on a digest mismatch?

Because the download is resumable, and resume is the thing that breaks. A stalled bar that jumps backwards is Ollama re-requesting a chunk range; a digest mismatch means one cached blob on disk is corrupt and every retry cheerfully reuses it, which is why re-running the identical command fails identically. Deleting that one blob — not the whole model — is the fix.

Proxy variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) are read by Ollama and are the usual cause on corporate networks. The full set of download failures, including unexpected EOF, max retries exceeded and no such host, is in Ollama pull stuck or slow.

---

Why is OLLAMA_MODELS being ignored?

Because you set it somewhere the server never reads. Three different things eat it, one per platform: on Linux the daemon runs under systemd and never inherits your shell, on macOS the menu-bar app launches from launchd with its own environment, and on Windows the tray app has to be quit from the tray — not just closed — before it picks up a new user variable.

On Linux the reliable form is sudo systemctl edit ollama, adding an Environment= line under [Service], then sudo systemctl daemon-reload && sudo systemctl restart ollama. Per-platform detail, including where the models actually move to and what happens to the old blobs, is in OLLAMA_MODELS not working: fix it by platform.

---

Why does Ollama not see my GPU?

Usually the driver, and usually it is not fatal — when GPU discovery fails, Ollama logs it and falls back to CPU, so the symptom you notice is "suddenly very slow" rather than a crash. Check the log first: journalctl -u ollama --no-pager --follow --pager-end on Linux, cat ~/.ollama/logs/server.log on macOS, explorer %LOCALAPPDATA%\Ollama on Windows.

Three checks in order:

• Driver version. Ollama's own Windows requirements list NVIDIA driver 551.61 or newer, and Windows 10 22H2 or newer. On Linux, run the latest driver your distro offers.
• Group membership (AMD on Linux). Access to /dev/kfd needs video and/or render group membership — sudo usermod -aG video,render ollama, then restart the service. This is called out directly in Ollama's official troubleshooting docs, which also list the NVIDIA init error codes (3, 46, 100, 999) you may see in the log.
• WSL2. Install the Windows-side NVIDIA driver and let WSL expose it; installing a Linux NVIDIA driver package inside the distro is what usually breaks GPU passthrough. Verify with nvidia-smi inside the distro before blaming Ollama.

AMD on Linux: ROCm, the extra package, and the gfx override

AMD cards fail more quietly than NVIDIA ones, and three things cover most of it. All three come from Ollama's own GPU and Linux docs, read 2 November 2026.

• The ROCm build of Ollama has to be there. The install script handles it. A manual install does not: alongside ollama-linux-amd64.tar.zst you also extract ollama-linux-amd64-rocm.tar.zst into /usr. Without it the ROCm backend is simply not installed, and nothing in the log will say so loudly.
• The driver stack has to be ROCm v7. Ollama's docs ask for ROCm v7 on Linux, installed or upgraded with AMD's amdgpu-install utility from the ROCm install docs. That replaces the old apt-key repository recipes still found in older guides. The docs also recommend AMD's own driver over the older amdgpu in the stock kernel.
• Your card's gfx target has to be supported, or overridden. ROCm only ships kernels for certain LLVM targets (gfx1030, gfx1100-1102, gfx1150/1151, gfx1200/1201 and the Instinct parts, per the docs). For a near miss you can set HSA_OVERRIDE_GFX_VERSION on the server. Ollama's documented example is the RX 5400, which is gfx1034 and runs as HSA_OVERRIDE_GFX_VERSION="10.3.0". With mixed cards, use HSA_OVERRIDE_GFX_VERSION_0, _1 and so on.

Cards ROCm will not take at all can still run through the Vulkan backend, which Ollama enables by default when it is installed; on some distributions the ollama user also needs to be in the render group. List what the server sees with rocminfo, and limit it to some cards with ROCR_VISIBLE_DEVICES.

Using LocalAI instead of Ollama?

"LocalAI not using GPU" is a different project with a different fix. LocalAI's GPU docs ask for three things: a GPU image (for example localai/localai:latest-gpu-nvidia-cuda-12, latest-gpu-hipblas for AMD or latest-gpu-intel), the GPU passed into the container (--gpus all for NVIDIA, --device /dev/dri --device /dev/kfd for AMD), and a model YAML that offloads layers (gpu_layers plus f16: true for llama.cpp models). LocalAI picks its backend from the hardware it detects. If detection picks the CPU build, LOCALAI_FORCE_META_BACKEND_CAPABILITY=nvidia (or amd, intel) forces the GPU build.

Running more than one card, or mixing an iGPU with a dGPU? Ollama multi-GPU setup covers device selection and OLLAMA_SCHED_SPREAD. Every GPU cause with a test for each is in Ollama not using GPU.

---

Why is Ollama slow even when it runs?

Because the model is on the CPU, or partly on the CPU. When a model does not fit entirely in VRAM, Ollama splits layers between GPU and CPU and the CPU layers set the pace for the whole thing — which is why a model that "only just" fits can be slower than a smaller one that fits comfortably. Watch nvidia-smi during generation: 0% GPU utilisation means you are on the fallback path described above.

The other repeat offenders are thermal throttling on laptops and a second process holding VRAM. Ranked fixes with the diagnostic commands for each: why your local LLM is slow, 12 fixes ranked.

---

Why does failed to load model keep coming back?

Because it is a category, not a cause. In practice it is a truncated or corrupt blob from an interrupted pull, a GGUF quantisation format newer than your Ollama build, or a permissions mismatch on ~/.ollama after running the server once as root.

Take them in that order:

# 1. Re-pull the model (fixes truncated and corrupt blobs)
ollama rm llama3.2 && ollama pull llama3.2

# 2. Update Ollama (fixes unsupported quant formats)
curl -fsSL https://ollama.com/install.sh | sh     # Linux
brew upgrade ollama                                # macOS Homebrew

# 3. Fix ownership after a root run
sudo chown -R $(whoami) ~/.ollama

If it survives all three, the failure is happening inside the runner and the real message is in the log — see reading the runner exit code.

---

Why does a brand new model say unknown model architecture?

Because support for a model architecture ships in an Ollama release. If your build predates the model, no configuration, quantisation or re-pull will change the answer — the loader genuinely does not know the architecture name in the file header. This bites hardest when you import a GGUF from Hugging Face days after it appears.

Upgrade Ollama and try again; if the newest release still refuses it, the architecture has not landed yet. Ollama version history is the fastest way to see which release added what.

---

Why do I only get a 500 Internal Server Error?

Because the 500 is the HTTP wrapper your client shows you, not the failure. The Python and JavaScript SDKs, Open WebUI, n8n and LangChain all surface it the same way, which is why searching the string finds nothing useful — there is no error to search yet.

Get the real one from the server, not the client:

# Linux (systemd)
journalctl -u ollama --no-pager -n 100

# macOS
cat ~/.ollama/logs/server.log

# Docker
docker logs <container-name>

Then take the line you find back to the index at the top. Ollama's troubleshooting docs list every log location, including the Windows server-#.log rotation.

---

Why does my app get 403 Forbidden when curl works?

Because it is a CORS rejection, and curl does not send an Origin header. A browser extension, an Electron or Tauri app, or a web front-end does — and Ollama compares that origin against OLLAMA_ORIGINS before it will answer. The request never reaches the model.

Set OLLAMA_ORIGINS to the origins you actually want (a comma-separated list), restart the server process rather than the client, and remember the platform rules above about which process reads your variables. Scoping it safely, rather than pasting a wildcard, is covered in securing your Ollama server.

---

How do I change the context length without breaking the load?

Not with a command-line flag — ollama run has no --num-ctx option. There are exactly three places the value can come from: the OLLAMA_CONTEXT_LENGTH environment variable on the server, a /set parameter num_ctx 8192 line inside an interactive session, or a PARAMETER num_ctx line in a Modelfile.

# Server-wide default
OLLAMA_CONTEXT_LENGTH=8192 ollama serve

# Just this session
ollama run llama3.2
>>> /set parameter num_ctx 8192

Per Ollama's own environment reference, OLLAMA_CONTEXT_LENGTH defaults to "4k/32k/256k based on VRAM" — so raising it is what pushes a model that previously fit into an out-of-memory failure. If you need long context permanently, bake it into a Modelfile instead; see the Ollama Modelfile guide.

---

Why does the model answer with gibberish?

Three causes, in rough order of likelihood: the quantisation is too aggressive (Q2_K and the IQ1 formats trade a lot of quality for size), the model is simply too small for what you asked of it, or the file is corrupt. A 1B model producing incoherent long-form text is not broken, it is limited.

Test the base model with no custom Modelfile before you debug anything else — if the base model is coherent, your system prompt or template is the problem, not the weights.

---

Why is the ollama command not found after installing?

The error reads zsh: command not found: ollama or bash: ollama: command not found on macOS and Linux, and 'ollama' is not recognized as an internal or external command on Windows. Usually the shell you are typing into was opened before the installer edited PATH. Close every terminal window — on Windows Terminal, the whole app, not just the tab — and open a fresh one. If it still fails: on macOS the direct-download .app puts the binary inside the bundle, so symlink it with sudo ln -sf /Applications/Ollama.app/Contents/Resources/ollama /usr/local/bin/ollama; on Windows, re-run the installer from ollama.com/download/windows and check Defender's quarantine list before assuming it failed.

Platform walkthroughs: Ollama on Windows and Mac local AI setup. If this is your first install, 15 first-time Ollama setup mistakes will save you the next four errors on this page.

---

Which environment variables does Ollama actually read?

These are the ones the server itself reports, taken from envconfig/config.go — the same list ollama serve --help prints. Names that are not on this list (there are several circulating, including an "OLLAMA_METAL") are not read by Ollama at all.

Two things trip people up here. OLLAMA_KV_CACHE_TYPE defaults to f16; setting it to q8_0 halves the bytes per cached token, which is the cheapest way to buy back memory when a long context will not fit. And every one of these is read by the server process — exporting them next to an ollama run call changes nothing on a machine where ollama serve is managed by systemd or a desktop app.

---

How do I reset Ollama completely?

Stop the server, delete the data directory, reinstall. This removes every downloaded model, so budget the bandwidth before you start.

# 1. Stop
pkill -f ollama                # Linux/macOS
taskkill /F /IM ollama.exe     # Windows

# 2. Remove data
rm -rf ~/.ollama               # Linux/macOS
# Windows: delete %LOCALAPPDATA%\Ollama and %USERPROFILE%\.ollama

# 3. Reinstall
curl -fsSL https://ollama.com/install.sh | sh   # Linux
brew install ollama                              # macOS
# Windows: installer from ollama.com/download/windows

# 4. Verify
ollama --version && ollama run llama3.2:3b "Hello"

Moving models to a bigger drive instead of deleting them? Do not copy the directory by hand — set OLLAMA_MODELS properly, as described in OLLAMA_MODELS not working.

Uninstalling Ollama on Linux

sudo apt remove ollama does nothing useful, because the install script does not install a .deb package. On a Linux install made with the script, the models also do not live in your home directory: the service runs as the ollama user, whose home is /usr/share/ollama. The removal steps from Ollama's Linux docs:

# Remove the service
sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm /etc/systemd/system/ollama.service

# Remove the libraries, then the binary
sudo rm -r $(which ollama | tr 'bin' 'lib')
sudo rm $(which ollama)

# Remove downloaded models and the service user and group
sudo userdel ollama
sudo groupdel ollama
sudo rm -r /usr/share/ollama

---

What if none of these match?

Collect the evidence before you post. Run OLLAMA_DEBUG=1 ollama serve in a terminal so the log lands in front of you, reproduce the failure, and copy the last error line the runner printed — not the HTTP status your client showed. Then search github.com/ollama/ollama/issues for that literal string, including any assertion text in parentheses.

A bug report that names your OS, ollama --version, the GPU and driver version, and that one log line gets answered. One that says "Ollama is not working" does not.

New to all of this? The complete Ollama guide starts from a clean machine and never reaches most of the errors above.