Ollama w rootless Podman na VPS: konfiguracja krok po

Uruchamianie Ollama w bezkorzeniowym Podman na VPS

Aby uruchomić Ollama w bezkorzeniowym (rootless) Podman na serwerze, należy spełnić pięć warunków, które w poradnikach dla komputerów stacjonarnych są często pomijane. Kontener musi należeć do dedykowanego użytkownika bez uprawnień roota. Dla tego użytkownika musi być włączona funkcja lingering, aby kontener działał po wylogowaniu. Plik Quadlet przekazuje zarządzanie kontenerem do systemd, co zapewnia jego restart po ponownym uruchomieniu serwera. Katalog z modelami musi posiadać odpowiednią etykietę SELinux w dystrybucjach, które wymuszają to zabezpieczenie. API powinno nasłuchiwać wyłącznie na interfejsie loopback, a dostęp do niego należy realizować przez tunel SSH (secure shell).

Ollama to serwer dla dużych modeli językowych (LLM). Przechowuje on wagi modeli na dysku, ładuje je do pamięci i odpowiada na żądania HTTP na porcie 11434. Usługa nie posiada mechanizmu logowania, kluczy API ani kont użytkowników, więc sieć stanowi jedyną formę kontroli dostępu. Podman uruchamia kontenery bez demona i bez uprawnień roota, dzięki czemu każda próba ucieczki z kontenera ogranicza się do poziomu zwykłego użytkownika bez uprawnień. Jeśli potrzebne jest porównanie środowisk uruchomieniowych, warto przeczytać różnice między Podman a Docker na VPS. Jeśli wolisz całkowicie zrezygnować z kontenerów, instalacja Ollama bezpośrednio na VPS jest krótszą ścieżką.

SSD Nodes udostępnia obraz Fedora, która domyślnie zawiera zarówno Podman, jak i SELinux (security-enhanced Linux). Każde z poniższych poleceń działa na dowolnej dystrybucji z Podman w wersji 5 lub nowszej.

Dlaczego wersja na laptopa wymaga zmian na serwerze

Magazyn Fedora opublikował 5 sierpnia 2026 r. przejrzysty przewodnik po tym stosie: Uruchamianie Ollama lokalnie za pomocą Podman na Fedora Linux, autorstwa Yazana Monsheda. Jest to dobre wprowadzenie do narzędzi. Poradnik ten jest jednak przeznaczony dla laptopa, a cztery zawarte w nim wybory zachowują się inaczej na maszynie z publicznym adresem IP.

• Kontener uruchamiany jest za pomocą zwykłego podman run -d. Kontener uruchomiony ręcznie nie powraca po restarcie, ponieważ nie skonfigurowano mechanizmu jego automatycznego startu.
• Używany jest zmienny tag ollama/ollama. Na laptopie zauważysz dzień, w którym zmieni się zachowanie aplikacji. Na serwerze pierwszym sygnałem będzie skrypt, który przestał działać z dnia na dzień.
• Publikacja odbywa się za pomocą -p 11434:11434, co wiąże usługę z każdym interfejsem. Za domowym routerem jest to niedostępne z Internetu. Na VPS jest to publiczne API wnioskowania bez żadnego hasła.
• Proces działa jako użytkownik, na którego jesteś zalogowany. Na serwerze konto będące właścicielem kontenera nie powinno posiadać żadnych innych uprawnień, aby w razie ucieczki z kontenera napastnik trafił do pustego katalogu domowego.

Żaden z tych punktów nie jest błędem w kontekście maszyny, dla której tekst został napisany. Każdy z nich to po prostu decyzja, którą należy zweryfikować, gdy serwer jest dostępny z każdego miejsca, a nikt nie siedzi bezpośrednio przed nim.

Utworzenie użytkownika bez uprawnień i weryfikacja subuid

Rootless Podman mapuje wewnętrzne identyfikatory użytkowników (UID) kontenera na blok nieużywanych identyfikatorów na hoście. Blok ten jest zadeklarowany w /etc/subuid oraz /etc/subgid. Bez niego kontenery rootless nie mogą się uruchomić.

