ద్వారా Matt Connor 2026-08-13 · అప్‌డేట్ చేయబడింది 2026-08-16

VPSలో rootless Podmanతో Ollama నడపడం

ప్రత్యేక user, lingering, reboot తర్వాత ప్రారంభమయ్యే Quadlet unit, SELinux labelsతో VPSలో Ollamaను rootless Podmanలో అమలు చేయండి. Port 11434ను మూసి SSH tunnel ద్వారా APIని వాడండి.

VPSలో rootless Podman ద్వారా Ollama నడపడం

సర్వర్‌లో rootless Podman ద్వారా Ollama నడపాలంటే desktop walkthroughలో వదిలివేయగల ఐదు అంశాలు తప్పనిసరిగా సరిగ్గా ఉండాలి. Containerకు ఒక ప్రత్యేక unprivileged user యజమానిగా ఉండాలి. ఆ userకు lingering ప్రారంభించి ఉండాలి. అందువల్ల మీరు logout అయిన తర్వాత కూడా container నడుస్తుంది. Quadlet file ద్వారా containerను systemdకు అప్పగించాలి. అందువల్ల reboot తర్వాత అది మళ్లీ ప్రారంభమవుతుంది. SELinux అమలు చేసే distributionsలో model directoryకి SELinux label ఉండాలి. API loopbackపై మాత్రమే listen చేయాలి. దాన్ని SSH (secure shell) tunnel ద్వారా యాక్సెస్ చేయాలి.

Ollama అనేది large language models (LLM) కోసం ఒక server. ఇది model weightsను diskపై నిల్వ చేసి, memoryలోకి load చేసి, port 11434పై వచ్చే HTTP requestsకు సమాధానం ఇస్తుంది. ఇందులో login, API key లేదా user accounts ఏవీ లేవు. కాబట్టి మీకు లభించే ఏకైక access control network మాత్రమే. Podman daemon లేకుండా, root లేకుండా containersను నడుపుతుంది. అందువల్ల container నుంచి బయటకు వచ్చిన ఏదైనా మొదట సాధారణ unprivileged user హక్కులతోనే నడుస్తుంది. ముందుగా runtime comparison చదవాలనుకుంటే VPSలో Podman మరియు Docker ఎలా భిన్నంగా ఉంటాయో చూడండి. Containersను పూర్తిగా వదిలేయాలనుకుంటే VPSలో Ollamaను నేరుగా install చేయడం తక్కువ దశలతో పూర్తవుతుంది.

SSD Nodes తన imagesలో Fedoraను అందిస్తుంది. Fedoraలో Podman మరియు SELinux (security-enhanced Linux) రెండూ defaultగా వస్తాయి. క్రింద ఉన్న ప్రతి command Podman 5 లేదా అంతకంటే కొత్త version ఉన్న ఏ distributionలోనైనా నడుస్తుంది.

ల్యాప్‌టాప్ కోసం ఉన్న విధానాన్ని సర్వర్‌లో ఎందుకు మార్చాలి

Fedora Magazine 5 August 2026న ఈ stack గురించి స్పష్టమైన మార్గదర్శకాన్ని ప్రచురించింది: Fedora Linuxలో Podmanతో Ollamaను స్థానికంగా నడపడం, రచయిత Yazan Monshed. ఈ toolsతో ప్రారంభించడానికి ఇది మంచి మొదటి గంట మార్గదర్శకం. అయితే ఇది ల్యాప్‌టాప్‌ను లక్ష్యంగా చేసుకుంది. అందులోని నాలుగు నిర్ణయాలు public IP address ఉన్న machineలో భిన్నంగా పనిచేస్తాయి.

