Ollama w rootless Podman na VPS: konfiguracja Quadlet

Uruchamianie Ollama w Podman bez uprawnień roota na VPS

Aby uruchomić Ollama w kontenerze Podman bez uprawnień roota na serwerze, należy spełnić pięć warunków, które często pomijają poradniki dla systemów desktopowych. Kontener musi należeć do dedykowanego użytkownika bez uprawnień administracyjnych. 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. Interfejs API powinien nasłuchiwać wyłącznie na adresie loopback, a dostęp do niego uzyskuje się poprzez 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, dlatego sieć stanowi jedyną formę kontroli dostępu. Podman uruchamia kontenery bez demona i bez uprawnień roota, więc każda próba ucieczki z kontenera ogranicza się do uprawnień zwykłego użytkownika. Jeśli potrzebne jest porównanie środowisk uruchomieniowych, warto przeczytać jak Podman i Docker różnią się 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 system Fedora w swoich obrazach, a Fedora domyślnie zawiera zarówno Podman, jak i SELinux (security-enhanced Linux). Każde poniższe polecenie działa na dowolnej dystrybucji z zainstalowanym Podman w wersji 5 lub nowszej.

Dlaczego wersja na laptopa wymaga zmian w środowisku serwerowym

Magazyn Fedora opublikował 5 sierpnia 2026 r. przejrzysty przewodnik po tym stosie technologiczny: 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 założenia zachowują się inaczej na maszynie z publicznym adresem IP.

• Kontener uruchamiany jest za pomocą zwykłego polecenia podman run -d. Kontener uruchomiony ręcznie nie powróci po restarcie systemu, ponieważ nie skonfigurowano mechanizmu jego automatycznego startu.
• Użyto zmiennego tagu ollama/ollama. Na laptopie zauważysz zmianę zachowania w dniu aktualizacji. Na serwerze pierwszym sygnałem będzie skrypt, który przestał działać w nocy.
• Publikacja odbywa się za pomocą -p 11434:11434, co wiąże usługę z każdym interfejsem sieciowym. Za domowym routerem jest to bezpieczne, gdyż usługa pozostaje niedostępna z Internetu. Na VPS oznacza to wystawienie publicznego API wnioskowania bez żadnego zabezpieczenia hasłem.
• Proces działa na uprawnieniach użytkownika. Na serwerze konto będące właścicielem kontenera nie powinno posiadać żadnych innych uprawnień, aby w przypadku przełamania zabezpieczeń atakujący trafił do pustego katalogu domowego.

Żaden z tych punktów nie jest błędem w kontekście maszyny, dla której przygotowano poradnik. Każdy z nich to po prostu decyzja, którą należy zweryfikować, gdy serwer jest dostępny z dowolnego miejsca, a przed monitorem nie siedzi administrator.

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 w systemie hosta. Blok ten jest deklarowany w /etc/subuid oraz /etc/subgid. Bez niego kontenery rootless nie mogą zostać uruchomione.

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, co jest poprawne. Jeśli grep nie zwraca żadnych danych, 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

Należy przypisać zakres, którego nie posiada żaden inny użytkownik, a następnie poinformować 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łączenie trybu lingering, aby usługa działała po wylogowaniu

Instancja systemd użytkownika uruchamia się standardowo w momencie logowania i kończy działanie przy wylogowaniu, co powoduje usunięcie /run/user/<uid>. Każdy bezuprawnieniowy 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. Należy włączyć tę opcję przed utworzeniem jednostki, ponieważ katalog wymagany przez jednostkę, /run/user/<uid>, powstaje dopiero po aktywacji trybu lingering.

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

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

systemd poszukuje 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

Gdzie zapisywane są pliki modeli i ile miejsca na dysku zaplanować