sudo dnf install -y podman        # or: sudo apt install -y podman
sudo useradd --create-home --shell /bin/bash --comment "Ollama container owner" ollama
sudo passwd --lock ollama
grep ollama /etc/subuid /etc/subgid

Polecenie grep powinno wyświetlić dwie linie, po jednej z każdego pliku, z których każda wskazuje zakres 65536 identyfikatorów:

/etc/subuid:ollama:100000:65536
/etc/subgid:ollama:100000:65536

Wartość początkowa będzie inna i jest to poprawne zachowanie. Jeśli grep nie wyświetli nic, useradd nie przydzielił zakresu, a pierwsze polecenie podman wykonane przez tego użytkownika zakończy się błędem:

Error: cannot find UID/GID for user ollama: no subuid ranges found for user "ollama" in /etc/subuid

Przypisz zakres, którego nie posiada żaden inny użytkownik, a następnie poinformuj Podman, że stare mapowanie jest nieaktualne:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ollama
sudo -iu ollama podman system migrate

Zablokowanie hasła oznacza, że nikt nie zaloguje się bezpośrednio jako ollama. Dostęp do konta uzyskuje się z poziomu użytkownika administracyjnego za pomocą sudo -iu ollama.

Włączanie trybu lingering, aby usługa działała po wylogowaniu

Instancja systemd użytkownika uruchamia się zazwyczaj w momencie logowania i kończy działanie przy wylogowaniu, a /run/user/<uid> jest usuwane wraz z nią. Każdy bezrootowy kontener należący do tego użytkownika zostaje w tym samym momencie zatrzymany. Tryb lingering utrzymuje instancję użytkownika w stanie aktywnym bez przypisanej sesji.

sudo loginctl enable-linger ollama
loginctl show-user ollama --property=Linger

Polecenie to powinno wyświetlić Linger=yes. Włącz tę opcję przed utworzeniem jednostki, ponieważ katalog wymagany przez jednostkę, /run/user/<uid>, istnieje tylko wtedy, gdy tryb lingering jest aktywny.

Istnieje jeszcze jeden krok, którego często się nie przewiduje. sudo -iu ollama zapewnia powłokę, ale nie magistralę sesji, dlatego systemctl --user kończy się natychmiastowym błędem:

Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

systemd szuka magistrali użytkownika w $XDG_RUNTIME_DIR/bus, a sudo -i nie ustawia tej zmiennej. Należy ustawić ją ręcznie w każdej powłoce administratora, w której zarządzana jest ta usługa:

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user status

Lokalizacja plików binarnych modelu i planowanie miejsca na dysku

Ollama zapisuje wagi w /root/.ollama/models wewnątrz kontenera. Podmontuj katalog z katalogu domowego użytkownika do tej ścieżki, a pliki trafią w miejsce, które można zmierzyć: /home/ollama/ollama-data/models. Obiekty typu blob trafiają do models/blobs jako pliki adresowane zawartością, a models/manifests przechowuje mały indeks, który je nazywa. Jeśli użyjesz nazwanego wolumenu, zgodnie z artykułem w Fedora Magazine, to samo drzewo plików znajduje się w /home/ollama/.local/share/containers/storage/volumes/<volume>/_data. W obu przypadkach ollama pull oraz ollama run zapisują wagi w tym samym drzewie, a to, co odróżnia te dwa polecenia to jedynie kwestia tego, czy po zakończeniu pobierania otwiera się sesja czatu.

Oszacuj miejsce na dysku przed pobraniem czegokolwiek. Opublikowane rozmiary pobierania stanowią wartość minimalną.

[
  {
    "label": "gemma3:4b",
    "download_gb": 3.3
  },
  {
    "label": "mistral:7b",
    "download_gb": 4.4
  },
  {
    "label": "qwen3:8b",
    "download_gb": 5.2
  },
  {
    "label": "gemma3:12b",
    "download_gb": 8.1
  },
  {
    "label": "qwen3:14b",
    "download_gb": 9.3
  },
  {
    "label": "gemma3:27b",
    "download_gb": 17
  },
  {
    "label": "qwen3:30b",
    "download_gb": 19
  }
]