ఇది containerను plain podman run -dతో ప్రారంభిస్తుంది. చేతితో ప్రారంభించిన container reboot తర్వాత మళ్లీ ప్రారంభం కాదు, ఎందుకంటే దాన్ని ప్రారంభించమని ఏ వ్యవస్థకూ చెప్పలేదు.
ఇది మారుతూ ఉండే ollama/ollama tagను ఉపయోగిస్తుంది. ల్యాప్‌టాప్‌లో ప్రవర్తన మారిన రోజునే మీకు తెలుస్తుంది. సర్వర్‌లో మొదటి సంకేతం overnight పనిచేయడం ఆపిన script కావచ్చు.
ఇది -p 11434:11434తో publish చేస్తుంది. ఇది ప్రతి interfaceకు bind అవుతుంది. Home router వెనుక ఉంటే అది internet నుంచి చేరుకోలేరు. VPSలో password లేకుండా public inference API అందుబాటులోకి వస్తుంది.
ఇది మీ స్వంత login userగా నడుస్తుంది. సర్వర్‌లో containerను కలిగి ఉన్న account మరే ఇతర వస్తువునూ కలిగి ఉండకూడదు. అప్పుడు break-out జరిగినా ఖాళీ home directoryలోనే ముగుస్తుంది.

ఇవేవీ అవి వ్రాయబడిన machineకు తప్పు కావు. అయితే machine ఎక్కడి నుంచైనా చేరుకోగలిగినప్పుడు, దాని ముందు ఎవరూ కూర్చోనప్పుడు, ప్రతి అంశాన్ని మళ్లీ పరిశీలించాలి.

అధికారాలు లేని user ను సృష్టించి, subuid ను తనిఖీ చేయండి

Rootless Podman container లోని అంతర్గత user IDలను (UID) host లో ఉపయోగించని IDల బ్లాక్‌కు map చేస్తుంది. ఆ బ్లాక్ /etc/subuid మరియు /etc/subgid లో నిర్వచించబడుతుంది. అది లేకపోతే rootless containers అసలు ప్రారంభం కావు.

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

grep output లో రెండు lines రావాలి. ప్రతి file నుంచి ఒక్క line రావాలి. ప్రతి line 65536 IDs పరిధిని చూపుతుంది:

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

మీ ప్రారంభ సంఖ్య వేరుగా ఉండవచ్చు. అది సాధారణమే. grep ఏమీ print చేయకపోతే, useradd ఎలాంటి పరిధినీ allocate చేయలేదు. ఆ user గా అమలు చేసే మొదటి podman command ఈ విధంగా విఫలమవుతుంది:

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

ఇతర user ఏదీ ఉపయోగించని పరిధిని కేటాయించండి. తరువాత పాత mapping చెల్లదని Podman కు తెలియజేయండి:

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

Password ను lock చేయడం ద్వారా ఎవరూ నేరుగా ollama గా login చేయలేరు. మీ admin user నుంచి sudo -iu ollama తో ఆ account ను access చేయాలి.

logout తర్వాత కూడా సేవ కొనసాగేందుకు lingering ను ప్రారంభించండి

వినియోగదారుడి systemd instance సాధారణంగా login సమయంలో ప్రారంభమై, logout సమయంలో ఆగిపోతుంది. దానితో పాటు /run/user/<uid> కూడా తొలగించబడుతుంది. ఆ వినియోగదారుడికి చెందిన ప్రతి rootless container కూడా అదే సమయంలో ఆగిపోతుంది. Lingering వల్ల session ఏదీ జత కాకపోయినా user instance నడుస్తూనే ఉంటుంది.

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

దాని output Linger=yes గా ఉండాలి. Unit సృష్టించే ముందు దీన్ని ప్రారంభించండి. ఎందుకంటే unit కు అవసరమైన /run/user/<uid> directory, lingering ప్రారంభించిన తర్వాత మాత్రమే ఉంటుంది.

ఇంకా ఒక దశ ఉంది. చాలామంది దీనిని ఊహించరు. sudo -iu ollama మీకు shell ఇస్తుంది, కానీ session bus ఇవ్వదు. అందువల్ల systemctl --user వెంటనే విఫలమవుతుంది:

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

