VPS پر rootless Podman میں Ollama کیسے چلائیں

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

سرور پر rootless Podman میں Ollama چلانے کے لیے پانچ شرائط پوری ہونی چاہییں، جنہیں desktop walkthrough میں نظرانداز کیا جا سکتا ہے۔ ایک dedicated unprivileged user container کا مالک ہو۔ اس user کے لیے lingering enabled ہو، تاکہ آپ کے log out کرنے کے بعد بھی container چلتا رہے۔ ایک Quadlet file container کو systemd کے حوالے کرے، تاکہ reboot کے بعد یہ دوبارہ چل سکے۔ ان distributions پر جہاں SELinux نافذ ہو، model directory پر درست SELinux label موجود ہو۔ API صرف loopback پر listening کرے، اور آپ 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 containers کو daemon اور root کے بغیر چلاتا ہے، اس لیے container سے باہر نکلنے والا کوئی بھی عمل ابتدا میں عام unprivileged user کے طور پر چلتا ہے۔ اگر آپ پہلے runtime comparison پڑھنا چاہتے ہیں تو VPS پر Podman اور Docker کے فرق دیکھیں۔ اگر آپ containers مکمل طور پر چھوڑنا چاہتے ہیں تو VPS پر Ollama براہِ راست انسٹال کرنا مختصر طریقہ ہے۔

SSD Nodes اپنی images میں Fedora فراہم کرتا ہے، اور Fedora میں Podman اور SELinux (security-enhanced Linux) دونوں default طور پر شامل ہوتے ہیں۔ ذیل کی ہر command ایسی distribution پر چلتی ہے جس میں Podman 5 یا اس کے بعد کا version موجود ہو۔

سرور پر laptop version میں تبدیلیاں کیوں ضروری ہیں

Fedora Magazine نے 5 August 2026 کو اس stack کی واضح رہنمائی شائع کی: Fedora Linux پر Podman کے ساتھ Ollama مقامی طور پر چلانا، جس کے مصنف Yazan Monshed ہیں۔ یہ tools کے ساتھ ابتدائی ایک گھنٹے کے لیے مفید ہے۔ تاہم اس کا ہدف laptop ہے، اور اس کے چار انتخاب public IP address والی machine پر مختلف طریقے سے کام کرتے ہیں۔

• یہ container کو سادہ podman run -d کے ساتھ start کرتا ہے۔ ہاتھ سے start کیا گیا container reboot کے بعد واپس start نہیں ہوتا، کیونکہ اسے start کرنے کی ہدایت کبھی دی ہی نہیں گئی تھی۔
• یہ بدلتے رہنے والا tag ollama/ollama استعمال کرتا ہے۔ laptop پر آپ اس دن کو محسوس کر لیتے ہیں جب behaviour تبدیل ہوتا ہے۔ server پر پہلی علامت عموماً وہ script ہوتی ہے جو راتوں رات کام کرنا چھوڑ دیتی ہے۔
• یہ -p 11434:11434 کے ساتھ publish کرتا ہے، جو ہر interface پر bind کرتا ہے۔ home router کے پیچھے یہ internet سے unreachable رہتا ہے۔ VPS پر یہ ایسا public inference API بن جاتا ہے جس پر کوئی password نہیں ہوتا۔
• یہ آپ کے اپنے login user کے طور پر چلتا ہے۔ server پر container کا مالک account کسی اور چیز کا مالک نہیں ہونا چاہیے، تاکہ break-out کی صورت میں حملہ آور خالی home directory میں پہنچے۔

اس machine کے لیے جس کے مقصد سے یہ تحریر لکھی گئی تھی، ان میں سے کوئی بات غلط نہیں۔ ہر نکتے پر صرف اس وقت دوبارہ غور کرنا ہوتا ہے جب box ہر جگہ سے reachable ہو اور اس کے سامنے کوئی موجود نہ ہو۔

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

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

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 کی ایک range درج ہونی چاہیے:

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

آپ کا starting number مختلف ہوگا، اور یہ درست ہے۔ اگر grep کوئی output نہ دے تو useradd نے کوئی range allocate نہیں کی۔ ایسی صورت میں اس user کے طور پر پہلی podman command اس طرح fail ہوگی:

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

ایسی range assign کریں جس پر کسی دوسرے user کا قبضہ نہ ہو، پھر Podman کو بتائیں کہ اس کی پرانی mapping stale ہے:

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 تک رسائی حاصل کریں۔

لاگ آؤٹ کے بعد سروس برقرار رکھنے کے لیے lingering فعال کریں