Ollama zapisuje wagi w /root/.ollama/models wewnątrz kontenera. Podmontuj katalog z katalogu domowego użytkownika do tej ścieżki, aby pliki trafiały w miejsce, które można monitorować: /home/ollama/ollama-data/models. Obiekty typu blob trafiają do models/blobs jako pliki adresowane zawartością, a models/manifests przechowuje niewielki 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.

Oszacuj miejsce na dysku przed pobraniem czegokolwiek. Opublikowane rozmiary plików do pobrania 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 stronie ollama.com/library, a nie rozmiary zmierzone na dysku. Najmniejszy tag w zestawieniu, gemma3:4b, wymaga pobrania 3.3 GB. Największy, qwen3:30b, wymaga pobrania 19 GB. Sam obraz kontenera zajmuje dodatkowe miejsce w pamięci masowej Podman, dlatego sprawdź obie wartości łącznie za pomocą podman system df oraz df -h /home. Model wymaga również ilości pamięci RAM zbliżonej do rozmiaru pliku w momencie załadowania, plus miejsca na okno kontekstowe, więc 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 według stanu 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; należy wybrać wersję podstawową, chyba że używany jest procesor graficzny AMD.

Należy również wpisać 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 danych o rozmiarze wielu gigabajtów poza limit czasu startu jednostki.

Jednostka Quadlet przetrwała restart

Quadlet to generator systemd dla Podman. Użytkownik tworzy plik .container, systemd przekształca go w usługę podczas rozruchu, a podman generate systemd przestaje być potrzebny. Należy zapisać plik 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 należy uruchamiać systemctl --user enable ollama.service. Jednostka nie istnieje jako plik na dysku, więc systemd odrzuci takie polecenie:

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

Sekcja [Install] wykonuje to zadanie. Quadlet samodzielnie tworzy dowiązanie uruchamiania przy starcie podczas daemon-reload, dlatego to polecenie nie jest opcjonalne. TimeoutStartSec=900 uwzględnia pierwsze uruchomienie, które musi pobrać obraz, ponieważ domyślne 90 sekund jest niewystarczające dla pobrania dwóch gigabajtów danych, co spowodowałoby przerwanie procesu przez systemd jako błąd. OLLAMA_KEEP_ALIVE=30m utrzymuje model w pamięci między żądaniami zamiast usuwać go po pięciu minutach; wady i zalety tego rozwiązania opisano w utrzymywaniu modelu Ollama w pamięci. Jeśli słownictwo systemd jest nowe, działanie usług i timerów systemd na VPS wyjaśnia zasady funkcjonowania samych jednostek.

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

W systemach Fedora, RHEL, Rocky oraz AlmaLinux mechanizm SELinux jest domyślnie włączony w trybie 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, przez co Ollama nie może utworzyć drzewa modeli, a kontener kończy działanie. Narzędzie 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

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

Należy zachować ostrożność przy używaniu :Z, ponieważ operacja ta jest destrukcyjna i nie generuje ostrzeżeń. Zmiana etykiety 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. Należy zawsze wskazywać dla :Z dedykowany podkatalog, który nie zawiera innych danych. Wolumeny nazwane nie wymagają tego zabiegu, ponieważ Podman automatycznie nadaje im poprawne etykiety podczas tworzenia. Jeśli wymagane są szersze informacje, podstawy SELinux dla serwera wyjaśniają konteksty oraz wartości logiczne (booleans). W systemach Ubuntu i Debian stosowany jest AppArmor, dlatego :Z nie wykonuje tam żadnej akcji, a pozostawienie tego parametru w jednostce jest bezpieczne.

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ę w kwestii tego, która strona jest wiązana. Adres w PublishPort to adres hosta. Wewnątrz kontenera Ollama musi nasłuchiwać na wszystkich interfejsach, co jest domyślnym ustawieniem obrazu. Ustawienie Environment=OLLAMA_HOST=127.0.0.1 wiąże Ollama z własnym interfejsem loopback 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 (inference) przy użyciu Twojego procesora i limitów 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 w formie otwartego tekstu, co pozwala każdemu urządzeniu na trasie połączenia na ich odczytanie. Oba problemy znikają, jeśli port nie wychodzi poza obręb serwera.

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 również uruchomiona jest usługa Ollama, lokalne wiązanie zakończy się 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 wymagany jest dostęp przez przeglądarkę, umieść przed usługą reverse proxy z hasłem. Blok witryny w 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 za pomocą gemma3:4b. /api/generate zwraca obiekt JSON z polem response po krótkiej przerwie, podczas której wagi są ładowane 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 procesy działają w tle, a sekcja [Install] oraz daemon-reload wykonały swoje zadania. inactive oznacza, że brakuje jednego z tych trzech elementów.