systemd user bus కోసం $XDG_RUNTIME_DIR/bus వద్ద చూస్తుంది. sudo -i ఆ variable ను సెట్ చేయదు. ఈ సేవను నిర్వహించే ప్రతి admin shell లో దాన్ని చేతితో సెట్ చేయండి:

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

మోడల్ blobs ఎక్కడ నిల్వ అవుతాయి, ఎంత disk స్థలం కేటాయించాలి

Ollama container లోని /root/.ollama/models కు weights రాస్తుంది. ఆ path పై user home నుంచి ఒక directory ను bind చేయండి. అప్పుడు files ను కొలవగలిగే ప్రదేశంలో నిల్వ చేయవచ్చు: /home/ollama/ollama-data/models. Blobs content-addressed files గా models/blobs లో నిల్వ అవుతాయి. వాటి పేర్లను సూచించే చిన్న index models/manifests లో ఉంటుంది. Fedora Magazine post లో ఉన్నట్లుగా named volume ఉపయోగిస్తే, ఇదే tree /home/ollama/.local/share/containers/storage/volumes/<volume>/_data కింద ఉంటుంది.

ఏదైనా pull చేయడానికి ముందు disk పరిమాణాన్ని నిర్ణయించండి. ప్రచురించిన download sizes కనీస అవసరాన్ని తెలియజేస్తాయి.

ChartPublished download size per Ollama model tag, ollama.com/library, checked 13 August 2026

label

download_gb

gemma3:4b

3.3

mistral:7b

4.4

qwen3:8b

5.2

gemma3:12b

8.1

qwen3:14b

9.3

gemma3:27b

qwen3:30b

The data behind this chart

[
  {
    "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
  }
]

ఇక్కడి 7 వరుసలన్నీ ollama.com/library లో ప్రచురించిన గణాంకాలు. అవి disk పై కొలిచిన పరిమాణాలు కావు. ఇక్కడి అతి చిన్న tag gemma3:4b download చేయడానికి 3.3 GB అవసరం. అతి పెద్దది qwen3:30b; దాన్ని download చేయడానికి 19 GB అవసరం. దీనికి అదనంగా container image Podman స్వంత storage లో స్థలాన్ని ఉపయోగిస్తుంది. కాబట్టి podman system df మరియు df -h /home తో రెండు పరిమాణాలను కలిపి తనిఖీ చేయండి. Model load అయినప్పుడు దాని file size కు సమానమైన RAM సుమారుగా అవసరం. Context window కోసం కూడా అదనపు స్థలం కావాలి. అందువల్ల 16 GB VPS లో 19 GB model నడవదు.

image tag ను pin చేసి, పూర్తి registry పేరును ఉపయోగించండి

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

Released version tag ను ఉపయోగించండి. August 2026 నాటికి అది 0.32.9. latest ను ఉపయోగించవద్దు. Pinned tag ఉపయోగిస్తే 04:00 గంటలకు restart చేసినప్పుడు మీరు పరీక్షించిన అదే binary లభిస్తుంది. అందువల్ల behaviour లో వచ్చే మార్పు మీరు చేసిన మార్పు అని నిర్ధారించవచ్చు. Docker Hub అదే versions కోసం -rc మరియు -rocm tags ను కూడా publish చేస్తుంది. మీ వద్ద AMD GPU ఉంటే తప్ప plain tag ను ఎంచుకోండి.

Registry host ను కూడా రాయండి. Fedora లో systemd unit లోని short name కోసం prompt చూపించడానికి terminal ఉండదు. అందువల్ల unit ఈ error తో fail అవుతుంది:

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

ముందుగా చేతితో pull చేయడం optional, కానీ ఉపయోగకరం. దీని వల్ల multi-gigabyte download unit యొక్క start timeout పరిధి బయట జరుగుతుంది.

రీబూట్ తర్వాత కూడా ఉండే Quadlet unit

