تحریر: Matt Connor 2026-08-13 · اپ ڈیٹ شدہ 2026-09-04

VPS پر rootless Podman میں Ollama چلانے کا طریقہ

Q: جب میں لاگ آؤٹ کرتا ہوں تو میرا rootless Podman کنٹینر کیوں رک جاتا ہے؟

صارف کا systemd انسٹینس اور اس کی /run/user/ ڈائریکٹری اس وقت ختم کر دی جاتی ہے جب اس صارف کا آخری سیشن ختم ہوتا ہے، اور ہر rootless کنٹینر بھی ان کے ساتھ ہی ختم ہو جاتا ہے۔ sudo loginctl enable-linger ollama چلائیں اور تصدیق کریں کہ loginctl show-user ollama --property=Linger آؤٹ پٹ میں Linger=yes دکھاتا ہے۔ Quadlet یونٹ بنانے سے پہلے lingering کو فعال کریں، کیونکہ یونٹ کو درکار رن ٹائم ڈائریکٹری صرف اسی صورت میں موجود رہتی ہے جب lingering آن ہو۔

VPS پر rootless Podman کے ذریعے Ollama چلانے کا مکمل طریقہ کار سیکھیں۔ Quadlet یونٹ، lingering کنفیگریشن، SELinux لیبلز اور SSH ٹنلنگ کے ذریعے محفوظ رسائی حاصل کریں۔

VPS پر rootless Podman میں Ollama چلانا

سرور پر rootless Podman میں Ollama چلانے کے لیے 5 ایسی شرائط کا پورا ہونا ضروری ہے جنہیں ڈیسک ٹاپ کے عام طریقہ کار میں نظر انداز کر دیا جاتا ہے۔ ایک مخصوص unprivileged صارف کنٹینر کا مالک ہوتا ہے۔ اس صارف کے لیے lingering فعال ہوتی ہے تاکہ آپ کے لاگ آؤٹ ہونے کے بعد بھی کنٹینر چلتا رہے۔ ایک Quadlet فائل کنٹینر کو systemd کے حوالے کرتی ہے، جس سے ریبوٹ کے بعد یہ خود بخود دوبارہ شروع ہو جاتا ہے۔ ماڈل ڈائریکٹری پر SELinux لیبل لگا ہوتا ہے (ان ڈسٹری بیوشنز پر جہاں یہ نافذ ہو)۔ API صرف loopback پر listen کرتی ہے، اور آپ اس تک SSH (secure shell) ٹنل کے ذریعے رسائی حاصل کرتے ہیں۔

Ollama بڑے لینگویج ماڈلز (LLM) کے لیے ایک سرور ہے۔ یہ ماڈل ویٹس کو ڈسک پر محفوظ کرتا ہے، انہیں میموری میں لوڈ کرتا ہے، اور port 11434 پر HTTP درخواستوں کا جواب دیتا ہے۔ اس میں کوئی لاگ ان، API کی، یا صارف اکاؤنٹس نہیں ہوتے، لہذا نیٹ ورک ہی واحد رسائی کنٹرول ہے۔ Podman بغیر کسی ڈیمن اور بغیر root کے کنٹینرز چلاتا ہے، اس لیے اگر کوئی چیز کنٹینر سے باہر نکلتی بھی ہے تو وہ ایک عام unprivileged صارف کے طور پر شروع ہوتی ہے۔ اگر آپ پہلے رن ٹائم کا موازنہ دیکھنا چاہتے ہیں تو VPS پر Podman اور Docker میں فرق پڑھیں۔ اگر آپ کنٹینرز سے مکمل گریز کرنا چاہتے ہیں تو VPS پر براہ راست Ollama انسٹال کرنا ایک مختصر راستہ ہے۔

SSD Nodes اپنی امیجز میں Fedora فراہم کرتا ہے، اور Fedora میں Podman اور SELinux (security-enhanced Linux) دونوں پہلے سے موجود ہوتے ہیں۔ نیچے دی گئی ہر کمانڈ Podman 5 یا اس سے نئے ورژن والی کسی بھی ڈسٹری بیوشن پر کام کرتی ہے۔

