Start / Poradniki / Rozwiązywanie problemów / Linux

Twoje zmienne środowiskowe Ollamy są na Linuksie ignorowane

Linux

Autor: Jakub Rusinowski · Ostatnia aktualizacja: 1 września 2026

Edukator AI i prowadzący warsztaty z wdrażania lokalnych modeli LLM

Komunikat błędu

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

Który to przypadek?

Jeśli widzisz	Przyczyną jest	Przejdź do
Zrobiłeś `export` zmiennej w powłoce i nic się nie zmieniło	Usługa systemd nigdy nie widzi środowiska twojej powłoki	Rozwiązanie 1: ustaw ją przez systemctl edit
`ollama serve` uruchomione ręcznie respektuje zmienną, a usługa nie	Ręczne uruchomienie dziedziczy twoją powłokę, usługa nie	Rozwiązanie 1 — na tym kontraście polega całe nieporozumienie
Ustawiłeś OLLAMA_MODELS, a Ollama nie może tam pisać	Ścieżka nie należy do użytkownika, na którym działa usługa	Rozwiązanie 3: zmień właściciela katalogu
Pobierania zawodzą za firmowym proxy	Ollama czyta HTTPS_PROXY, a nie HTTP_PROXY	Rozwiązanie 4: tabela zmiennych
Zmodyfikowałeś plik jednostki, a aktualizacja cofnęła zmianę	Aktualizacje pakietu nadpisują /etc/systemd/system/ollama.service	Rozwiązanie 2: używaj drop-inu, nigdy nie edytuj jednostki

Kiedy się pojawia

Ustawiłeś zmienną dokładnie tak, jak opisywała dokumentacja dla innej platformy, zrestartowałeś — a Ollama działa dalej, jakbyś nic nie zrobił. Nie ma żadnego błędu, bo z jej punktu widzenia nic nie zostało skonfigurowane.

Poszedłeś za instrukcją dla macOS albo Windowsa i wyeksportowałeś zmienną w bashu lub zsh.
Dodałeś ją do .bashrc albo .profile i zrestartowałeś komputer, bez żadnego efektu.
Działa, gdy sam uruchamiasz ollama serve, i przestaje po systemctl restart ollama.
Przeniosłeś katalog modeli, a Ollama nie może pisać w nowej lokalizacji.
Jesteś za proxy, a pobierania wygasają mimo ustawionego http_proxy.

Co się właściwie dzieje

Na Linuksie instalator konfiguruje Ollamę jako usługę systemd działającą na własnym koncie ollama, uruchamianą przez system init przy starcie maszyny. Usługa systemd nie dziedziczy środowiska twojej powłoki logowania — dostaje to, co da jej plik jednostki, i nic więcej. Zatem export OLLAMA_HOST=... konfiguruje powłokę, w której to wpisałeś, a usługa — inny proces, na innym koncie, uruchomiony jeszcze przed twoim zalogowaniem — nigdy tego nie zobaczy. To wyjaśnia również szczegół, przez który ludzie zaczynają nie wierzyć własnym oczom: ollama serve wpisane w twoim terminalu owszem czyta środowisko twojej powłoki, bo ten proces naprawdę jest jej dzieckiem. Ten sam plik binarny, ta sama zmienna, dwie różne odpowiedzi zależnie od tego, kto go uruchomił.

Jak to naprawić

1. Ustaw zmienną na usłudze przez systemctl edit

systemctl edit ollama.service otwiera w twoim edytorze nadpisanie w formie drop-inu. Dodaj zmienne w sekcji [Service], zapisz, przeładuj demona i zrestartuj usługę. To udokumentowany mechanizm i przeżywa aktualizacje pakietu, bo drop-in leży w pliku osobnym od samej jednostki.

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

Czy zadziałało? systemd wypisuje zmienne, które faktycznie przekaże procesowi. Jeśli twojej wartości w tym wyjściu nie ma, usługa jej nie dostaje — i nic dalej nie zadziała.

systemctl show ollama --property=Environment
journalctl -u ollama --no-pager -n 20

2. Używaj drop-inu, nigdy nie edytuj pliku jednostki bezpośrednio