Wszystkie 7 wiersze to wartości opublikowane na ollama.com/library, a nie rozmiary zmierzone na dysku. Najmniejszy tag w zestawieniu, gemma3:4b, pobiera 3.3 GB. Największy, qwen3:30b, pobiera 19 GB. Sam obraz kontenera znajduje się ponad tym we własnej pamięci masowej Podman, więc sprawdź obie wartości łącznie za pomocą podman system df oraz df -h /home. Model wymaga również w pamięci RAM ilości miejsca odpowiadającej w przybliżeniu jego rozmiarowi na dysku w momencie załadowania, plus dodatkowej przestrzeni na okno kontekstowe, dlatego model 19 GB nie uruchomi się na VPS z 16 GB pamięci RAM.

Przypnij tag obrazu i użyj pełnej nazwy rejestru

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
mkdir -p ~/ollama-data ~/.config/containers/systemd
podman pull docker.io/ollama/ollama:0.32.9

Użyj wydanej wersji tagu, 0.32.9 na sierpień 2026, a nie latest. Przypięty tag oznacza, że restart o godzinie 04:00 dostarczy ten sam plik binarny, który był testowany, więc każda zmiana w zachowaniu wynika z wprowadzonych zmian. Docker Hub publikuje również tagi -rc oraz -rocm dla tych samych wersji; wybierz wersję podstawową, chyba że używasz procesora graficznego AMD.

Wpisz również hosta rejestru. W systemie Fedora krótka nazwa w jednostce systemd nie posiada terminala, który mógłby wyświetlić monit, przez co jednostka kończy się błędem:

Error: short-name "ollama/ollama" did not resolve to an alias and no unqualified-search registries are defined

Ręczne pobranie obrazu przed uruchomieniem jest opcjonalne, ale przydatne, ponieważ przenosi proces pobierania wielogigabajtowych danych poza limit czasu startu jednostki.

Jednostka Quadlet przetrwała restart

Quadlet to generator systemd dla Podman. Tworzysz plik .container, systemd zamienia go w usługę podczas rozruchu, a podman generate systemd nie jest już potrzebne. Zapisz to jako /home/ollama/.config/containers/systemd/ollama.container, którego właścicielem jest użytkownik ollama.

[Unit]
Description=Ollama API (rootless)
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/ollama/ollama:0.32.9
ContainerName=ollama
PublishPort=127.0.0.1:11434:11434
Volume=/home/ollama/ollama-data:/root/.ollama:Z
Environment=OLLAMA_KEEP_ALIVE=30m
Environment=OLLAMA_MAX_LOADED_MODELS=1

[Service]
Restart=always
TimeoutStartSec=900

[Install]
WantedBy=default.target

Nazwa pliku określa nazwę usługi, więc ollama.container staje się ollama.service.

systemctl --user daemon-reload
systemctl --user start ollama.service
systemctl --user status ollama.service

status powinno pokazać active (running). Nie uruchamiaj systemctl --user enable ollama.service. Jednostka nie istnieje jako plik na dysku, więc systemd odmawia:

Failed to enable unit: Unit file /run/user/1001/systemd/generator/ollama.service is transient or generated.

Sekcja [Install] wykonuje już to zadanie. Quadlet sam tworzy dowiązanie startowe podczas daemon-reload, dlatego to polecenie nie jest opcjonalne. TimeoutStartSec=900 obejmuje pierwsze uruchomienie, które musi jeszcze pobrać obraz, ponieważ domyślne 90 sekund nie wystarcza na pobranie dwóch gigabajtów danych, a systemd przerwie start jako nieudany. OLLAMA_KEEP_ALIVE=30m utrzymuje model w pamięci między żądaniami zamiast zwalniać go po pięciu minutach; kompromisy opisano w utrzymywaniu modelu Ollama w pamięci. Jeśli którekolwiek z użytych tu pojęć systemd jest nowe, jak działają usługi i timery systemd na VPS omawia same jednostki.