Quadlet అనేది Podman యొక్క systemd generator. మీరు ఒక .container ఫైల్ రాస్తే, systemd boot సమయంలో దాన్ని service గా మారుస్తుంది. అందువల్ల podman generate systemd ఇక అవసరం ఉండదు. దీన్ని ollama user యాజమాన్యంలో /home/ollama/.config/containers/systemd/ollama.containerగా సేవ్ చేయండి.

[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

ఫైల్ పేరు service name ను నిర్ణయిస్తుంది. అందువల్ల ollama.container, ollama.serviceగా మారుతుంది.

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

status, active (running)ను చూపాలి. systemctl --user enable ollama.serviceను అమలు చేయవద్దు. Unit డిస్క్‌లో ఫైల్‌గా ఉండదు. అందువల్ల systemd నిరాకరిస్తుంది:

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

[Install] section ఇప్పటికే ఆ పనిని చేస్తుంది. Quadlet, daemon-reload సమయంలో boot వద్ద ప్రారంభించే link ను స్వయంగా సృష్టిస్తుంది. అందుకే ఆ command ఐచ్ఛికం కాదు. మొదటిసారి start చేయడానికి image ను ఇంకా pull చేయాల్సి ఉంటే TimeoutStartSec=900 ఉపయోగపడుతుంది. ఎందుకంటే 90 seconds default timeout, two-gigabyte download కు సరిపోదు. అప్పుడు systemd ఆ start ను failed గా గుర్తించి నిలిపివేస్తుంది. OLLAMA_KEEP_ALIVE=30m ప్రతి request తర్వాత model ను unload చేయకుండా, requests మధ్య memory లో ఉంచుతుంది. దీనికి సంబంధించిన trade-offs ను Ollama model ను memory లో ఉంచడంలో చూడండి. ఇక్కడి systemd పరిభాషలో ఏదైనా కొత్తగా ఉంటే, VPSలో systemd services మరియు timers ఎలా పనిచేస్తాయిలో units గురించి వివరించబడింది.

SELinux కింద model directoryకి permission denied ఎందుకు వస్తుంది

Fedora, RHEL, Rocky మరియు AlmaLinuxలో SELinux డిఫాల్ట్‌గా enforcing స్థితిలో ఉంటుంది. Container process container_t domainలో నడుస్తుంది, అయితే user homeలోని directoryకి user_home_t label ఉంటుంది. ఈ రెండింటి మధ్య అనుమతిని policy ఇవ్వదు. అందువల్ల Ollama తన model treeని సృష్టించలేక container నిష్క్రమిస్తుంది. ఈ systemsలో getenforce అమలు చేస్తే Enforcing కనిపిస్తుంది, అలాగే denial నమోదు అవుతుంది:

sudo ausearch -m avc -ts recent

Domain మరియు target label పేర్లు ఉన్న ఒక line మీకు కనిపిస్తుంది:

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

Volume= line చివరలోని :Z పరిష్కారం. ఇది host directoryని container_file_tగా మళ్లీ label చేసి, ఈ containerకే చెందిన private MCS (multi-category security) categoryని దానికి కేటాయిస్తుంది. చిన్న అక్షరాలతో ఉన్న :z బదులుగా shared labelను ఉపయోగిస్తుంది. రెండు containers ఒకే directoryని చదవాల్సినప్పుడు అదే కావాలి.

:Z విషయంలో ఒక హెచ్చరిక ఉంది, ఎందుకంటే ఇది destructive మరియు నిశ్శబ్దంగా పనిచేస్తుంది. Relabelling recursiveగా జరుగుతుంది. దాన్ని /home/ollamaకి చూపిస్తే, ఆ home directoryలోని ప్రతి file మళ్లీ label అవుతుంది. దాంతో ఆ userకు SSH key access పనిచేయదు. :Zకు ఎల్లప్పుడూ మరేదీ లేని dedicated subdirectoryని మాత్రమే ఇవ్వండి. Named volumesకు ఇది అవసరం లేదు, ఎందుకంటే Podman వాటిని సృష్టించేటప్పుడు సరిగ్గా label చేస్తుంది. మరింత విస్తృత సమాచారం కోసం server కోసం SELinux ప్రాథమికాలులో contexts మరియు booleans వివరించబడ్డాయి. Ubuntu మరియు Debianలో బదులుగా AppArmor ఉపయోగిస్తారు. అక్కడ :Z ఎలాంటి ప్రభావం చూపదు, unitలో దాన్ని ఉంచినా సమస్య ఉండదు.

11434 port ను మూసివేసి SSH ద్వారా APIని చేరుకోండి

PublishPort=127.0.0.1:11434:11434 host వైపు bind ను loopback కు పరిమితం చేస్తుంది. దీన్ని నిర్ధారించండి:

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

ss output లో 127.0.0.1:11434 కనిపించాలి. 0.0.0.0:11434 లేదా *:11434 కనిపిస్తే port internet కు తెరిచి ఉంది. అప్పుడు curl తప్పనిసరిగా Ollama is running కు స్పందించాలి.

మీరు ఏ వైపు bind చేస్తున్నారో ఖచ్చితంగా గుర్తించండి. PublishPort లోని address host address. Container లో Ollama అన్ని interfaces పై వినడం కొనసాగించాలి. ఇదే image యొక్క default. Environment=OLLAMA_HOST=127.0.0.1 ను సెట్ చేస్తే Ollama container యొక్క స్వంత loopback కు bind అవుతుంది. అప్పుడు Podman published traffic ను container network address కు పంపుతుంది. అందువల్ల host నుంచే చేసినా ప్రతి request తిరస్కరించబడుతుంది.

11434 port ను తెరిచి ఉంచడం వల్ల రెండు సమస్యలు వస్తాయి. Ollama లో authentication లేదు. కాబట్టి port ను చేరుకోగల ఎవరైనా /api/tags ద్వారా మీ models జాబితాను చూడగలరు. /api/generate ద్వారా మీ CPU మరియు bandwidth allowance ఉపయోగించి inference నడపగలరు. మీ disk పై కొత్త models ను pull చేయగలరు. మీ వద్ద ఉన్న models ను delete చేయగలరు. రెండవది, remote port కు plain HTTP ద్వారా పంపిన prompts మరియు completions cleartext లో ఉంటాయి. అందువల్ల మార్గంలోని ప్రతి machine వాటిని చదవగలదు. Port host వెలుపలికి వెళ్లకుండా చేస్తే ఈ రెండు సమస్యలు తొలగిపోతాయి.

మీ workstation నుంచి SSH ద్వారా port ను forward చేయండి:

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

ఇప్పుడు మీ laptop లోని http://127.0.0.1:11434, SSH session encryption లోపల నడుస్తున్న server యొక్క Ollama కు అనుసంధానమవుతుంది. మీ laptop లో ఇప్పటికే Ollama నడుస్తుంటే local bind bind [127.0.0.1]:11434: Address already in use తో విఫలమవుతుంది. -L 11435:127.0.0.1:11434 ను ఉపయోగించి, మీ client ను 11435 వైపు చూపించండి.

Browser client కు ఇది అవసరమైతే, ముందుగా password కలిగిన reverse proxy ను ఉంచండి. Caddy site block నాలుగు lines మాత్రమే ఉంటుంది. దీనికి అవసరమైన bcrypt hash ను caddy hash-password చూపిస్తుంది:

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

Caddy స్వయంగా TLS (transport layer security) ద్వారా certificate పొందుతుంది. అందువల్ల traffic encrypted గా ఉంటుంది. ముందుగా మీ client ను పరీక్షించండి. Ollama తో మాట్లాడే అనేక tools లో Authorization header కోసం field ఉండదు. కాబట్టి అవి basic auth కు bare 401 Unauthorized తో విఫలమవుతాయి. SSH tunnel కు ఈ సమస్య ఉండదు. అందుకే ఇక్కడ దాన్ని default recommendation గా సూచిస్తున్నాం.

మోడల్‌ను pull చేసి పూర్తి మార్గాన్ని తనిఖీ చేయండి

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 gemma3:4b ను జాబితా చేసే JSON ను తిరిగి ఇస్తుంది. డిస్క్‌ నుంచి weights load అయ్యే సమయంలో కొద్దిసేపు ఆగిన తర్వాత /api/generate, response field కలిగిన JSON object ను తిరిగి ఇస్తుంది. du, ప్రచురించిన download size కు దగ్గరగా ఉన్న సంఖ్యను చూపాలి. ఇప్పుడు ఈ guide మొత్తం దృష్టి పెట్టిన భాగం పనిచేస్తుందని నిరూపించండి:

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

active అంటే lingering, [Install] section మరియు daemon-reload రెండూ సరిగ్గా పనిచేశాయని అర్థం. inactive అంటే ఈ మూడింటిలో ఒకటి అందుబాటులో లేదని అర్థం.

మీరు చూడగల సందేశాలతో failure modes

Reboot తర్వాత container కనిపించదు. ముందుగా loginctl show-user ollama --property=Linger ను పరిశీలించండి. Linger=yes లేకపోతే, వినియోగదారుడి systemd instance boot సమయంలో ఎప్పుడూ ప్రారంభం కాదు. lingering ప్రారంభించబడి ఉంటే, .container ఫైల్‌లో [Install] section లేకపోవచ్చు. లేదా మీరు ఫైల్‌ను సవరించిన తర్వాత systemctl --user daemon-reload ను అమలు చేసి ఉండకపోవచ్చు.

Error: statfs /home/ollama/ollama-data: no such file or directory. Container ప్రారంభం కావడానికి ముందు bind mount source తప్పనిసరిగా ఉండాలి. Podman మీ కోసం host directories ను సృష్టించదు. ollama user గా mkdir -p ~/ollama-data ను అమలు చేయండి.

90 seconds వద్ద start విఫలమవుతుంది. Image pull ఇంకా నడుస్తుండటంతో journalctl --user -u ollama.service, Start operation timed out. Terminating. ను చూపిస్తుంది. Image ను manual గా pull చేయండి లేదా TimeoutStartSec=900 ను ఉంచండి.

Container ప్రారంభమై వెంటనే ఆగిపోతుంది. ఇది SELinux label సమస్యేనా అని podman logs ollama మరియు sudo ausearch -m avc -ts recent కలిసి తెలియజేస్తాయి. container_t మరియు user_home_t పేర్లతో ఉన్న AVC సందేశం, :Z లేదని సూచిస్తుంది.

Host నుంచి requests తిరస్కరించబడుతున్నాయి. Service active తో curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused సాధారణంగా, container లో loopback address కు OLLAMA_HOST సెట్ అయిందని సూచిస్తుంది. ఆ line ను తొలగించండి.

Generation చాలా నెమ్మదిగా ఉంటుంది లేదా container నిలిపివేయబడుతుంది. GPU లేకపోతే inference CPUపై నడుస్తుంది. అందువల్ల పెద్ద model సహజంగానే నెమ్మదిగా ఉంటుంది. Logs లో signal: killed కనిపిస్తూ request మధ్యలో container ఆగిపోతే, అది kernel out-of-memory killer చర్య. కాబట్టి పై chart నుంచి చిన్న tag ను ఎంచుకోండి.

స్థిరపరచిన image ను నవీకరించడం

Pinning అంటే updates మీ నియంత్రణలో ఉండటం; అవి స్వయంగా జరిగే విషయం కాదు. ollama.container లోని Image= ను సవరించి, తరువాత reload చేసి restart చేయండి:

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

Models bind mount లో ఉంటాయి. అందువల్ల image మారినప్పటికీ అవి అలాగే ఉంటాయి. [Container] విభాగంలోని AutoUpdate=registry moving tag ఉపయోగించే వారి కోసం ఉంది. Fixed version tag తో పాటు దీనివల్ల ఉపయోగం ఉండదు, ఎందుకంటే ఆ tag లోని contents ఎప్పటికీ మారవు. /home/ollama/ollama-data/models/manifests మరియు .container file ను backup చేయండి. Blobs ను backup చేయకండి: అవి పెద్దవిగా ఉంటాయి, కొత్త box లో ollama pull వాటిని మళ్లీ fetch చేస్తుంది.

FAQ

నేను log out అయినప్పుడు నా rootless Podman container ఎందుకు ఆగిపోతుంది?

ఆ user కు సంబంధించిన చివరి session ముగిసినప్పుడు, ఆ user యొక్క systemd instance మరియు దాని /run/user/<uid> directory తొలగించబడతాయి. వాటితో పాటు ప్రతి rootless container కూడా ఆగిపోతుంది. sudo loginctl enable-linger ollama ను run చేసి, loginctl show-user ollama --property=Linger లో Linger=yes కనిపిస్తుందో నిర్ధారించండి. Quadlet unit ను సృష్టించే ముందు lingering ను enable చేయండి. ఎందుకంటే unit కు అవసరమైన runtime directory lingering enable అయిన తర్వాత మాత్రమే అందుబాటులోకి వస్తుంది.

Ollama model directory పై SELinux labels అవసరమా?

Fedora, RHEL, Rocky మరియు AlmaLinux లో host directory ను bind mount చేస్తే అవసరం. Container container_t domain లో నడుస్తుంది. Home folder లోని directory కి user_home_t label ఉండటంతో write నిరాకరించబడుతుంది మరియు Ollama exit అవుతుంది. Volume= line కు :Z ను append చేసి, దానికి ప్రత్యేక subdirectory ఇవ్వండి. Relabelling nested directories కు కూడా వర్తిస్తుంది. :Z ను మొత్తం home directory కి pointing చేస్తే ఆ user యొక్క SSH key access పనిచేయదు. Podman named volumes కు సరైన labels స్వయంచాలకంగా ఇస్తుంది. వాటికి అదనపు configuration అవసరం లేదు.

Ollama model కు ఎంత disk అవసరం?

ollama.com/library లో ప్రచురించిన download size ను ప్రారంభ అంచనాగా తీసుకోండి. ఇది gemma3:4b కోసం 3.3 GB నుంచి qwen3:30b కోసం 19 GB వరకు ఉంటుంది. దీనికి అదనంగా Podman image కు అవసరమైన disk ను లెక్కించండి. కొంత ఖాళీని కూడా ఉంచండి. ఎందుకంటే రెండవ model disk పై మొదటి model ను భర్తీ చేయదు. Pull చేయడానికి ముందు df -h /home ను, pull చేసిన తర్వాత du -sh ~/ollama-data/models ను పరిశీలించండి. RAM ను కూడా ఇదే విధంగా ప్రణాళిక చేయండి. Loaded స్థితిలో model కు సాధారణంగా దాని file size కు సమానమైన memory అవసరం. దీనికి context window memory కూడా అదనంగా అవసరం.

VPS పై port 11434 ను బయటకు అందించడం సురక్షితమేనా?

కాదు. Ollama లో ఏ విధమైన authentication కూడా default గా ఉండదు. అందువల్ల ఆ port కు చేరగల ఎవరైనా మీ models ను list చేయవచ్చు, వాటిని delete చేయవచ్చు, మీ disk పై కొత్త models ను pull చేయవచ్చు, అలాగే మీ CPU మరియు bandwidth allowance ను ఉపయోగించి inference run చేయవచ్చు. Internet పై plain HTTP ఉపయోగిస్తే ప్రతి prompt మరియు completion cleartext లో పంపబడుతుంది. Host side ను PublishPort=127.0.0.1:11434:11434 తో 127.0.0.1 కు bind చేయండి. ss -ltnp | grep 11434 తో దాన్ని నిర్ధారించండి. తరువాత password అవసరమైన SSH tunnel లేదా reverse proxy ద్వారా దాన్ని access చేయండి.

#ollama #podman #rootless#quadlet#selinux #systemd