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

Ollama na serwerze linuksowym bez monitora — dysk się zapełnia, API nieosiągalne

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

Error: write /usr/share/ollama/.ollama/models/blobs/sha256-...: no space left on device

$ curl http://server.local:11434/api/tags
curl: (7) Failed to connect to server.local port 11434: Connection refused

Który to przypadek?

Jeśli widzisz	Przyczyną jest	Przejdź do
`df -h /` pokazuje 100%, a `/usr/share/ollama` jest ogromne	Domyślny katalog modeli leży na partycji root	Rozwiązanie 2: przenieś katalog na wolumen z danymi
API odpowiada na serwerze, ale nigdzie indziej	Ollama jest przypięta do 127.0.0.1, jak domyślnie	Rozwiązanie 4: wybierz sposób udostępnienia — przeczytaj to przed bindowaniem
Przeniosłeś katalog i Ollama nie może w nim pisać	Nowa ścieżka nie należy do użytkownika usługi ollama	Rozwiązanie 2 — chown to ten krok, który ludzie pomijają
Pierwsze żądanie po przerwie zawsze jest wolne	Model został wyładowany po wygaśnięciu OLLAMA_KEEP_ALIVE	Rozwiązanie 5: dostrój keep-alive do pamięci
Równoczesni użytkownicy ustawiają się w kolejce	OLLAMA_NUM_PARALLEL domyślnie wynosi 1 żądanie na model	Rozwiązanie 6: podnieś równoległość w granicach VRAM-u

Kiedy się pojawia

Dwa problemy, które przychodzą razem w pierwszym tygodniu samodzielnego hostowania, bo mają ten sam korzeń: wartości domyślne dobrano pod laptopa, przy którym siedzisz, a serwer nie jest ani jednym, ani drugim.

Zainstalowałeś Ollamę na VPS-ie albo domowym serwerze i partycja root zapełniła się w dwa tygodnie.
Serwer ma duży wolumen z danymi, z którego katalog modeli nie korzysta.
Możesz odpytać API przez curl po SSH na samej maszynie, a nic w sieci do niego nie dosięga.
Zbierasz się do zbindowania na 0.0.0.0 i przekierowania portu, bo tak radził poradnik.
Maszynę dzieli kilka osób, a żądania ustawiają się w kolejce.

Co się właściwie dzieje

Na Linuksie katalog modeli domyślnie leży w /usr/share/ollama/.ollama/models — na partycji root, która na większości serwerowych obrazów jest najmniejszą partycją w maszynie. Modele ważą po 4–40 GB, więc garstka z nich ją zapełnia, a pełna partycja root pociąga za sobą znacznie więcej niż samą Ollamę. Osobno: Ollama domyślnie binduje się do 127.0.0.1:11434, co jest właściwym ustawieniem domyślnym i bezużytecznym na maszynie bez monitora — wszystko, co chce sięgnąć do API, jest gdzie indziej. Każda z tych rzeczy to jedna zmiana konfiguracji, a druga zasługuje na więcej namysłu, niż zwykle dostaje, bo API Ollamy nie ma żadnego uwierzytelniania.

Jak to naprawić

1. Ustal, co naprawdę zapełnia dysk

Zanim cokolwiek przeniesiesz, potwierdź, że winowajcą jest katalog modeli, a nie logi czy rozbiegany kontener, i zobacz, co ci się nazbierało. ollama list niemal zawsze ujawnia parę dużych modeli pobranych raz podczas oceniania i nieużywanych od tamtej pory. Ich usunięcie jest natychmiastowe i darmowe.

bash

# bash
df -h /
sudo du -sh /usr/share/ollama/.ollama/models
sudo du -xh / --max-depth=2 2>/dev/null | sort -rh | head -15

ollama list
ollama rm llama3.1:70b

Czy zadziałało? Zwolnione miejsce pojawia się od razu w df -h /, a ollama list nie zawiera już tego modelu.

df -h / && ollama list

2. Przenieś katalog na wolumen z danymi i oddaj go użytkownikowi ollama

Najpierw zatrzymaj usługę — działająca Ollama trzyma uchwyty do plików w katalogu. Przenieś katalog, wykonaj na nim chown na ollama:ollama (to ten krok, który ludzie pomijają, i powód, dla którego usługa potem nie może pisać), ustaw OLLAMA_MODELS przez drop-in systemd, a nie w swojej powłoce, i zrestartuj.

⚠️ Sprawdź, czy miejsce docelowe jest kompletne, zanim cokolwiek usuniesz ze źródła. Katalog jest adresowany treścią, więc częściowo przeniesiona kopia wygląda strukturalnie poprawnie i zawodzi wyłącznie na tych modelach, których bloby nie dotarły.

bash