Dlaczego katalog modelu zwraca błąd permission denied w SELinux

W systemach Fedora, RHEL, Rocky oraz AlmaLinux, SELinux jest domyślnie włączony w trybie wymuszania (enforcing). Proces kontenera działa w domenie container_t, a katalog w katalogu domowym użytkownika jest oznaczony etykietą user_home_t. Polityka bezpieczeństwa nie zezwala na interakcję między nimi, dlatego Ollama nie może utworzyć drzewa modeli, co powoduje zakończenie pracy kontenera. getenforce wyświetla Enforcing w tych systemach, a odmowa dostępu jest rejestrowana:

sudo ausearch -m avc -ts recent

Widoczny będzie wiersz wskazujący domenę oraz etykietę docelową:

avc:  denied  { write } for  pid=1842 comm="ollama" name="models" dev="vda1" ino=131077 scontext=system_u:system_r:container_t:s0:c214,c827 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permlisted=0

Opcja :Z na końcu wiersza Volume= stanowi rozwiązanie. Powoduje ona zmianę etykiety katalogu hosta na container_file_t i przypisanie mu prywatnej kategorii MCS (multi-category security), którą posiada tylko dany kontener. Mała litera :z używa etykiety współdzielonej, co jest pożądane w przypadku, gdy dwa kontenery odczytują ten sam katalog.

Należy zachować ostrożność przy stosowaniu :Z, ponieważ operacja ta jest destrukcyjna i przebiega bez ostrzeżeń. Zmiana etykiet odbywa się rekurencyjnie. Wskazanie /home/ollama spowoduje zmianę etykiet wszystkich plików w tym katalogu domowym, co uniemożliwi użytkownikowi logowanie za pomocą kluczy SSH. Zawsze należy przypisywać :Z dedykowany podkatalog, który nie zawiera innych danych. Wolumeny nazwane nie wymagają tego zabiegu, ponieważ Podman nadaje im poprawne etykiety podczas tworzenia. Jeśli potrzebne są szersze informacje, podstawy SELinux dla serwera wyjaśniają konteksty oraz zmienne logiczne (booleans). W systemach Ubuntu i Debian stosowany jest AppArmor, dlatego :Z jest tam ignorowane, a pozostawienie tego parametru w jednostce nie powoduje błędów.

Zamknięcie portu 11434 i dostęp do API przez SSH

PublishPort=127.0.0.1:11434:11434 wiąże stronę hosta z interfejsem loopback. Potwierdź to:

ss -ltnp | grep 11434
curl http://127.0.0.1:11434

Dane wyjściowe ss muszą wskazywać 127.0.0.1:11434. 0.0.0.0:11434 lub *:11434 oznacza, że port jest otwarty na świat, a curl musi zwrócić Ollama is running.

Należy zachować precyzję przy określaniu strony wiązania. Adres w PublishPort to adres hosta. Wewnątrz kontenera Ollama musi nasłuchiwać na wszystkich interfejsach, co jest ustawieniem domyślnym obrazu. Ustawienie Environment=OLLAMA_HOST=127.0.0.1 wiąże Ollama z pętlą zwrotną kontenera, a Podman przekazuje opublikowany ruch na adres sieciowy kontenera, przez co każde żądanie jest odrzucane, nawet z poziomu hosta.

Otwarty port 11434 generuje dwa rodzaje zagrożeń. Ollama nie posiada mechanizmu uwierzytelniania, więc każdy, kto uzyska dostęp do portu, może wyświetlić listę modeli za pomocą /api/tags, uruchamiać wnioskowanie przy użyciu Twojego procesora i limitu transferu danych przez /api/generate, pobierać nowe modele na Twój dysk oraz usuwać te już istniejące. Po drugie, zwykły protokół HTTP przesyła prompty i odpowiedzi otwartym tekstem, więc każde urządzenie na trasie połączenia może je odczytać. Oba problemy znikają, jeśli port nie wychodzi poza serwer.

