Your Ollama environment variables are ignored on Linux
I exported OLLAMA_HOST and nothing changed
错误信息
$ export OLLAMA_MODELS=/mnt/data/models $ ollama pull llama3.1:8b # ... still writes to /usr/share/ollama/.ollama/models
| 如果你看到 | 原因是 | 前往 |
|---|---|---|
You exported the variable in your shell and nothing changed | The systemd service never sees your shell environment | Fix 1: set it with systemctl edit |
ollama serve run by hand honours it, the service does not | The manual run inherits your shell; the service does not | Fix 1 — this contrast is the whole confusion |
| You set OLLAMA_MODELS and Ollama cannot write there | The path is not owned by the ollama service user | Fix 3: chown the directory |
| Pulls fail behind a corporate proxy | HTTPS_PROXY is the variable Ollama reads, not HTTP_PROXY | Fix 4: the variable table |
| You edited the unit file and an upgrade reverted it | Package upgrades overwrite /etc/systemd/system/ollama.service | Fix 2: use a drop-in, never edit the unit |
何时出现
You set the variable exactly as the documentation for another platform described, restarted, and Ollama carried on as if you had done nothing. There is no error because, from Ollama's point of view, nothing was configured.
- You followed macOS or Windows instructions and exported the variable in bash or zsh.
- You added it to
.bashrcor.profileand rebooted, with no effect. - It works when you run
ollama serveyourself and stops working aftersystemctl restart ollama. - You moved the model directory and Ollama cannot write to the new location.
- You are behind a proxy and pulls time out despite
http_proxybeing set.
实际原因
On Linux the installer sets Ollama up as a systemd service running as its own ollama user, started by the init system at boot. A systemd service does not inherit your login shell's environment — it gets whatever the unit file gives it and nothing else. So export OLLAMA_HOST=... configures the shell you typed it into, and the service, which is a different process owned by a different user started before you logged in, never sees it. This also explains the detail that makes people doubt their own eyes: ollama serve typed into your terminal does read your shell environment, because that process really is your child. Same binary, same variable, two different answers depending on who started it.
如何修复
- 1
Set the variable on the service with systemctl edit
systemctl edit ollama.serviceopens a drop-in override in your editor. Add the variables under a[Service]section, save, reload the daemon and restart. This is the documented mechanism and it survives package upgrades, because the drop-in lives in a separate file from the unit itself.# bash sudo systemctl edit ollama.service # Add, between the marked lines: # [Service] # Environment="OLLAMA_HOST=0.0.0.0:11434" # Environment="OLLAMA_MODELS=/mnt/data/ollama-models" sudo systemctl daemon-reload sudo systemctl restart ollama生效了吗?systemd reports the variables it will actually pass to the process. If your value is not in this output, the service is not getting it — nothing downstream will work.systemctl show ollama --property=Environment journalctl -u ollama --no-pager -n 20 - 2
Use a drop-in, never edit the unit file directly
It is tempting to open
/etc/systemd/system/ollama.serviceand add the line there. Do not: a package upgrade replaces that file and your configuration disappears at the least convenient moment, usually weeks later when nobody connects the two events.systemctl editwrites to/etc/systemd/system/ollama.service.d/override.conf, which upgrades leave alone. You can inspect and version-control that file directly.# bash — where the override actually lives sudo cat /etc/systemd/system/ollama.service.d/override.conf systemctl cat ollama # unit + every drop-in, in load order生效了吗?systemctl cat ollamashows your override listed after the base unit, which is what makes it win.systemctl cat ollama | tail -20 - 3
Give the ollama user ownership of any path you point it at
OLLAMA_MODELSis the variable people hit permission trouble with. The default on Linux is/usr/share/ollama/.ollama/models, owned by the service user. Point the service at a directory your own account owns and it cannot write there — the service is not you. Create the directory, hand it toollama:ollama, and only then restart.注意:Run chown against the model directory only. A recursive chown aimed a level too high — at /mnt or a whole data volume — hands unrelated files to the service user and is tedious to undo.# bash sudo mkdir -p /mnt/data/ollama-models sudo chown -R ollama:ollama /mnt/data/ollama-models sudo systemctl restart ollama ollama list生效了吗?A pull completes and the blobs land in the new directory rather than the default one.ollama pull gemma3:1b sudo ls -l /mnt/data/ollama-models/blobs | tail -3 - 4
Know which variables exist and what they default to
Most "Ollama ignores my config" reports are one of these set in the wrong place.
OLLAMA_HOST(default127.0.0.1:11434) is the bind address.OLLAMA_MODELS(default/usr/share/ollama/.ollama/modelson Linux) is the store.OLLAMA_CONTEXT_LENGTHdefaults to 4096, which is why long conversations truncate on a machine with memory to spare.OLLAMA_KEEP_ALIVEdefaults to 5m before a model unloads.OLLAMA_MAX_LOADED_MODELSdefaults to 3× your GPU count, or 3 on CPU, andOLLAMA_NUM_PARALLELto 1 request per model.OLLAMA_DEBUGturns on verbose logging,OLLAMA_VULKAN=0disables the Vulkan backend, andOLLAMA_TMPDIRmatters on hardened servers where/tmpis mountednoexec— a real failure mode, since Ollama needs to execute from its temporary directory. For proxies the variable isHTTPS_PROXY, notHTTP_PROXY; the model registry is HTTPS and the lowercase HTTP form is simply not read.# bash — a typical server drop-in sudo systemctl edit ollama.service # [Service] # Environment="OLLAMA_HOST=0.0.0.0:11434" # Environment="OLLAMA_CONTEXT_LENGTH=8192" # Environment="OLLAMA_KEEP_ALIVE=30m" # Environment="OLLAMA_NUM_PARALLEL=2" # Environment="HTTPS_PROXY=http://proxy.internal:3128" # Environment="OLLAMA_TMPDIR=/var/tmp/ollama"生效了吗?Every variable you set appears in the Environment property. Anything missing was mistyped or is in the wrong file.systemctl show ollama --property=Environment | tr ' ' '\n' - 5
Compare against the other two platforms before copying instructions
Readers arrive here having followed instructions for a different operating system, and the three genuinely differ. Linux:
systemctl edit ollama.service, a drop-in, thendaemon-reloadandrestart. macOS:launchctl setenv OLLAMA_HOST "0.0.0.0:11434", then quit and reopen the Ollama app. Windows: Settings → environment variables for your account, then quit from the system tray and relaunch. Each is documented, none transfers, and all three share one requirement — the application must be fully restarted, not merely closed.# macOS (zsh) — for reference; does not apply on Linux launchctl setenv OLLAMA_HOST "0.0.0.0:11434" # then quit and reopen the Ollama app # Windows (PowerShell) — for reference # [Environment]::SetEnvironmentVariable("OLLAMA_HOST", "0.0.0.0:11434", "User") # then quit Ollama from the system tray and relaunch - 6
Set the context length deliberately rather than discovering it最常见的修复方法
OLLAMA_CONTEXT_LENGTHdeserves a moment on its own because its default of 4096 is the quiet cause of a lot of "the model forgot what I said". Raising it is free in configuration and expensive in memory: the KV cache grows with context, and on a card that was already close to full, doubling the window is what tips you into offload. Work out the memory cost for your model and card before you raise it, rather than raising it and wondering why throughput collapsed.# bash — what is the service actually using? systemctl show ollama --property=Environment | grep -o 'OLLAMA_CONTEXT_LENGTH=[0-9]*' ollama ps # Processor column shows whether you are still fully on the GPU检查哪些模型适配你的硬件work out the memory cost before you raise OLLAMA_CONTEXT_LENGTH打开显存检查器 →
如果以上都没用
If the variables are landing and the API still is not reachable from another machine, binding is only half the story and the firewall is the other half. If you are configuring a server rather than a workstation, the headless guide covers the operational pieces — the disk filling, keeping models warm, and exposing the API safely.
- Ollama on a headless Linux server — disk and remote access
- Can't reach Ollama from another device — Windows Firewall
- Ollama "connection refused" — the full triage
- Output of
systemctl show ollama --property=Environment - Output of
systemctl cat ollamaincluding every drop-in - The last 30 lines of
journalctl -u ollama --no-pager - Whether you set the variable in your shell, in the unit file, or in a drop-in
相关内容
常见问题
Why does exporting a variable in my shell not affect Ollama?
Because on Linux Ollama runs as a systemd service under its own user, started before you logged in. Services do not inherit a login shell's environment. Your export configures your shell; the service reads only what its unit file and drop-ins provide.
Why does "ollama serve" honour my variables but the service does not?
Because that process is a child of your shell and inherits its environment, while the service is not. Same binary, two different environments. Naming that difference usually resolves the confusion faster than any command.
Should I edit /etc/systemd/system/ollama.service directly?
No. Package upgrades replace that file and your settings vanish without warning. Use systemctl edit ollama.service, which writes a drop-in under ollama.service.d/ that upgrades leave alone. systemctl cat ollama shows the merged result.
Why can Ollama not write to my new OLLAMA_MODELS directory?
Because the service runs as the ollama user and the directory is owned by you. Create it and sudo chown -R ollama:ollama the path, then restart the service. Keep the chown scoped to the model directory itself.
HTTP_PROXY is set and pulls still fail. Why?
Ollama reads HTTPS_PROXY, not HTTP_PROXY, because the model registry is served over HTTPS. Set HTTPS_PROXY in the service drop-in. Behind a TLS-inspecting proxy you also need its certificate installed as a system certificate.