سرور پر لیپ ٹاپ ورژن میں تبدیلیوں کی ضرورت کیوں ہے

Fedora Magazine نے 5 اگست 2026 کو اس اسٹیک پر ایک واضح گائیڈ شائع کی: Running Ollama Locally with Podman on Fedora Linux، جسے Yazan Monshed نے لکھا ہے۔ یہ ان ٹولز کے ساتھ ابتدائی ایک گھنٹے کے تجربے کے لیے بہترین ہے۔ تاہم، یہ ایک لیپ ٹاپ کو ہدف بناتی ہے، اور اس کے چار انتخاب ایک ایسی مشین پر مختلف انداز میں کام کرتے ہیں جس کا IP ایڈریس عوامی (public) ہو۔

یہ کنٹینر کو ایک سادہ podman run -d کے ساتھ شروع کرتی ہے۔ ہاتھ سے شروع کیا گیا کنٹینر ریبوٹ کے بعد خود بخود واپس نہیں آتا، کیونکہ اسے شروع کرنے کے لیے کوئی ہدایت نہیں دی گئی ہوتی۔
یہ متحرک ٹیگ ollama/ollama استعمال کرتی ہے۔ لیپ ٹاپ پر آپ کو اسی دن معلوم ہو جاتا ہے جب رویہ تبدیل ہوتا ہے۔ سرور پر اس کی پہلی علامت ایک ایسی اسکرپٹ ہے جو راتوں رات کام کرنا چھوڑ دیتی ہے۔
یہ -p 11434:11434 کے ساتھ پبلش کرتی ہے، جو ہر انٹرفیس کو بائنڈ کر دیتا ہے۔ ہوم راؤٹر کے پیچھے یہ انٹرنیٹ سے ناقابل رسائی ہوتا ہے۔ VPS پر یہ بغیر پاس ورڈ کے ایک عوامی inference API بن جاتا ہے۔
یہ آپ کے اپنے لاگ ان صارف کے طور پر چلتی ہے۔ سرور پر، کنٹینر کی مالک اکاؤنٹ کو کسی اور چیز کا مالک نہیں ہونا چاہیے، تاکہ اگر کوئی بریک آؤٹ ہو تو وہ ایک خالی ہوم ڈائریکٹری تک محدود رہے۔

جس مشین کے لیے یہ لکھا گیا تھا، اس کے لحاظ سے ان میں سے کوئی بھی چیز غلط نہیں ہے۔ ہر آئٹم محض ایک ایسا فیصلہ ہے جس پر آپ اس وقت نظر ثانی کرتے ہیں جب مشین ہر جگہ سے قابل رسائی ہو اور اس کے سامنے کوئی موجود نہ ہو۔

غیر مراعات یافتہ صارف بنائیں اور subuid چیک کریں

Rootless Podman کنٹینر کے اندرونی user IDs (UID) کو ہوسٹ پر موجود غیر استعمال شدہ IDs کے ایک بلاک پر میپ کرتا ہے۔ اس بلاک کا اعلان /etc/subuid اور /etc/subgid میں کیا جاتا ہے۔ اس کے بغیر، rootless کنٹینرز بالکل شروع نہیں ہو سکتے۔

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 کو دو لائنیں پرنٹ کرنی چاہئیں، ہر فائل سے ایک، جن میں سے ہر ایک 65536 IDs کی رینج ظاہر کرے:

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

آپ کا ابتدائی نمبر مختلف ہو سکتا ہے، اور یہ ٹھیک ہے۔ اگر grep کچھ بھی پرنٹ نہ کرے، تو useradd نے کوئی رینج مختص نہیں کی، اور اس صارف کے طور پر پہلا podman کمانڈ اس طرح ناکام ہو جائے گا:

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