Kusi, żeby otworzyć /etc/systemd/system/ollama.service i dopisać tam linię. Nie rób tego: aktualizacja pakietu podmienia ten plik, a twoja konfiguracja znika w najmniej dogodnym momencie — zwykle kilka tygodni później, gdy nikt już nie kojarzy obu zdarzeń. systemctl edit zapisuje do /etc/systemd/system/ollama.service.d/override.conf, którego aktualizacje nie ruszają. Ten plik możesz podejrzeć i trzymać w systemie kontroli wersji.

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

Czy zadziałało? systemctl cat ollama pokazuje twoje nadpisanie wypisane po jednostce bazowej — i to właśnie sprawia, że wygrywa.

systemctl cat ollama | tail -20

3. Oddaj użytkownikowi ollama na własność każdą ścieżkę, którą jej wskazujesz

OLLAMA_MODELS to zmienna, przy której ludzie najczęściej wpadają w kłopoty z uprawnieniami. Domyślna wartość na Linuksie to /usr/share/ollama/.ollama/models, należąca do użytkownika usługi. Wskaż usłudze katalog należący do twojego konta, a nie będzie mogła tam pisać — usługa to nie ty. Utwórz katalog, przekaż go na ollama:ollama i dopiero wtedy zrestartuj.

⚠️ Uruchamiaj chown wyłącznie na katalogu modeli. Rekurencyjny chown wycelowany o poziom za wysoko — w /mnt albo w cały wolumen z danymi — oddaje usłudze niepowiązane pliki i jest żmudny do cofnięcia.

bash

# bash
sudo mkdir -p /mnt/data/ollama-models
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl restart ollama
ollama list

Czy zadziałało? Pobranie kończy się powodzeniem, a bloby lądują w nowym katalogu, a nie w domyślnym.

ollama pull gemma3:1b
sudo ls -l /mnt/data/ollama-models/blobs | tail -3

4. Poznaj istniejące zmienne i ich wartości domyślne

Większość zgłoszeń „Ollama ignoruje moją konfigurację” to któraś z nich, ustawiona w złym miejscu. OLLAMA_HOST (domyślnie 127.0.0.1:11434) to adres bindowania. OLLAMA_MODELS (domyślnie /usr/share/ollama/.ollama/models na Linuksie) to katalog modeli. OLLAMA_CONTEXT_LENGTH domyślnie wynosi 4096 — dlatego długie rozmowy urywają się na maszynie z zapasem pamięci. OLLAMA_KEEP_ALIVE domyślnie trzyma model 5 minut przed wyładowaniem. OLLAMA_MAX_LOADED_MODELS domyślnie równa się trzykrotności liczby kart GPU (albo 3 na CPU), a OLLAMA_NUM_PARALLEL — 1 żądaniu na model. OLLAMA_DEBUG włącza szczegółowe logowanie, OLLAMA_VULKAN=0 wyłącza backend Vulkan, a OLLAMA_TMPDIR ma znaczenie na utwardzonych serwerach, gdzie /tmp jest zamontowany z noexec — to realny tryb awarii, bo Ollama musi wykonywać kod ze swojego katalogu tymczasowego. Dla proxy właściwą zmienną jest HTTPS_PROXY, a nie HTTP_PROXY: rejestr modeli działa po HTTPS, a forma pisana małymi literami po prostu nie jest odczytywana.

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"

Czy zadziałało? Każda ustawiona przez ciebie zmienna pojawia się we właściwości Environment. Cokolwiek brakuje, zostało źle wpisane albo leży w niewłaściwym pliku.

systemctl show ollama --property=Environment | tr ' ' '\n'

5. Porównaj z dwoma pozostałymi platformami, zanim skopiujesz instrukcję