صارف کا systemd instance عموماً login کے وقت شروع ہوتا ہے اور logout کے وقت بند ہو جاتا ہے، اور /run/user/<uid> بھی اس کے ساتھ حذف ہو جاتا ہے۔ اس صارف کے زیرِ ملکیت ہر rootless container اسی وقت بند ہو جاتا ہے۔ Lingering صارف کے instance کو کسی session کے منسلک نہ ہونے کے باوجود چلتا رکھتا ہے۔

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

اس سے Linger=yes ظاہر ہونا چاہیے۔ Unit بنانے سے پہلے اسے فعال کریں، کیونکہ unit کو درکار directory، /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 کو set نہیں کرتا۔ ہر اس admin shell میں اسے دستی طور پر set کریں جہاں آپ اس سروس کا انتظام کرتے ہیں:

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

ماڈل blobs کہاں محفوظ ہوتے ہیں، اور ڈسک کی کتنی گنجائش درکار ہے

Ollama weights کو container کے اندر /root/.ollama/models میں لکھتا ہے۔ صارف کے home directory سے ایک directory اس path پر bind کریں، تاکہ files ایسی جگہ محفوظ ہوں جس کی پیمائش کی جا سکے: /home/ollama/ollama-data/models۔ Blobs content-addressed files کے طور پر models/blobs میں محفوظ ہوتے ہیں، جبکہ models/manifests میں ان کے نام رکھنے والا چھوٹا index موجود ہوتا ہے۔ اگر آپ named volume استعمال کریں، جیسا کہ Fedora Magazine کی post میں کیا گیا ہے، تو یہی tree /home/ollama/.local/share/containers/storage/volumes/<volume>/_data کے تحت موجود ہوگا۔

کچھ بھی pull کرنے سے پہلے ڈسک کی گنجائش طے کریں۔ Published download sizes کم از کم مطلوبہ گنجائش بتاتی ہیں۔