ایک ایسی رینج تفویض کریں جو کسی اور صارف کے پاس نہ ہو، پھر Podman کو بتائیں کہ اس کی پرانی میپنگ پرانی ہو چکی ہے:

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

پاس ورڈ کو لاک کرنے کا مطلب ہے کہ کوئی بھی براہ راست ollama کے طور پر لاگ ان نہیں ہو سکتا۔ آپ اپنے ایڈمن صارف سے sudo -iu ollama کے ذریعے اس اکاؤنٹ تک رسائی حاصل کرتے ہیں۔

Lingering کو فعال کریں تاکہ سروس لاگ آؤٹ کے بعد بھی چلتی رہے

صارف کا systemd instance عام طور پر لاگ ان پر شروع ہوتا ہے اور لاگ آؤٹ پر بند ہو جاتا ہے، اور اس کے ساتھ ہی /run/user/<uid> بھی ختم ہو جاتا ہے۔ اس صارف کی ملکیت میں موجود ہر rootless container اسی لمحے بند ہو جاتا ہے۔ Lingering صارف کے instance کو بغیر کسی فعال session کے چلتا رکھتی ہے۔

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

اس کمانڈ کو Linger=yes پرنٹ کرنا چاہیے۔ اسے unit بنانے سے پہلے فعال کریں، کیونکہ جس ڈائریکٹری کی unit کو ضرورت ہوتی ہے، یعنی /run/user/<uid>، وہ صرف اس وقت موجود ہوتی ہے جب 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 صارف کی bus کو $XDG_RUNTIME_DIR/bus پر تلاش کرتا ہے، اور sudo -i اس متغیر (variable) کو سیٹ نہیں کرتا۔ ہر اس admin shell میں اسے دستی طور پر سیٹ کریں جہاں آپ اس سروس کو manage کرتے ہیں:

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

ماڈل بلاب کہاں محفوظ ہوتے ہیں، اور کتنی ڈسک اسپیس درکار ہے

Ollama وزن (weights) کو کنٹینر کے اندر /root/.ollama/models میں لکھتا ہے۔ صارف کی ہوم ڈائریکٹری سے ایک ڈائریکٹری کو اس پاتھ پر bind کریں تو فائلیں ایسی جگہ محفوظ ہوں گی جہاں آپ ان کی پیمائش کر سکیں: /home/ollama/ollama-data/models۔ بلاب models/blobs میں content-addressed فائلز کے طور پر جاتے ہیں، اور models/manifests میں وہ چھوٹا انڈیکس ہوتا ہے جو ان کے نام متعین کرتا ہے۔ اگر آپ Fedora Magazine کی پوسٹ کی طرح named volume استعمال کریں، تو یہی ٹری /home/ollama/.local/share/containers/storage/volumes/<volume>/_data کے نیچے موجود ہوتا ہے۔ بہرصورت ollama pull اور ollama run وزن کو ایک ہی ٹری میں لکھتے ہیں، اور دونوں کمانڈز میں فرق صرف یہ ہے کہ ڈاؤن لوڈ مکمل ہونے پر چیٹ سیشن کھلتا ہے یا نہیں۔

کچھ بھی pull کرنے سے پہلے ڈسک کا سائز طے کر لیں۔ شائع شدہ ڈاؤن لوڈ سائز آپ کو کم از کم حد بتاتے ہیں۔

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 پر شائع کردہ اعداد و شمار ہیں، نہ کہ ڈسک پر ماپی گئی سائز۔ یہاں سب سے چھوٹا ٹیگ، gemma3:4b، 3.3 GB ڈاؤن لوڈ کرتا ہے۔ سب سے بڑا، qwen3:30b، 19 GB ڈاؤن لوڈ کرتا ہے۔ کنٹینر امیج خود Podman کی اپنی اسٹوریج میں اس کے اوپر موجود ہوتا ہے، لہذا podman system df اور df -h /home کے ساتھ دونوں نمبرز کو ایک ساتھ چیک کریں۔ ایک ماڈل کو لوڈ ہونے کے دوران تقریباً اپنی فائل سائز کے برابر RAM درکار ہوتی ہے، اس کے علاوہ context window کے لیے اضافی جگہ بھی چاہیے، لہذا 16 GB کے VPS پر 19 GB کا ماڈل نہیں چل سکے گا۔