Czytelnicy trafiają tu po instrukcjach dla innego systemu, a te trzy naprawdę się różnią. Linux: systemctl edit ollama.service, drop-in, potem daemon-reload i restart. macOS: launchctl setenv OLLAMA_HOST "0.0.0.0:11434", a następnie zamknięcie i ponowne otwarcie aplikacji Ollama. Windows: Ustawienia → zmienne środowiskowe dla twojego konta, potem zamknięcie z zasobnika i ponowne uruchomienie. Każdy sposób jest udokumentowany, żaden się nie przenosi, a wszystkie trzy mają jeden wspólny wymóg — aplikację trzeba w pełni zrestartować, a nie tylko zamknąć.

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. Ustaw długość kontekstu świadomie, zamiast ją odkrywać Najczęstsze rozwiązanie

OLLAMA_CONTEXT_LENGTH zasługuje na osobną chwilę, bo jej wartość domyślna 4096 jest cichą przyczyną wielu skarg w stylu „model zapomniał, co powiedziałem”. Podniesienie jej jest darmowe w konfiguracji i kosztowne w pamięci: cache KV rośnie wraz z kontekstem, a na karcie i tak już bliskiej pełna, podwojenie okna jest właśnie tym, co przechyla cię w offload. Policz koszt pamięciowy dla swojego modelu i karty, zanim ją podniesiesz — zamiast podnosić ją i dziwić się, że przepustowość się załamała.

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

Sprawdź, co zmieści się na twoim sprzęcie — policz koszt pamięciowy, zanim podniesiesz OLLAMA_CONTEXT_LENGTH
Otwórz kalkulator VRAM →

Jeśli nic z tego nie pomogło

Jeśli zmienne już docierają, a API nadal jest nieosiągalne z innej maszyny, bindowanie to tylko połowa historii — drugą jest zapora. Jeśli konfigurujesz serwer, a nie stację roboczą, poradnik o pracy bez monitora omawia stronę operacyjną: zapełniający się dysk, utrzymywanie modeli w pamięci i bezpieczne udostępnianie API.

Dołącz to, zgłaszając problem

Wynik systemctl show ollama --property=Environment
Wynik systemctl cat ollama razem z każdym drop-inem
Ostatnie 30 linii z journalctl -u ollama --no-pager
Czy ustawiłeś zmienną w powłoce, w pliku jednostki, czy w drop-inie

Powiązane

Model, który mieści się na większości zestawów:

Zobacz model i wymagania →

Najczęstsze pytania

Dlaczego wyeksportowanie zmiennej w powłoce nie wpływa na Ollamę?

Bo na Linuksie Ollama działa jako usługa systemd na własnym koncie, uruchomiona jeszcze przed twoim zalogowaniem. Usługi nie dziedziczą środowiska powłoki logowania. Twój export konfiguruje twoją powłokę; usługa czyta wyłącznie to, co dają jej plik jednostki i drop-iny.

Dlaczego „ollama serve” respektuje moje zmienne, a usługa nie?

Bo tamten proces jest dzieckiem twojej powłoki i dziedziczy jej środowisko, a usługa nie. Ten sam plik binarny, dwa różne środowiska. Nazwanie tej różnicy zwykle rozwiewa nieporozumienie szybciej niż jakiekolwiek polecenie.

Czy edytować /etc/systemd/system/ollama.service bezpośrednio?

Nie. Aktualizacje pakietu podmieniają ten plik, a twoje ustawienia znikają bez ostrzeżenia. Użyj systemctl edit ollama.service, co zapisuje drop-in w katalogu ollama.service.d/, którego aktualizacje nie ruszają. systemctl cat ollama pokazuje scalony wynik.

Dlaczego Ollama nie może pisać do mojego nowego katalogu OLLAMA_MODELS?

Bo usługa działa na koncie ollama, a katalog należy do ciebie. Utwórz go i wykonaj sudo chown -R ollama:ollama na tej ścieżce, potem zrestartuj usługę. Zachowaj chown ograniczony do samego katalogu modeli.

HTTP_PROXY jest ustawione, a pobierania dalej zawodzą. Dlaczego?

Ollama czyta HTTPS_PROXY, a nie HTTP_PROXY, bo rejestr modeli działa po HTTPS. Ustaw HTTPS_PROXY w drop-inie usługi. Za proxy inspekcjonującym TLS potrzebujesz jeszcze jego certyfikatu zainstalowanego jako certyfikat systemowy.