# bash
sudo systemctl stop ollama
sudo mkdir -p /data/ollama-models
sudo rsync -a --info=progress2 /usr/share/ollama/.ollama/models/ /data/ollama-models/
sudo chown -R ollama:ollama /data/ollama-models

sudo systemctl edit ollama.service
# [Service]
# Environment="OLLAMA_MODELS=/data/ollama-models"

sudo systemctl daemon-reload && sudo systemctl start ollama
ollama list

Czy zadziałało? Wszystkie modele są nadal wypisywane, a świeże pobranie ląduje na wolumenie z danymi. Dopiero wtedy usuń stary katalog.

ollama list
ollama pull gemma3:1b
sudo du -sh /data/ollama-models
sudo ls /usr/share/ollama/.ollama/models/blobs | wc -l

3. Zajmij się szczegółami utwardzonego serwera: noexec na /tmp i proxy

Dwie rzeczy gryzą szczególnie na serwerach zbudowanych według standardu utwardzania. Jeśli /tmp jest zamontowany z noexec, Ollama nie może wykonywać kodu ze swojego katalogu tymczasowego i zawodzi w sposób wyglądający na uszkodzenie plików; OLLAMA_TMPDIR kieruje ją tam, gdzie wolno jej to robić. A za firmowym proxy zmienną, którą Ollama czyta, jest HTTPS_PROXY, a nie HTTP_PROXY — rejestr działa po HTTPS, a forma pisana małymi literami po prostu nie jest sprawdzana.

bash

# bash — is /tmp noexec?
mount | grep -E ' /tmp '

sudo mkdir -p /var/tmp/ollama && sudo chown ollama:ollama /var/tmp/ollama
sudo systemctl edit ollama.service
# [Service]
# Environment="OLLAMA_TMPDIR=/var/tmp/ollama"
# Environment="HTTPS_PROXY=http://proxy.internal:3128"

sudo systemctl daemon-reload && sudo systemctl restart ollama

Czy zadziałało? Pobranie przechodzi przez proxy, a w logu nie ma błędów o uprawnieniach do wykonywania.

ollama pull gemma3:1b && journalctl -u ollama --no-pager -n 20

4. Wybierz sposób udostępnienia API — w tej kolejności Najczęstsze rozwiązanie

OLLAMA_HOST=0.0.0.0:11434 wystawia API bez żadnego uwierzytelniania. Każdy, kto dosięgnie portu, może liczyć na twoim GPU i pobierać modele na twój dysk, a otwarty endpoint w publicznym internecie jest gorszy, niż brzmi: nieuwierzytelnione, wielogigabajtowe zapisy, nierozliczana moc obliczeniowa i żadnego śladu, kto z niej korzystał. W kolejności, w jakiej je polecamy: (1) tunel SSH — nic nie jest wystawione, działa od zaraz, a klient nadal rozmawia z localhost; (2) reverse proxy z uwierzytelnianiem i TLS-em kończonym na proxy, przy Ollamie wciąż przypiętej do pętli zwrotnej; (3) bindowanie na adres interfejsu VPN albo Tailscale zamiast 0.0.0.0, żeby dosięgła go tylko sieć prywatna; (4) 0.0.0.0 z zaporą ograniczoną do konkretnych adresów źródłowych, w sieci lokalnej, którą administrujesz — a „zaufana” znaczy, że znasz każde urządzenie w niej, a nie że stoi u ciebie w domu.

bash

# bash — (1) SSH tunnel, from the CLIENT machine
ssh -N -L 11434:127.0.0.1:11434 you@server.example.com
curl http://localhost:11434/api/tags

# (3) Bind to a Tailscale address only, never 0.0.0.0
# [Service]
# Environment="OLLAMA_HOST=100.101.102.103:11434"

Czy zadziałało? Przy tunelu klient sięga do API po własnym localhoście, a ss na serwerze wciąż pokazuje Ollamę nasłuchującą wyłącznie na 127.0.0.1.

ss -ltnp | grep 11434

Sprawdź, co zmieści się na twoim sprzęcie — dobierz modele na współdzielonym serwerze do VRAM-u, który naprawdę masz
Otwórz kalkulator VRAM →

5. Postaw z przodu reverse proxy zamiast otwierać port

Dla czegokolwiek więcej niż jedna osoba właściwym kształtem jest reverse proxy: Ollama zostaje na pętli zwrotnej, proxy trzyma certyfikat i dane uwierzytelniające, a ty dostajesz log dostępu — czego otwarty port ci nie daje. Caddy to dwie linijki. Przy okazji zachowaj domyślne OLLAMA_HOST równe 127.0.0.1: proxy łączy się lokalnie, więc nie ma żadnego powodu, by port w ogóle wystawiać.

bash

# Caddyfile — TLS and basic auth in front of a loopback-bound Ollama
# ollama.example.com {
#     basic_auth {
#         alice $2a$14$...   # caddy hash-password
#     }
#     reverse_proxy 127.0.0.1:11434
# }