Z poziomu stacji roboczej przekieruj port przez SSH:

ssh -N -L 11434:127.0.0.1:11434 you@vps.example.com

Teraz http://127.0.0.1:11434 na Twoim laptopie to Ollama działająca na serwerze, zabezpieczona szyfrowaniem sesji SSH. Jeśli na laptopie działa już lokalna instancja Ollama, wiązanie nie powiedzie się z błędem bind [127.0.0.1]:11434: Address already in use; użyj -L 11435:127.0.0.1:11434 i skieruj klienta na port 11435.

Jeśli dostęp jest wymagany przez przeglądarkę, umieść przed usługą reverse proxy z hasłem. Blok konfiguracji Caddy składa się z czterech linii, a caddy hash-password generuje wymagany skrót bcrypt:

ollama.example.com {
  basic_auth {
    you $2a$14$replace_with_the_generated_hash
  }
  reverse_proxy 127.0.0.1:11434
}

Caddy automatycznie uzyskuje certyfikat TLS (transport layer security), dzięki czemu ruch jest szyfrowany. Najpierw przetestuj klienta: wiele narzędzi komunikujących się z Ollama nie posiada pola dla nagłówka Authorization i nie obsłuży uwierzytelniania basic auth, zwracając błąd 401 Unauthorized. Tunel SSH nie ma tego problemu, dlatego jest to zalecane rozwiązanie domyślne.

Pobranie modelu i weryfikacja pełnej ścieżki

podman exec -it ollama ollama pull gemma3:4b
curl -s http://127.0.0.1:11434/api/tags
curl -s http://127.0.0.1:11434/api/generate -d '{"model":"gemma3:4b","prompt":"Reply with the single word: ready","stream":false}'
du -sh ~/ollama-data/models

/api/tags zwraca listę JSON z gemma3:4b. /api/generate zwraca obiekt JSON z polem response, po krótkiej przerwie niezbędnej na wczytanie wag z dysku. du powinno wskazać wartość zbliżoną do opublikowanego rozmiaru pobierania. Następnie należy zweryfikować część, której dotyczy cały ten przewodnik:

sudo reboot
# reconnect, then:
sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user is-active ollama.service

active oznacza, że proces pozostaje aktywny, a sekcja [Install] oraz daemon-reload wykonały swoje zadania. inactive oznacza, że brakuje jednego z tych trzech elementów.

Tryby awarii i towarzyszące im komunikaty

Kontener znika po restarcie. Sprawdź najpierw loginctl show-user ollama --property=Linger, ponieważ bez Linger=yes instancja systemd użytkownika nie uruchamia się podczas startu systemu. Jeśli funkcja lingering jest włączona, brakuje sekcji [Install] w pliku .container lub plik został edytowany bez wykonania systemctl --user daemon-reload.

Error: statfs /home/ollama/ollama-data: no such file or directory. Źródło montowania typu bind musi istnieć przed uruchomieniem kontenera. Podman nie tworzy automatycznie katalogów na hoście. Wykonaj mkdir -p ~/ollama-data jako użytkownik ollama.

Uruchomienie kończy się niepowodzeniem po 90 sekundach. journalctl --user -u ollama.service pokazuje Start operation timed out. Terminating., ponieważ pobieranie obrazu nadal trwało. Pobierz obraz ręcznie lub zwiększ TimeoutStartSec=900.

Kontener uruchamia się i natychmiast kończy działanie. podman logs ollama oraz sudo ausearch -m avc -ts recent razem wskazują, czy przyczyną jest etykieta SELinux. Komunikat AVC zawierający container_t oraz user_home_t oznacza brak :Z.

Żądania z hosta są odrzucane. curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused z usługą active zazwyczaj oznacza, że OLLAMA_HOST ustawiono na adres loopback wewnątrz kontenera. Usuń tę linię.

Generowanie jest bardzo wolne lub kontener jest zabijany. Bez GPU wnioskowanie odbywa się na CPU, a duże modele są z natury wolne. Kontener, który kończy działanie w trakcie żądania, a w logach zawiera signal: killed, jest zamykany przez mechanizm OOM killer jądra systemu. Należy wybrać mniejszy tag z powyższej tabeli.