Image tag کو پن کریں اور مکمل 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 استعمال کریں، جو اگست 2026 تک 0.32.9 ہے، نہ کہ latest۔ Pinned tag کا مطلب یہ ہے کہ 04:00 بجے restart کرنے پر آپ کو وہی binary ملے گی جس کی آپ نے جانچ کی تھی، لہذا رویے میں کوئی بھی تبدیلی آپ کی اپنی کی ہوئی تبدیلی ہوگی۔ Docker Hub انہی ورژنز کے لیے -rc اور -rocm ٹیگز بھی شائع کرتا ہے؛ اگر آپ کے پاس AMD GPU نہیں ہے تو سادہ ٹیگ کا انتخاب کریں۔

Registry host کا نام بھی لکھیں۔ Fedora پر systemd unit میں مختصر نام استعمال کرنے سے terminal پر کوئی prompt ظاہر نہیں ہوتا، اور unit درج ذیل غلطی کے ساتھ ناکام ہو جاتی ہے:

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

دستی طور پر pull کرنا اختیاری ہے لیکن مفید ہے، کیونکہ یہ کئی گیگا بائٹس کی ڈاؤن لوڈ کو unit کے start timeout سے باہر نکال دیتا ہے۔

وہ Quadlet یونٹ جو ریبوٹ کے بعد بھی برقرار رہتا ہے

Quadlet دراصل Podman کا systemd جنریٹر ہے۔ آپ ایک .container فائل لکھتے ہیں، systemd اسے بوٹ کے وقت ایک سروس میں تبدیل کر دیتا ہے، اور پھر podman generate systemd کی ضرورت باقی نہیں رہتی۔ اسے /home/ollama/.config/containers/systemd/ollama.container کے طور پر محفوظ کریں، جس کا مالک 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

فائل کا نام سروس کا نام متعین کرتا ہے، لہذا 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 کو مت چلائیں۔ یہ یونٹ ڈسک پر فائل کے طور پر موجود نہیں ہوتا، اس لیے systemd اسے چلانے سے انکار کر دیتا ہے:

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

[Install] سیکشن پہلے ہی یہ کام کر دیتا ہے۔ Quadlet خود daemon-reload کے دوران بوٹ پر اسٹارٹ ہونے والا لنک بنا دیتا ہے، اسی لیے یہ کمانڈ اختیاری نہیں ہے۔ TimeoutStartSec=900 پہلی بار اسٹارٹ ہونے کے عمل کا احاطہ کرتا ہے جس میں امیج ڈاؤن لوڈ کرنا پڑتا ہے، کیونکہ 90 سیکنڈ کا ڈیفالٹ وقت دو گیگا بائٹ کی ڈاؤن لوڈنگ کے لیے کافی نہیں ہے اور systemd اسٹارٹ کو ناکام قرار دے کر ختم کر دے گا۔ OLLAMA_KEEP_ALIVE=30m ماڈل کو پانچ منٹ بعد ان لوڈ کرنے کے بجائے درخواستوں کے درمیان میموری میں رکھتا ہے؛ اس کے فوائد و نقصانات Ollama ماڈل کو میموری میں رکھنے کے بارے میں سیکشن میں موجود ہیں۔ اگر یہاں استعمال ہونے والی systemd کی اصطلاحات نئی ہیں، تو VPS پر systemd سروسز اور ٹائمرز کیسے کام کرتے ہیں میں یونٹس کی تفصیل موجود ہے۔

SELinux کے تحت ماڈل ڈائریکٹری میں permission denied کیوں آتا ہے

