Działa, ale źleLinuxOstatnia aktualizacja 1 września 2026

Twoje zmienne środowiskowe Ollamy są na Linuksie ignorowane

Wyeksportowałem OLLAMA_HOST i nic się nie zmieniło

Autor Jakub Rusinowski

Błąd

$ 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 widziszPrzyczyną jestPrzejdź do
Zrobiłeś export zmiennej w powłoce i nic się nie zmieniłoUsługa systemd nigdy nie widzi środowiska twojej powłokiRozwiązanie 1: ustaw ją przez systemctl edit
ollama serve uruchomione ręcznie respektuje zmienną, a usługa nieRęczne uruchomienie dziedziczy twoją powłokę, usługa nieRozwią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ługaRozwiązanie 3: zmień właściciela katalogu
Pobierania zawodzą za firmowym proxyOllama czyta HTTPS_PROXY, a nie HTTP_PROXYRozwiązanie 4: tabela zmiennych
Zmodyfikowałeś plik jednostki, a aktualizacja cofnęła zmianęAktualizacje pakietu nadpisują /etc/systemd/system/ollama.serviceRozwią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. 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.
    bash
    systemctl show ollama --property=Environment
journalctl -u ollama --no-pager -n 20
  2. 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.
    bash
    systemctl cat ollama | tail -20
  3. 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.

    Uwaga: 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.
    bash
    ollama pull gemma3:1b
sudo ls -l /mnt/data/ollama-models/blobs | tail -3
  4. 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.
    bash
    systemctl show ollama --property=Environment | tr ' ' '\n'
  5. 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. 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 pasuje do Twojego sprzętupolicz koszt pamięciowy, zanim podniesiesz OLLAMA_CONTEXT_LENGTHOtwó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

Najczęściej zadawane 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.