Your Ollama environment variables are ignored on Linux

Linux

作者： Jakub Rusinowski · 最后更新： 2026年9月1日

AI 教育者、本地 LLM 部署工作坊讲师

The error

$ export OLLAMA_MODELS=/mnt/data/models
$ ollama pull llama3.1:8b
# ... still writes to /usr/share/ollama/.ollama/models

你遇到的是哪一种？

如果你看到	原因是	前往
You `export`ed 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

When you see it

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 .bashrc or .profile and rebooted, with no effect.
It works when you run ollama serve yourself and stops working after systemctl 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_proxy being set.

What's actually going on

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.

How to fix it

1. Set the variable on the service with systemctl edit

systemctl edit ollama.service opens 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

# 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.service and 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 edit writes to /etc/systemd/system/ollama.service.d/override.conf, which upgrades leave alone. You can inspect and version-control that file directly.

bash

# 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 ollama shows 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_MODELS is 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 to ollama: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

# 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 (default 127.0.0.1:11434) is the bind address. OLLAMA_MODELS (default /usr/share/ollama/.ollama/models on Linux) is the store. OLLAMA_CONTEXT_LENGTH defaults to 4096, which is why long conversations truncate on a machine with memory to spare. OLLAMA_KEEP_ALIVE defaults to 5m before a model unloads. OLLAMA_MAX_LOADED_MODELS defaults to 3× your GPU count, or 3 on CPU, and OLLAMA_NUM_PARALLEL to 1 request per model. OLLAMA_DEBUG turns on verbose logging, OLLAMA_VULKAN=0 disables the Vulkan backend, and OLLAMA_TMPDIR matters on hardened servers where /tmp is mounted noexec — a real failure mode, since Ollama needs to execute from its temporary directory. For proxies the variable is HTTPS_PROXY, not HTTP_PROXY; the model registry is HTTPS and the lowercase HTTP form is simply not read.

bash

# 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, then daemon-reload and restart. 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.

multiple shells — see comments

# 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 Most common fix

OLLAMA_CONTEXT_LENGTH deserves 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

# 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

Check what fits your hardware — work out the memory cost before you raise OLLAMA_CONTEXT_LENGTH
Open the VRAM checker →

如果以上都没用

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.

上报问题时请附上这些信息

Output of systemctl show ollama --property=Environment
Output of systemctl cat ollama including 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

Frequently asked questions

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.