Fedora، RHEL، Rocky اور AlmaLinux پر SELinux بائی ڈیفالٹ نافذ ہوتا ہے۔ ایک کنٹینر پروسیس container_t ڈومین میں چلتا ہے، اور صارف کی ہوم ڈائریکٹری میں موجود ایک ڈائریکٹری پر user_home_t کا لیبل لگا ہوتا ہے۔ پالیسی ایک کو دوسرے تک رسائی کی اجازت نہیں دیتی، اس لیے Ollama اپنا ماڈل ٹری نہیں بنا سکتا اور کنٹینر بند ہو جاتا ہے۔ ان سسٹمز پر getenforce کمانڈ Enforcing پرنٹ کرتی ہے، اور یہ رکاوٹ ریکارڈ ہو جاتی ہے:

sudo ausearch -m avc -ts recent

آپ کو ایک لائن نظر آئے گی جس میں ڈومین اور ٹارگٹ لیبل کا نام ہوگا:

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= لائن کے آخر میں موجود :Z اس کا حل ہے۔ یہ ہوسٹ ڈائریکٹری کو container_file_t پر دوبارہ لیبل کرتا ہے اور اس پر ایک پرائیویٹ MCS (ملٹی کیٹیگری سیکیورٹی) کیٹیگری کی مہر لگاتا ہے جو صرف اسی کنٹینر کے پاس ہوتی ہے۔ چھوٹے حروف والا :z اس کے بجائے ایک مشترکہ لیبل استعمال کرتا ہے، جو اس وقت درکار ہوتا ہے جب دو کنٹینرز ایک ہی ڈائریکٹری کو پڑھ رہے ہوں۔

:Z کے بارے میں ایک انتباہ، کیونکہ یہ عمل تباہ کن اور خاموش ہے۔ دوبارہ لیبلنگ (Relabelling) ریکرسیو ہوتی ہے۔ اگر آپ اسے /home/ollama کی طرف اشارہ کریں گے تو اس ہوم ڈائریکٹری کی ہر فائل دوبارہ لیبل ہو جائے گی، جس سے اس صارف کی SSH کی رسائی ختم ہو جائے گی۔ ہمیشہ :Z کو ایک مخصوص سب ڈائریکٹری دیں جس میں کچھ اور نہ ہو۔ Named volumes کو اس کی ضرورت نہیں ہوتی، کیونکہ Podman انہیں بناتے وقت خود بخود درست لیبل لگا دیتا ہے۔ اگر آپ کو مزید تفصیل درکار ہو تو SELinux basics for a server سیاق و سباق اور بولینز کی وضاحت کرتا ہے۔ Ubuntu اور Debian پر اس کے بجائے AppArmor استعمال ہوتا ہے، وہاں :Z کا کوئی اثر نہیں ہوتا، اور اسے یونٹ فائل میں چھوڑ دینا نقصان دہ نہیں ہے۔

Port 11434 کو بند کریں اور SSH کے ذریعے API تک رسائی حاصل کریں

PublishPort=127.0.0.1:11434:11434 ہوسٹ سائیڈ کو loopback پر bind کرتا ہے۔ اس کی تصدیق کریں:

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

ss کا آؤٹ پٹ 127.0.0.1:11434 دکھانا چاہیے۔ 0.0.0.0:11434 یا *:11434 کا مطلب ہے کہ پورٹ انٹرنیٹ کے لیے کھلا ہے، اور curl کو Ollama is running جواب دینا چاہیے۔

اس بارے میں محتاط رہیں کہ آپ کس سائیڈ کو bind کر رہے ہیں۔ PublishPort میں دیا گیا ایڈریس ہوسٹ کا ایڈریس ہے۔ کنٹینر کے اندر، Ollama کو تمام انٹرفیسز پر سننا (listen) جاری رکھنا چاہیے، جو کہ امیج کی ڈیفالٹ سیٹنگ ہے۔ Environment=OLLAMA_HOST=127.0.0.1 سیٹ کرنے سے Ollama کنٹینر کے اپنے loopback پر bind ہو جاتا ہے، اور Podman پبلش شدہ ٹریفک کو کنٹینر کے نیٹ ورک ایڈریس پر فارورڈ کرتا ہے، جس کی وجہ سے ہر درخواست ہوسٹ سے بھی مسترد (refuse) ہو جاتی ہے۔

