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

VPSలో rootless Podmanతో Ollamaను ఎలా నడపాలి

ప్రత్యేక user, lingering, reboot తర్వాత ప్రారంభమయ్యే Quadlet unit, SELinux labels, మూసివేసిన portతో VPSలో Ollamaను సురక్షితంగా నడపడం నేర్చుకోండి.

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

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

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లోనైనా నడుస్తుంది.

సర్వర్‌లో laptop వెర్షన్‌కు మార్పులు ఎందుకు అవసరం

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

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

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

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

Rootless Podman container లోని అంతర్గత user IDs (UID) ను host పై ఉపయోగించని IDs యొక్క ఒక block కు map చేస్తుంది. ఆ block ను /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 నుంచి రెండు lines రావాలి. ప్రతి file నుంచి ఒక line వస్తుంది. ప్రతి line 65536 IDs పరిధిని పేర్కొంటుంది:

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

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

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

ఇతర user ఏదీ ఉపయోగించని పరిధిని assign చేసి, పాత 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 చేయాలి.

లాగ్‌అవుట్‌ తర్వాత కూడా సేవ కొనసాగేందుకు 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 ఎక్కడ నిల్వ అవుతాయి, ఎంత డిస్క్ స్థలాన్ని కేటాయించాలి

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

ఏదైనా download చేయడానికి ముందు డిస్క్ పరిమాణాన్ని నిర్ణయించండి. ప్రచురించిన 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 rows అన్నీ ollama.com/library లో ప్రచురించిన గణాంకాలు. ఇవి డిస్క్‌పై కొలిచిన sizes కావు. ఇక్కడి అతి చిన్న tag gemma3:4b download అయినప్పుడు 3.3 GB స్థలాన్ని ఉపయోగిస్తుంది. అతి పెద్ద tag 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

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

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

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

ముందుగా చేతితో pull చేయడం తప్పనిసరి కాదు. అయితే అది ఉపయోగకరంగా ఉంటుంది, ఎందుకంటే multi-gigabyte download unit యొక్క start timeout వెలుపల పూర్తవుతుంది.

రీబూట్ తర్వాత కూడా పనిచేసే Quadlet unit

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

[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 డిస్క్‌లో file గా ఉండదు కాబట్టి systemd నిరాకరిస్తుంది:

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

[Install] section ఇప్పటికే ఆ పని చేస్తుంది. daemon-reload సమయంలో Quadlet స్వయంగా start-at-boot link ను సృష్టిస్తుంది. అందుకే ఆ command ఐచ్ఛికం కాదు. మొదటి start సమయంలో image ను ఇంకా pull చేయాల్సి ఉండవచ్చు. దీనికి TimeoutStartSec=900 ఉపయోగపడుతుంది, ఎందుకంటే default 90 seconds, రెండు-gigabyte download కు సరిపోదు; systemd ఆ start ను failed గా పరిగణించి నిలిపివేస్తుంది. OLLAMA_KEEP_ALIVE=30m requests మధ్య ఒక model ను memory లో ఉంచుతుంది. దాన్ని ఐదు నిమిషాల తర్వాత unload చేయదు. దీనికి సంబంధించిన 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 exit అవుతుంది. ఈ systemsలో getenforce, Enforcing ను చూపిస్తుంది. Denial ఇలా record అవుతుంది:

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కి relabel చేసి, ఈ containerకే చెందిన private MCS (multi-category security) categoryని దానికి జతచేస్తుంది. Lowercase :z బదులుగా shared labelను ఉపయోగిస్తుంది. రెండు containers ఒకే directoryని చదవాల్సినప్పుడు అదే అవసరం.

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

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

PublishPort=127.0.0.1:11434:11434 host వైపు binding ను 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 కు స్పందించాలి.

ఏ వైపు binding చేస్తున్నారో స్పష్టంగా గుర్తించండి. 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 తెరిచి ఉండటం వల్ల రెండు విధాలుగా నష్టం కలుగుతుంది. Ollamaలో authentication లేదు. కాబట్టి port కు చేరుకోగల ఎవరైనా /api/tags ద్వారా మీ models జాబితాను చూడగలరు, /api/generate ద్వారా మీ CPU మరియు bandwidth allowance ఉపయోగించి inference నడపగలరు, మీ diskలో కొత్త modelsను pull చేయగలరు, మీ వద్ద ఉన్న modelsను తొలగించగలరు. రెండవది, remote portకు plain HTTP ద్వారా పంపిన prompts మరియు completions cleartextలో ఉంటాయి. కాబట్టి మార్గంలోని ప్రతి machine వాటిని చదవగలదు. Port ఈ machine బయటకు వెళ్లకుండా చేస్తే రెండు సమస్యలూ తొలగిపోతాయి.

మీ 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కి point చేయండి.

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ను test చేయండి. Ollamaతో మాట్లాడే అనేక toolsలో Authorization header కోసం field ఉండదు. అందువల్ల అవి ఖాళీ 401 Unauthorized తో basic authను ఉపయోగించేటప్పుడు విఫలమవుతాయి. SSH tunnelకు ఈ సమస్య ఉండదు. అందుకే ఇక్కడ ఇది default సిఫారసు.

మోడల్‌ను పొందండి, మొత్తం మార్గాన్ని తనిఖీ చేయండి

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 లోడ్ అయ్యే సమయంలో కొద్దిసేపు ఆగిన తర్వాత, /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 అంటే ఈ మూడింటిలో ఒకటి అందుబాటులో లేదని అర్థం.

మీరు చూడగల సందేశాలతో వైఫల్య పరిస్థితులు

రీబూట్ తర్వాత 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 వద్ద ప్రారంభం విఫలమవుతుంది. image pull ఇంకా కొనసాగుతున్నందున journalctl --user -u ollama.service లో Start operation timed out. Terminating. కనిపిస్తుంది. 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 సాధారణంగా OLLAMA_HOST ను container లోని loopback address కు సెట్ చేసినట్లు సూచిస్తుంది. ఆ 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] section లోని 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

నా rootless Podman container నేను logout చేసినప్పుడు ఎందుకు ఆగిపోతుంది?

ఆ వినియోగదారుడి చివరి session ముగిసినప్పుడు, అతని systemd instance మరియు దాని /run/user/<uid> directory తొలగించబడతాయి. వాటితో పాటు ప్రతి rootless container కూడా ఆగిపోతుంది. sudo loginctl enable-linger ollama ను అమలు చేసి, 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 ను జోడించి, దానికి dedicated subdirectory ఇవ్వండి. Relabelling recursive గా జరుగుతుంది. :Z ను మొత్తం home directory కి సూచిస్తే ఆ వినియోగదారుడి SSH key access పనిచేయదు. Podman named volumes కు సరైన labels ను స్వయంచాలకంగా ఇస్తుంది. వాటికి అదనపు చర్య అవసరం లేదు.

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

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

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

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

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