Tryby awaryjne i komunikaty błędów

Kontener znika po restarcie. W pierwszej kolejności sprawdź 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 aktywna, oznacza to brak sekcji [Install] w pliku .container lub edycję pliku 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 wskazuje na Start operation timed out. Terminating., ponieważ pobieranie obrazu nadal trwało. Pobierz obraz ręcznie lub zachowaj TimeoutStartSec=900.

Kontener uruchamia się i natychmiast kończy działanie. podman logs ollama oraz sudo ausearch -m avc -ts recent pozwalają ustalić, 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 pętli zwrotnej wewnątrz kontenera. Usuń ten wiersz.

Generowanie jest bardzo wolne lub kontener zostaje zabity. Bez GPU wnioskowanie odbywa się na CPU, co w przypadku dużych modeli jest naturalnie powolne. Kontener, który kończy działanie w trakcie żądania z wpisem signal: killed w logach, został zamknięty przez mechanizm OOM killer jądra systemu; należy wybrać mniejszy tag z powyższej tabeli.

Aktualizacja przypiętego obrazu

Przypięcie wersji oznacza, że aktualizacje są działaniem celowym, a nie automatycznym procesem. 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 przetrwają zmianę obrazu w nienaruszonym stanie. Parametr AutoUpdate=registry w sekcji [Container] jest przeznaczony dla użytkowników korzystających ze zmiennych tagów. Nie przynosi on żadnych korzyści w połączeniu ze stałym tagiem wersji, ponieważ zawartość takiego taga nigdy nie ulega zmianie. Należy wykonać kopię zapasową /home/ollama/ollama-data/models/manifests oraz pliku .container, pomijając przy tym katalog blobs: są one duże, a ollama pull pobierze je ponownie na nowej maszynie.

FAQ

Dlaczego mój kontener Podman działający w trybie rootless zatrzymuje się po wylogowaniu?

Instancja systemd użytkownika oraz jej katalog /run/user/<uid> są usuwane, gdy kończy się ostatnia sesja tego użytkownika, co powoduje zatrzymanie wszystkich kontenerów rootless. 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 modeli Ollama?

W systemach Fedora, RHEL, Rocky oraz AlmaLinux jest to konieczne w przypadku montowania katalogu hosta (bind mount). Kontener działa w domenie container_t, a katalogi w folderze domowym mają etykietę user_home_t, co powoduje odmowę zapisu i wyłączenie 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?

Punktem wyjścia jest rozmiar pobieranego pliku podany na stronie ollama.com/library, który wynosi od 3.3 GB dla gemma3:4b do 19 GB dla qwen3:30b. Należy doliczyć rozmiar obrazu Podman oraz pozostawić wolną przestrzeń, ponieważ kolejny model nie zastępuje poprzedniego na dysku. Sprawdź df -h /home przed pobieraniem oraz du -sh ~/ollama-data/models po jego zakończeniu. Podobnie zaplanuj zasoby RAM: model wymaga w pamięci ilości miejsca zbliżonej do rozmiaru pliku modelu, powiększonej o rozmiar okna kontekstowego.

Czy wystawienie portu 11434 na VPS jest bezpieczne?

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