# bash
sudo systemctl reload caddy
curl -u alice:secret https://ollama.example.com/api/tags

Czy zadziałało? Żądanie z danymi uwierzytelniającymi przechodzi, a bez nich zostaje odrzucone, przy czym Ollama jest wciąż przypięta do 127.0.0.1.

curl -s -o /dev/null -w "%{http_code}\n" https://ollama.example.com/api/tags
ss -ltnp | grep 11434

6. Dostrój keep-alive, równoległość i liczbę modeli do współdzielonej maszyny

Trzy wartości domyślne to wartości laptopowe. OLLAMA_KEEP_ALIVE wynosi 5 minut, więc pierwsze żądanie po ciszy płaci pełny czas ładowania — podniesienie tej wartości trzyma model ciepłym, kosztem trzymania jego VRAM-u przez cały czas, co na współdzielonej karcie jest realnym kompromisem. OLLAMA_NUM_PARALLEL wynosi 1 żądanie na model, więc równocześni użytkownicy stoją w kolejce. OLLAMA_MAX_LOADED_MODELS to trzykrotność liczby kart GPU (3 na CPU), a każdy jednocześnie załadowany model trzyma własne wagi i własny cache KV. Podnoś te wartości względem zmierzonego wolnego VRAM-u, a nie optymizmu: każde równoległe gniazdo potrzebuje własnego cache'u KV, więc podwojenie równoległości potrafi kosztować więcej pamięci niż załadowanie drugiego modelu.

bash

# bash
sudo systemctl edit ollama.service
# [Service]
# Environment="OLLAMA_KEEP_ALIVE=30m"
# Environment="OLLAMA_NUM_PARALLEL=4"
# Environment="OLLAMA_MAX_LOADED_MODELS=2"

sudo systemctl daemon-reload && sudo systemctl restart ollama
journalctl -u ollama -f

Czy zadziałało? Pod obciążeniem ollama ps nadal pokazuje umieszczenie na GPU, a nie podział, a VRAM ma zapas.

ollama ps
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

Jeśli nic z tego nie pomogło

Jeśli zmienna w ogóle nie odnosi skutku, strona o środowisku systemd wyjaśnia, dlaczego export w powłoce nigdy nie dociera do usługi. Jeśli API odrzuca połączenia, zamiast być nieosiągalne, ogólna strona diagnostyczna oddziela „nic nie nasłuchuje” od „nasłuchuje w złym miejscu”.

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

Wynik df -h / oraz sudo du -sh na katalogu modeli
systemctl show ollama --property=Environment
ss -ltnp | grep 11434 z adresem bindowania
Sposób udostępnienia API: tunel, reverse proxy, interfejs VPN czy 0.0.0.0

Powiązane

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

Zobacz model i wymagania →

Najczęstsze pytania

Gdzie Ollama trzyma modele na Linuksie?

Domyślnie w /usr/share/ollama/.ollama/models, z użytkownikiem usługi ollama jako właścicielem. Ta ścieżka leży na partycji root — dlatego kilka modeli potrafi zapełnić serwer, którego wolumen z danymi świeci pustkami.

Dlaczego Ollama nie może pisać do katalogu, do którego przeniosłem modele?

Bo usługa działa na koncie ollama, a nowa ścieżka należy do ciebie. Wykonaj sudo chown -R ollama:ollama na katalogu modeli i zrestartuj usługę. OLLAMA_MODELS ustaw w drop-inie systemd, a nie w powłoce — usługa nigdy nie widzi twojego środowiska powłoki.

Czy ustawienie OLLAMA_HOST=0.0.0.0 na serwerze jest bezpieczne?

Tylko za czymś, co uwierzytelnia. API nie ma uwierzytelniania, więc każdy, kto dosięgnie portu, może liczyć i pobierać na twój dysk wielogigabajtowe modele. Lepszy będzie tunel SSH, reverse proxy z uwierzytelnianiem albo bindowanie na adres interfejsu VPN.

Dlaczego pierwsze żądanie po przerwie jest tak wolne?

Model został wyładowany, gdy wygasło OLLAMA_KEEP_ALIVE — domyślnie po pięciu minutach — więc to żądanie płaci pełny czas ładowania. Podniesienie tej wartości trzyma model rezydentnie i ciepło, kosztem stałego zajmowania jego VRAM-u.

Jak obsłużyć kilka osób naraz?

Podnieś OLLAMA_NUM_PARALLEL powyżej domyślnej wartości 1, a OLLAMA_MAX_LOADED_MODELS, jeśli serwujesz więcej niż jeden model. Oba kosztują VRAM: każde równoległe gniazdo potrzebuje własnego cache'u KV, więc zmierz wolną pamięć przed podniesieniem, a nie po.