[
  {
    "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 پر published figures ہیں؛ یہ ڈسک پر ناپے گئے sizes نہیں ہیں۔ یہاں سب سے چھوٹا tag، gemma3:4b، 3.3 GB download کرتا ہے۔ سب سے بڑا، qwen3:30b، 19 GB download کرتا ہے۔ Container image اس کے علاوہ Podman کی اپنی storage میں جگہ لیتی ہے، اس لیے podman system df اور df -h /home کے ساتھ دونوں numbers چیک کریں۔ Model کے loaded ہونے کے دوران اسے تقریباً اس کے 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 استعمال کریں، 0.32.9 اگست 2026 تک، نہ کہ latest۔ pinned tag کا مطلب یہ ہے کہ 04:00 پر restart کرنے سے وہی binary ملتی ہے جسے آپ نے test کیا تھا، اس لیے behavior میں کوئی بھی تبدیلی آپ کی کی ہوئی تبدیلی ہوتی ہے۔ Docker Hub انہی versions کے لیے -rc اور -rocm tags بھی شائع کرتا ہے؛ جب تک آپ کے پاس AMD GPU نہ ہو، سادہ tag منتخب کریں۔

registry host بھی لکھیں۔ Fedora پر systemd unit میں مختصر نام کے لیے prompt دکھانے والا terminal موجود نہیں ہوتا، اس لیے unit اس error کے ساتھ fail ہو جاتی ہے:

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

پہلے دستی طور پر pull کرنا اختیاری ہے، لیکن مفید ہے، کیونکہ اس سے کئی gigabytes کی 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 پہلے ہی یہ کام انجام دیتا ہے۔ Quadlet خود daemon-reload کے دوران start-at-boot link بناتا ہے، اسی لیے یہ command اختیاری نہیں ہے۔ TimeoutStartSec=900 پہلی start کو مکمل ہونے کے لیے اضافی وقت دیتا ہے، کیونکہ اسے image pull کرنا پڑ سکتا ہے۔ دو gigabyte کے download کے لیے default 90 seconds کافی نہیں ہوتے، اور systemd start کو failed قرار دے کر ختم کر دیتا ہے۔ OLLAMA_KEEP_ALIVE=30m requests کے درمیان model کو memory میں رکھتا ہے، بجائے اس کے کہ پانچ منٹ بعد اسے unload کر دے؛ اس کے فوائد اور نقصانات 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 میں چلتا ہے، جبکہ صارف کے home میں موجود directory کو user_home_t label دیا جاتا ہے۔ Policy دونوں کو ایک دوسرے تک رسائی نہیں دیتی، اس لیے Ollama اپنا model tree نہیں بنا سکتا اور container exit ہو جاتا ہے۔ ان systems پر getenforce، Enforcing دکھاتا ہے، اور denial record ہو جاتی ہے:

sudo ausearch -m avc -ts recent

آپ کو ایک ایسی line نظر آئے گی جس میں domain اور target label درج ہوں گے:

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 کرتا ہے اور اسے private MCS (multi-category security) category دیتا ہے، جو صرف اسی container کے پاس ہوتی ہے۔ اس کے برعکس lowercase :z مشترکہ label استعمال کرتا ہے۔ جب دو containers کو ایک ہی directory پڑھنی ہو تو یہی مطلوبہ طریقہ ہے۔

:Z کے بارے میں ایک اہم انتباہ ہے، کیونکہ یہ خاموشی سے destructive کارروائی کرتا ہے۔ Relabelling recursive ہوتی ہے۔ اگر اسے /home/ollama پر چلایا جائے تو اس home directory کی ہر file relabel ہو جاتی ہے، جس سے اس صارف کے SSH key access میں خرابی پیدا ہوتی ہے۔ ہمیشہ :Z کو ایک dedicated subdirectory دیں، جس میں کوئی دوسری چیز موجود نہ ہو۔ Named volumes کو اس کی ضرورت نہیں ہوتی، کیونکہ Podman انہیں بناتے وقت درست labels لگا دیتا ہے۔ اگر آپ کو مزید تفصیل درکار ہو تو server کے لیے SELinux کی بنیادی معلومات میں contexts اور booleans کی وضاحت موجود ہے۔ Ubuntu اور Debian پر اس کے بجائے AppArmor استعمال ہوتا ہے، وہاں :Z کا کوئی اثر نہیں ہوتا، اور اسے unit میں رہنے دینا بے ضرر ہے۔

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

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

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

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

واضح طور پر متعین کریں کہ آپ کس side کو bind کر رہے ہیں۔ PublishPort میں موجود address host کا address ہے۔ container کے اندر Ollama کو تمام interfaces پر listening جاری رکھنی چاہیے؛ یہی image کی default setting ہے۔ Environment=OLLAMA_HOST=127.0.0.1 مقرر کرنے سے Ollama container کے اپنے loopback پر bind ہو جاتا ہے، جبکہ Podman published traffic کو container کے network address پر forward کرتا ہے۔ اس کے نتیجے میں host سے بھی ہر request مسترد ہو جاتی ہے۔

کھلا ہوا 11434 آپ کے لیے دو مسائل پیدا کرتا ہے۔ Ollama میں authentication نہیں ہے، اس لیے جو بھی اس پورٹ تک پہنچ سکے وہ /api/tags کے ذریعے آپ کے models کی فہرست حاصل کر سکتا ہے، /api/generate کے ذریعے آپ کے CPU اور bandwidth allowance پر inference چلا سکتا ہے، disk پر نئے models pull کر سکتا ہے، اور موجودہ models حذف کر سکتا ہے۔ دوسرا مسئلہ یہ ہے کہ remote port تک plain HTTP prompts اور completions کو cleartext میں بھیجتا ہے، اس لیے راستے میں موجود ہر machine انہیں پڑھ سکتی ہے۔ اگر پورٹ host سے باہر ہی نہ جائے تو دونوں مسائل ختم ہو جاتے ہیں۔

اپنے workstation سے SSH کے ذریعے پورٹ 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 چار سطروں پر مشتمل ہوتا ہے، اور caddy hash-password مطلوبہ bcrypt hash دکھاتا ہے:

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 نہیں ہوتی، اور وہ خالی 401 Unauthorized کے ساتھ basic auth کے خلاف ناکام ہو جائیں گے۔ SSH tunnel میں یہ مسئلہ نہیں ہوتا، اسی لیے یہاں اسے default recommendation قرار دیا گیا ہے۔

ماڈل pull کریں اور مکمل path کی جانچ کریں

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 کی فہرست شامل ہوتی ہے۔ ڈسک سے weights load ہونے کے دوران کچھ وقفے کے بعد /api/generate ایک JSON object واپس کرتا ہے، جس میں response field شامل ہوتی ہے۔ du کو published download size کے قریب کوئی number report کرنا چاہیے۔ اب اس پورے 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 کا مطلب ہے کہ ان تینوں میں سے ایک موجود نہیں ہے۔

خرابی کی صورتیں اور نظر آنے والے strings

ریبوٹ کے بعد container غائب ہے۔ پہلے loginctl show-user ollama --property=Linger دیکھیں، کیونکہ Linger=yes کے بغیر صارف کا systemd instance boot کے وقت کبھی شروع نہیں ہوتا۔ اگر lingering فعال ہے، .container file میں [Install] section موجود نہیں، یا آپ نے file میں ترمیم کی ہے لیکن 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 ناکام ہو جاتا ہے۔ Start operation timed out. Terminating. میں journalctl --user -u ollama.service دکھائی دیتا ہے، کیونکہ image pull ابھی جاری تھا۔ اسے دستی طور پر pull کریں، یا TimeoutStartSec=900 برقرار رکھیں۔

container شروع ہو کر بند ہو جاتا ہے۔ podman logs ollama اور sudo ausearch -m avc -ts recent سے مل کر معلوم ہوتا ہے کہ مسئلہ SELinux label کا ہے یا نہیں۔ 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 پر set کیا گیا ہے۔ وہ line ہٹا دیں۔

generation بہت سست ہے، یا container kill ہو جاتا ہے۔ GPU نہ ہونے کی صورت میں inference CPU پر چلتی ہے اور بڑا model فطری طور پر سست ہوتا ہے۔ اگر request کے دوران container بند ہو جائے اور logs میں signal: killed موجود ہو، تو یہ kernel کا out-of-memory killer ہے۔ اس لیے اوپر دیے گئے chart سے چھوٹا tag منتخب کریں۔

پِن کی گئی image کو update کرنا

Pinning کا مطلب یہ ہے کہ updates آپ کی مرضی سے کیے جاتے ہیں، خود بخود نہیں ہوتے۔ ollama.container میں Image= کو edit کریں، پھر 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 کا content کبھی تبدیل نہیں ہوتا۔ /home/ollama/ollama-data/models/manifests اور .container file کا backup لیں، لیکن blobs کو چھوڑ دیں۔ یہ بڑی ہوتی ہیں، اور ollama pull انہیں نئے box پر دوبارہ fetch کر لیتا ہے۔

FAQ

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

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

کیا 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 operation مسترد ہو جاتی ہے اور Ollama بند ہو جاتا ہے۔ :Z کو Volume= line کے آخر میں شامل کریں اور اس کے لیے الگ subdirectory استعمال کریں، کیونکہ relabelling اندر موجود تمام directories پر بھی لاگو ہوتی ہے اور :Z کو پورے home directory پر مقرر کرنے سے اس صارف کے SSH key access میں خرابی پیدا ہو جاتی ہے۔ Podman named volumes کو درست labels دیتا ہے، اس لیے ان کے لیے اضافی configuration درکار نہیں۔

Ollama model کے لیے کتنی disk درکار ہوتی ہے؟

ollama.com/library پر شائع شدہ download size سے آغاز کریں۔ یہ 3.3 GB، gemma3:4b کے لیے، سے لے کر 19 GB، qwen3:30b کے لیے، تک ہوتی ہے۔ اس کے علاوہ Podman image کے لیے بھی disk space رکھیں، پھر کچھ اضافی گنجائش چھوڑیں، کیونکہ دوسرا model disk پر پہلے model کی جگہ نہیں لیتا۔ Pull کرنے سے پہلے df -h /home اور اس کے بعد du -sh ~/ollama-data/models چیک کریں۔ RAM کی منصوبہ بندی بھی اسی طرح کریں: loaded ہونے کے دوران ایک model کو تقریباً اپنی file size کے برابر memory درکار ہوتی ہے، اس کے علاوہ context window کے لیے بھی memory چاہیے۔

کیا VPS پر port 11434 کو public کرنا محفوظ ہے؟

نہیں۔ Ollama میں کسی بھی قسم کی authentication شامل نہیں ہوتی، اس لیے جو بھی اس port تک پہنچ سکے وہ آپ کے models کی فہرست دیکھ سکتا ہے، انہیں حذف کر سکتا ہے، آپ کی disk پر نئے models pull کر سکتا ہے، اور آپ کے CPU اور bandwidth allowance پر inference چلا سکتا ہے۔ Internet پر plain HTTP ہر prompt اور completion کو cleartext میں بھیجتا ہے۔ Host side کو 127.0.0.1 پر PublishPort=127.0.0.1:11434:11434 کے ساتھ bind کریں، ss -ltnp | grep 11434 سے تصدیق کریں، اور SSH tunnel یا ایسے reverse proxy کے ذریعے اس تک رسائی دیں جو password کا تقاضا کرے۔