Ollama Troubleshooting: Where the Logs Are, Debug Mode and the Fixes in Ollama's Official Docs

By Web Asset House Studio · October 29, 2026

Note: Some future links on this site may be affiliate links. We never claim hands-on testing; guides are researched from the public sources listed in each article.

How we wrote this: A summary of Ollama's official "Troubleshooting" and "Context length" documentation (linked below), checked October 29, 2026. Commands are adapted from those pages. Some steps need administrator (sudo) rights; only run them on a machine you manage.

When Ollama misbehaves (a model won't load, it's suddenly slow, or the GPU isn't used), Ollama's own docs say the best first move is to read the server log. This guide walks through where to find it, how to get more detail, and the specific fixes the troubleshooting page lists.

Step 1: find the server log

Where Ollama runs	How to see the log
Mac	`cat ~/.ollama/logs/server.log`
Linux (systemd)	`journalctl -u ollama --no-pager --follow --pager-end`
Docker	`docker logs <container-name>` (find the name with `docker ps`)
`ollama serve` in a terminal	The output in that terminal
Windows	Press Win+R and open `explorer %LOCALAPPDATA%\Ollama`. The newest log is `server.log`; older ones are `server-#.log`

The Windows docs also list %LOCALAPPDATA%\Programs\Ollama (the program files, which the installer adds to your PATH), %HOMEPATH%\.ollama (models and configuration) and %TEMP% (temporary files in ollama* folders). Our setup guides for Windows, Mac and Linux cover installation itself.

Step 2: turn on debug logging

Set OLLAMA_DEBUG=1 before starting the server to get more detail. On Windows, the docs say to quit Ollama from the tray menu first, then start it from PowerShell:

$env:OLLAMA_DEBUG="1"
& "ollama app.exe"

On Linux and Mac, set the variable the same way you set other Ollama variables for your install.

Step 3: is the model on the GPU, and is the context too big?

A common "it's slow" cause is a model that doesn't fit in GPU memory and spills onto the CPU. Ollama's context length page says to check the split under PROCESSOR:

ollama ps

100% GPU is what you want. The same page notes that Ollama picks a default context length based on VRAM (4k under 24 GiB, 32k from 24 to 48 GiB, 256k at 48 GiB or more), and that a larger context needs more memory. If raising the context pushed a model partly onto the CPU, lower it or choose a smaller model. Our AI model memory calculator gives a rough estimate before you download, and context length explained covers the setting itself.

Fixes the troubleshooting page lists

Force a specific LLM library

Ollama ships several builds of its inference libraries for different GPUs and CPU features and picks one automatically. The log shows the choices in a line like Dynamic LLM libraries [...]. If autodetection goes wrong or your GPU crashes, the docs describe an experimental override:

OLLAMA_LLM_LIBRARY="cpu_avx2" ollama serve

Per the docs, cpu_avx2 is fastest, then cpu_avx, and plain cpu is the slowest but most compatible (and the one that works under Rosetta on a Mac). On Linux, cat /proc/cpuinfo | grep flags | head -1 shows which CPU features you have.

Linux: /tmp mounted noexec

If the place Ollama keeps temporary executables is mounted with noexec, set OLLAMA_TMPDIR to a folder the Ollama user can write to; the docs' example is /usr/share/ollama/.

Docker: GPU works, then falls back to CPU

If a container starts on the GPU but later switches to the CPU with GPU discovery failures in the log, the docs' fix is to disable systemd cgroup management in Docker. Add "exec-opts": ["native.cgroupdriver=cgroupfs"] to /etc/docker/daemon.json on the host. See run Ollama in Docker for the container setup.

NVIDIA GPU not found (Linux)

The log may show error codes such as 3 (not initialized), 46 (device unavailable), 100 (no device) or 999 (unknown). The docs suggest, in order:

in a container, test the runtime with docker run --gpus all ubuntu nvidia-smi;
load the UVM driver (sudo nvidia-modprobe -u) or reload nvidia_uvm;
reboot, and run the latest NVIDIA driver;
for an issue report, retry with CUDA_ERROR_LEVEL=50 and check sudo dmesg | grep -i nvidia.

More on supported cards: check Ollama GPU support.

AMD GPU not found (Linux)

Access to /dev/kfd usually requires membership in the video and/or render groups; Ollama reports a permissions problem in the log.
In containers, use ls -lnd /dev/kfd /dev/dri /dev/dri/* on the host to find the numeric group IDs and pass them with --group-add.
For more detail, use AMD_LOG_LEVEL=3, OLLAMA_DEBUG=1, and sudo dmesg | grep -i amdgpu.
Driver mismatch: log lines like failure during GPU discovery ... failed to finish discovery before timeout typically mean the driver is too old. The docs say Ollama bundles ROCm 7 libraries that need a ROCm 7 kernel driver; with ROCm 6.x or earlier, discovery hangs, times out, and Ollama falls back to CPU. The fix is upgrading the driver with AMD's amdgpu-install tool, then rebooting.
Gibberish output when a model spans several AMD GPUs is a known issue; the docs point to AMD's multi-GPU notes.

Windows: strange characters in the terminal

Older Windows 10 versions (for example 21H1) can show strings like ←[?25h←[?25l or the error "The parameter is incorrect." The docs' fix is to update Windows 10.

Try another version (Linux)

The install script accepts a version number, which helps when a regression appears or you want a pre-release:

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.5.7 sh

Before you ask for help

Collect your Ollama version (ollama -v), your OS, GPU and driver version, the relevant lines of the server log with debug on, and the ollama ps output. The troubleshooting page points to Ollama's Discord for help reading logs. Remove anything private from logs before you share them.