Aktualizacja przypiętego obrazu

Przypięcie oznacza, że aktualizacje są procesem inicjowanym ręcznie, a nie automatycznym. Należy edytować Image= w pliku ollama.container, a następnie przeładować konfigurację i zrestartować usługę:

systemctl --user daemon-reload
systemctl --user restart ollama.service
podman exec ollama ollama --version

Modele znajdują się w punkcie montowania (bind mount), więc pozostają nienaruszone po zmianie obrazu. Opcja AutoUpdate=registry w sekcji [Container] jest przeznaczona dla użytkowników korzystających ze zmiennych tagów. Nie przynosi ona korzyści w przypadku użycia stałego tagu wersji, ponieważ zawartość takiego tagu nigdy nie ulega zmianie. Należy wykonać kopię zapasową /home/ollama/ollama-data/models/manifests oraz pliku .container, pomijając katalog blobs: są one duże, a ollama pull pobierze je ponownie na nowej maszynie.

FAQ

Dlaczego mój kontener Podman działający bez uprawnień roota zatrzymuje się po wylogowaniu?

Instancja systemd użytkownika oraz jej katalog /run/user/<uid> są usuwane po zakończeniu ostatniej sesji użytkownika, co powoduje zamknięcie wszystkich kontenerów działających bez uprawnień roota. Uruchom sudo loginctl enable-linger ollama i sprawdź, czy loginctl show-user ollama --property=Linger zwraca Linger=yes. Włącz funkcję lingering przed utworzeniem jednostki Quadlet, ponieważ katalog uruchomieniowy wymagany przez jednostkę istnieje tylko wtedy, gdy funkcja ta jest aktywna.

Czy muszę stosować etykiety SELinux dla katalogu z modelami Ollama?

W systemach Fedora, RHEL, Rocky oraz AlmaLinux jest to konieczne, jeśli montujesz katalog hosta za pomocą bind mount. Kontener działa w domenie container_t, a katalogi w folderze domowym mają etykietę user_home_t, co powoduje odmowę zapisu i wyjście z Ollama. Dodaj :Z do linii Volume= i użyj dedykowanego podkatalogu, ponieważ zmiana etykiet działa rekurencyjnie, a wskazanie :Z na cały katalog domowy uniemożliwi użytkownikowi dostęp przez klucze SSH. Wolumeny nazwane są etykietowane przez Podman automatycznie i nie wymagają dodatkowej konfiguracji.

Ile miejsca na dysku potrzebuje model Ollama?

Przyjmij za punkt wyjścia rozmiar pobieranego pliku podany na stronie ollama.com/library, który waha się od 3.3 GB dla gemma3:4b do 19 GB dla qwen3:30b. Dodaj do tego rozmiar obrazu Podman oraz zapas miejsca, ponieważ drugi model nie zastępuje pierwszego na dysku. Sprawdź df -h /home przed pobraniem i du -sh ~/ollama-data/models po zakończeniu. Podobnie zaplanuj pamięć RAM: model potrzebuje w pamięci operacyjnej ilości miejsca zbliżonej do rozmiaru pliku modelu, powiększonej o okno kontekstowe.

Czy wystawienie portu 11434 na VPS jest bezpieczne?

Nie. Ollama nie posiada żadnego mechanizmu uwierzytelniania, więc każdy, kto uzyska dostęp do portu, może wyświetlić listę modeli, usunąć je, pobrać nowe na Twój dysk oraz uruchamiać wnioskowanie, zużywając Twój procesor i limit transferu danych. Ponadto zwykły protokół HTTP przesyła wszystkie zapytania i odpowiedzi otwartym tekstem. Powiąż port po stronie hosta z 127.0.0.1 za pomocą PublishPort=127.0.0.1:11434:11434, zweryfikuj ustawienie poleceniem ss -ltnp | grep 11434 i uzyskuj dostęp przez tunel SSH lub reverse proxy wymagające hasła.