ایک کھلا 11434 پورٹ آپ کو دو طریقوں سے نقصان پہنچاتا ہے۔ Ollama میں کوئی authentication نہیں ہے، لہذا جو بھی اس پورٹ تک پہنچے وہ /api/tags کے ذریعے آپ کے ماڈلز کی فہرست دیکھ سکتا ہے، /api/generate کے ذریعے آپ کے CPU اور بینڈوتھ الاؤنس پر inference چلا سکتا ہے، آپ کی ڈسک پر نئے ماڈلز ڈاؤن لوڈ کر سکتا ہے، اور موجودہ ماڈلز کو ڈیلیٹ کر سکتا ہے۔ دوسرا، ریموٹ پورٹ پر plain HTTP پرامپٹس اور completions کو cleartext میں بھیجتا ہے، لہذا راستے میں موجود ہر مشین انہیں پڑھ سکتی ہے۔ اگر پورٹ کبھی بھی سرور سے باہر نہ نکلے تو یہ دونوں مسائل ختم ہو جاتے ہیں۔

اپنے ورک سٹیشن سے، SSH کے ذریعے پورٹ کو فارورڈ کریں:

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

اب آپ کے لیپ ٹاپ پر http://127.0.0.1:11434 سرور کا Ollama ہے، جو SSH سیشن کی انکرپشن کے اندر ہے۔ اگر آپ کا لیپ ٹاپ پہلے سے Ollama چلا رہا ہے، تو لوکل bind bind [127.0.0.1]:11434: Address already in use کے ساتھ ناکام ہو جائے گا؛ -L 11435:127.0.0.1:11434 استعمال کریں اور اپنے کلائنٹ کو 11435 کی طرف پوائنٹ کریں۔

جب کسی براؤزر کلائنٹ کو اس کی ضرورت ہو، تو اس کے سامنے پاس ورڈ کے ساتھ ایک reverse proxy لگا دیں۔ Caddy سائٹ بلاک چار لائنوں پر مشتمل ہے، اور caddy hash-password وہ bcrypt ہیش پرنٹ کرتا ہے جس کی اسے ضرورت ہے:

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

Caddy خود بخود TLS (ٹرانسپورٹ لیئر سیکیورٹی) پر سرٹیفکیٹ حاصل کر لیتا ہے، لہذا ٹریفک انکرپٹڈ ہوتی ہے۔ پہلے اپنے کلائنٹ کو ٹیسٹ کریں: Ollama سے بات کرنے والے بہت سے ٹولز میں Authorization ہیڈر کے لیے کوئی فیلڈ نہیں ہوتی، اور وہ basic auth کے ساتھ ایک سادہ 401 Unauthorized پر ناکام ہو جائیں گے۔ SSH ٹنل میں ایسا کوئی مسئلہ نہیں ہے، اسی لیے یہاں اسے ڈیفالٹ تجویز کیا گیا ہے۔

ماڈل کو پل (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 ایک JSON لسٹنگ واپس کرتا ہے جس میں gemma3:4b شامل ہوتا ہے۔ /api/generate ایک JSON آبجیکٹ واپس کرتا ہے جس میں response فیلڈ ہوتی ہے، یہ اس وقت ہوتا ہے جب ڈسک سے ویٹس (weights) لوڈ ہونے کے دوران کچھ دیر کا وقفہ آتا ہے۔ du کو شائع شدہ ڈاؤن لوڈ سائز کے قریب ایک نمبر رپورٹ کرنا چاہیے۔ اس کے بعد اس حصے کو ثابت کریں جس کے بارے میں یہ مکمل گائیڈ ہے:

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

active کا مطلب ہے کہ عمل جاری ہے، [Install] سیکشن اور daemon-reload سب نے اپنا کام مکمل کر لیا ہے۔ inactive کا مطلب ہے کہ ان تینوں میں سے کوئی ایک غائب ہے۔

ناکامی کے طریقے اور وہ اسٹرنگز جو آپ دیکھیں گے

ریبوٹ کے بعد کنٹینر غائب ہے۔ سب سے پہلے loginctl show-user ollama --property=Linger چیک کریں، کیونکہ Linger=yes کے بغیر صارف کا systemd instance بوٹ پر کبھی شروع نہیں ہوتا۔ اگر lingering فعال ہے، تو .container فائل سے [Install] سیکشن غائب ہے، یا آپ نے فائل میں ترمیم کی ہے لیکن systemctl --user daemon-reload نہیں چلایا۔

Error: statfs /home/ollama/ollama-data: no such file or directory۔ کنٹینر شروع ہونے سے پہلے بائنڈ ماؤنٹ (bind mount) کا سورس موجود ہونا چاہیے۔ Podman آپ کے لیے ہوسٹ ڈائریکٹریز نہیں بناتا۔ ollama صارف کے طور پر mkdir -p ~/ollama-data چلائیں۔

90 سیکنڈ پر اسٹارٹ ناکام ہو جاتا ہے۔ journalctl --user -u ollama.service میں Start operation timed out. Terminating. ظاہر ہوتا ہے کیونکہ امیج پل (image pull) ابھی جاری تھی۔ دستی طور پر پل کریں، یا TimeoutStartSec=900 کو برقرار رکھیں۔

کنٹینر شروع ہو کر بند ہو جاتا ہے۔ podman logs ollama اور sudo ausearch -m avc -ts recent مل کر آپ کو بتاتے ہیں کہ آیا یہ SELinux لیبل کا مسئلہ ہے۔ AVC میں container_t اور user_home_t کا ذکر ہونے کا مطلب ہے کہ :Z غائب ہے۔

ہوسٹ سے درخواستیں مسترد کر دی جاتی ہیں۔ active سروس کے ساتھ curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused کا مطلب عام طور پر یہ ہوتا ہے کہ OLLAMA_HOST کو کنٹینر کے اندر لوپ بیک ایڈریس پر سیٹ کیا گیا تھا۔ اس لائن کو ہٹا دیں۔

جنریشن بہت سست ہے، یا کنٹینر کل (kill) ہو جاتا ہے۔ GPU کے بغیر، انفرنس CPU پر چلتی ہے اور ایک بڑا ماڈل فطری طور پر سست ہوتا ہے۔ اگر کنٹینر درخواست کے دوران لاگز میں signal: killed کے ساتھ بند ہو جائے، تو یہ کرنل کا out-of-memory killer ہے، لہذا اوپر دیے گئے چارٹ سے چھوٹا ٹیگ منتخب کریں۔

Pinned image کو اپ ڈیٹ کرنا

Pinning کا مطلب ہے کہ اپ ڈیٹس آپ کا ایک فعال عمل ہیں، نہ کہ کوئی خودکار واقعہ۔ Image= کو ollama.container میں ایڈٹ کریں، پھر 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 کا مواد کبھی تبدیل نہیں ہوتا۔ /home/ollama/ollama-data/models/manifests اور .container فائل کا بیک اپ لیں، اور blobs کو چھوڑ دیں: یہ بڑے ہوتے ہیں، اور کسی نئے box پر ollama pull انہیں دوبارہ fetch کر لیتا ہے۔

FAQ

جب میں لاگ آؤٹ کرتا ہوں تو میرا rootless Podman کنٹینر کیوں رک جاتا ہے؟

صارف کا systemd انسٹینس اور اس کی /run/user/<uid> ڈائریکٹری اس وقت ختم کر دی جاتی ہے جب اس صارف کا آخری سیشن ختم ہوتا ہے، اور ہر rootless کنٹینر بھی ان کے ساتھ ہی ختم ہو جاتا ہے۔ sudo loginctl enable-linger ollama چلائیں اور تصدیق کریں کہ loginctl show-user ollama --property=Linger آؤٹ پٹ میں Linger=yes دکھاتا ہے۔ Quadlet یونٹ بنانے سے پہلے lingering کو فعال کریں، کیونکہ یونٹ کو درکار رن ٹائم ڈائریکٹری صرف اسی صورت میں موجود رہتی ہے جب lingering آن ہو۔

کیا مجھے Ollama ماڈل ڈائریکٹری پر SELinux لیبلز کی ضرورت ہے؟

Fedora، RHEL، Rocky اور AlmaLinux پر، جی ہاں، اگر آپ ہوسٹ ڈائریکٹری کو bind mount کر رہے ہیں۔ کنٹینر container_t ڈومین میں چلتا ہے اور ہوم فولڈر میں موجود ڈائریکٹری کو user_home_t لیبل دیا جاتا ہے، اس لیے رائٹ (write) کی اجازت نہیں ملتی اور Ollama بند ہو جاتا ہے۔ :Z کو Volume= لائن میں شامل کریں اور اسے ایک مخصوص سب ڈائریکٹری دیں، کیونکہ relabelling ریکرسیو (recursive) ہوتی ہے اور :Z کو پوری ہوم ڈائریکٹری پر پوائنٹ کرنے سے اس صارف کی SSH کی رسائی ٹوٹ جاتی ہے۔ Named volumes کو Podman خود بخود درست لیبل لگا دیتا ہے اور انہیں کسی اضافی چیز کی ضرورت نہیں ہوتی۔

Ollama ماڈل کو کتنی ڈسک درکار ہوتی ہے؟

ollama.com/library پر شائع شدہ ڈاؤن لوڈ سائز سے شروع کریں، جو gemma3:4b کے لیے 3.3 GB سے لے کر qwen3:30b کے لیے 19 GB تک ہوتا ہے۔ اس کے اوپر Podman امیج کا سائز شامل کریں، پھر اضافی گنجائش رکھیں، کیونکہ دوسرا ماڈل ڈسک پر پہلے والے کی جگہ نہیں لیتا۔ پل (pull) کرنے سے پہلے df -h /home اور بعد میں du -sh ~/ollama-data/models چیک کریں۔ RAM کا منصوبہ بھی اسی طرح بنائیں: ایک ماڈل کو لوڈ ہونے کے دوران تقریباً اپنی فائل سائز کے برابر میموری درکار ہوتی ہے، اس کے علاوہ کانٹیکسٹ ونڈو (context window) کی میموری الگ ہے۔

کیا VPS پر پورٹ 11434 کو ایکسپوز کرنا محفوظ ہے؟

نہیں۔ Ollama کسی بھی قسم کی تصدیق (authentication) کے بغیر آتا ہے، لہذا جو بھی اس پورٹ تک پہنچے گا وہ آپ کے ماڈلز کی فہرست دیکھ سکتا ہے، انہیں حذف کر سکتا ہے، آپ کی ڈسک پر نئے ماڈلز ڈاؤن لوڈ کر سکتا ہے، اور آپ کے CPU اور بینڈوتھ الاؤنس پر inference چلا سکتا ہے۔ انٹرنیٹ پر سادہ HTTP ہر پرامپٹ اور تکمیل کو بھی پلین ٹیکسٹ میں بھیجتا ہے۔ ہوسٹ سائیڈ کو 127.0.0.1 کے ساتھ PublishPort=127.0.0.1:11434:11434 پر بائنڈ کریں، ss -ltnp | grep 11434 کے ساتھ تصدیق کریں، اور اس تک SSH ٹنل یا ایسے ریورس پراکسی کے ذریعے رسائی حاصل کریں جس کے لیے پاس ورڈ درکار ہو۔

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