द्वारे Matt Connor 2026-08-13 · अपडेटेड 2026-09-04

VPS वर rootless Podman मध्ये Ollama कसे चालवावे

VPS वर rootless Podman वापरून Ollama सुरक्षितपणे चालवण्याची पद्धत शिका. यात lingering, Quadlet युनिट्स, SELinux लेबल्स आणि SSH टनेलिंगद्वारे सुरक्षित ॲक्सेसची माहिती दिली आहे.

VPS वर rootless Podman मध्ये Ollama चालवणे

सर्व्हरवर rootless Podman मध्ये Ollama चालवण्यासाठी अशा पाच गोष्टींची पूर्तता होणे आवश्यक आहे, ज्या डेस्कटॉप मार्गदर्शकांमध्ये सहसा वगळल्या जातात. कंटेनरची मालकी एका समर्पित unprivileged युजरकडे असते. त्या युजरसाठी lingering सक्षम केलेले असते, जेणेकरून तुम्ही लॉग आउट केल्यानंतरही कंटेनर चालू राहतो. एक Quadlet फाईल कंटेनरचे नियंत्रण systemd कडे सोपवते, ज्यामुळे रीबूटनंतर तो पुन्हा सुरू होतो. ज्या डिस्ट्रिब्युशन्समध्ये SELinux लागू आहे, तिथे मॉडेल डिरेक्टरीवर योग्य SELinux लेबल असणे आवश्यक असते. API फक्त loopback वर ऐकते (listen करते) आणि तुम्ही SSH (secure shell) टनेलद्वारे त्यापर्यंत पोहोचता.

Ollama हे लार्ज लँग्वेज मॉडेल्स (LLM) साठीचे एक सर्व्हर आहे. ते मॉडेल वेट्स डिस्कवर साठवते, मेमरीमध्ये लोड करते आणि पोर्ट 11434 वर HTTP विनंत्यांना प्रतिसाद देते. यामध्ये कोणतीही लॉगिन सुविधा, API की किंवा युजर अकाउंट्स नसतात, त्यामुळे नेटवर्क हेच तुमच्याकडे असलेले एकमेव ॲक्सेस कंट्रोल असते. Podman कंटेनर कोणत्याही डेमनशिवाय आणि रूटशिवाय चालवते, त्यामुळे कंटेनरमधून बाहेर पडणारी कोणतीही गोष्ट एका सामान्य unprivileged युजरच्या अधिकारांसह सुरू होते. जर तुम्हाला आधी रनटाइमची तुलना वाचायची असेल, तर VPS वर Podman आणि Docker मधील फरक वाचा. जर तुम्हाला कंटेनर पूर्णपणे टाळायचे असतील, तर Ollama थेट VPS वर इन्स्टॉल करणे हा एक सोपा मार्ग आहे.

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 ॲड्रेस असलेल्या मशीनवर वेगळ्या प्रकारे काम करतात.

हे कंटेनर एका साध्या podman run -d कमांडने सुरू करते. हाताने सुरू केलेला कंटेनर रीबूटनंतर पुन्हा सुरू होत नाही, कारण तो आपोआप सुरू होण्यासाठी कोणतीही सूचना दिलेली नसते.
हे ollama/ollama या मूव्हिंग टॅगचा वापर करते. लॅपटॉपवर तुम्हाला वर्तणुकीतील बदल लगेच लक्षात येतात. सर्व्हरवर, याचा पहिला संकेत म्हणजे रात्रीतून अचानक बंद पडलेली स्क्रिप्ट.
हे -p 11434:11434 सह पब्लिश करते, जे सर्व इंटरफेसेसना बाइंड करते. होम राउटरच्या मागे असताना हे इंटरनेटवरून पोहोचण्यायोग्य नसते. मात्र, VPS वर हे पासवर्ड नसलेले सार्वजनिक इन्फरन्स API बनते.
हे तुमच्या स्वतःच्या लॉगिन युजर म्हणून चालते. सर्व्हरवर, ज्या खात्याच्या मालकीचे कंटेनर आहे, त्या खात्याकडे इतर कोणतीही जबाबदारी नसावी, जेणेकरून एखादा ब्रेक-आउट झाल्यास तो रिकाम्या होम डिरेक्टरीमध्येच मर्यादित राहील.

ज्या मशीनसाठी हे लिहिले आहे, त्या दृष्टीने यात काहीही चुकीचे नाही. जेव्हा मशीन सर्व बाजूंनी पोहोचण्यायोग्य असते आणि समोर कोणीही बसलेले नसते, तेव्हा प्रत्येक मुद्द्याचा पुनर्विचार करणे आवश्यक असते.

अविशेषाधिकार (unprivileged) वापरकर्ता तयार करा आणि 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 म्हणून लॉग इन करू शकत नाही. तुम्ही तुमच्या admin वापरकर्त्याकडून sudo -iu ollama वापरून त्या खात्यात प्रवेश करू शकता.

लॉगआउटनंतरही सेवा सुरू राहण्यासाठी lingering सक्षम करा

वापरकर्त्याचे systemd इन्स्टन्स सामान्यतः लॉगिन झाल्यावर सुरू होते आणि लॉगआउट झाल्यावर थांबते, आणि त्यासोबतच /run/user/<uid> काढून टाकले जाते. त्या वापरकर्त्याच्या मालकीचे प्रत्येक rootless कंटेनर त्याच क्षणी बंद होतात. Lingering मुळे कोणतेही सेशन जोडलेले नसतानाही वापरकर्त्याचे इन्स्टन्स सुरू राहते.

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

हे कमांड Linger=yes प्रिंट करेल. युनिट तयार करण्यापूर्वी हे सक्षम करा, कारण युनिटला आवश्यक असलेली डिरेक्टरी, /run/user/<uid>, केवळ lingering सुरू असतानाच अस्तित्वात असते.

अजून एक अशी पायरी आहे ज्याची कोणाला अपेक्षा नसते. sudo -iu ollama तुम्हाला शेल देते पण सेशन बस (session bus) देत नाही, त्यामुळे systemctl --user त्वरित अपयशी ठरते:

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

systemd वापरकर्ता बससाठी $XDG_RUNTIME_DIR/bus वर शोध घेते, आणि sudo -i तो व्हेरिएबल सेट करत नाही. तुम्ही जिथे ही सेवा व्यवस्थापित करता त्या प्रत्येक ॲडमिन शेलमध्ये तो हाताने सेट करा:

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

मॉडेल ब्लब्स कोठे साठवले जातात आणि डिस्कचे नियोजन कसे करावे

Ollama कंटेनरच्या आत /root/.ollama/models मध्ये वेट्स (weights) लिहितो. वापरकर्त्याच्या होम डिरेक्टरीमधील एक डिरेक्टरी या पाथवर बाइंड करा, म्हणजे फाईल्स तुम्हाला मोजता येतील अशा ठिकाणी साठवल्या जातील: /home/ollama/ollama-data/models. ब्लब्स models/blobs मध्ये कंटेंट-ॲड्रेस्ड फाईल्स म्हणून साठवले जातात आणि 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 लागते, तसेच कॉन्टेक्स्ट विंडोसाठी अतिरिक्त जागा लागते. त्यामुळे 16 GB च्या VPS वर 19 GB चे मॉडेल चालणार नाही.

इमेज टॅग पिन करा आणि पूर्ण रजिस्ट्री नाव वापरा

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

ऑगस्ट 2026 नुसार 0.32.9 हा रिलीज झालेला व्हर्जन टॅग वापरा, latest नको. टॅग पिन केल्यामुळे 04:00 वाजता सर्व्हर रीस्टार्ट झाल्यावर तुम्हाला तेच बायनरी मिळते ज्याची तुम्ही चाचणी केली होती, त्यामुळे वागणुकीत कोणताही बदल हा तुमच्याकडून झालेला बदल असतो. Docker Hub एकाच व्हर्जनसाठी -rc आणि -rocm टॅग देखील प्रकाशित करते; जर तुमच्याकडे AMD GPU नसेल, तर साधा टॅग निवडा.

रजिस्ट्री होस्टचे नाव देखील लिहा. Fedora वर systemd युनिटमधील लहान नावासाठी टर्मिनल उपलब्ध नसल्यामुळे प्रॉम्प्ट मिळत नाही आणि युनिट खालील त्रुटीसह अपयशी ठरते:

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

इमेज मॅन्युअली पुल करणे ऐच्छिक आहे, परंतु ते उपयुक्त ठरते कारण यामुळे अनेक गिगाबाइट्सचे डाउनलोड युनिटच्या स्टार्ट टाइमआउटच्या बाहेर होते.

रीबूटनंतर टिकून राहणारे 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 अंतर्गत model डिरेक्टरी 'permission denied' का दर्शवते

Fedora, RHEL, Rocky आणि AlmaLinux वर SELinux डीफॉल्टनुसार 'enforcing' मोडमध्ये असते. कंटेनर प्रक्रिया container_t डोमेनमध्ये चालते आणि वापरकर्त्याच्या होम डिरेक्टरीमधील फोल्डरला user_home_t लेबल असते. पॉलिसी या दोघांना एकमेकांशी संवाद साधू देत नाही, त्यामुळे Ollama आपली model ट्री तयार करू शकत नाही आणि कंटेनर बंद होतो. अशा सिस्टिम्सवर getenforce कमांड चालवल्यास Enforcing असा संदेश येतो आणि ही नाकारलेली विनंती (denial) खालीलप्रमाणे नोंदवली जाते:

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 (multi-category security) कॅटेगरी स्टॅम्प करते, जी फक्त याच कंटेनरकडे असते. लहान लिपीतील :z हे त्याऐवजी सामायिक लेबल वापरते, जे तुम्हाला तेव्हा हवे असते जेव्हा दोन कंटेनर एकाच डिरेक्टरीमधून वाचत असतात.

:Z बद्दल एक सावधगिरी, कारण ही प्रक्रिया विनाशकारी आणि शांतपणे काम करणारी आहे. रिलेबलिंग (Relabelling) रिकर्सिव्ह असते. जर तुम्ही ते /home/ollama कडे निर्देशित केले, तर त्या होम डिरेक्टरीमधील प्रत्येक फाईल रिलेबल केली जाईल, ज्यामुळे त्या वापरकर्त्याचा SSH की ॲक्सेस बंद होऊ शकतो. :Z ला नेहमी एक समर्पित सब-डिरेक्टरी द्या ज्यामध्ये इतर काहीही नसेल. Named volumes साठी याची गरज नसते, कारण Podman जेव्हा ते तयार करते तेव्हा त्यांना योग्यरित्या लेबल करते. जर तुम्हाला अधिक सविस्तर माहिती हवी असेल, तर SELinux basics for a server मध्ये कॉन्टेक्स्ट आणि बुलियन्स (booleans) बद्दल स्पष्टीकरण दिले आहे. Ubuntu आणि Debian वर त्याऐवजी AppArmor वापरले जाते, तिथे :Z चा काहीही परिणाम होत नाही आणि युनिट फाईलमध्ये ते तसेच ठेवल्यास काहीही नुकसान होत नाही.

पोर्ट 11434 बंद करा आणि SSH द्वारे API ॲक्सेस करा

PublishPort=127.0.0.1:11434:11434 होस्ट-साइडला लूपबॅकवर बाइंड करते. याची खात्री करा:

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 असे उत्तर दिले पाहिजे.

तुम्ही कोणत्या बाजूला बाइंड करत आहात याबद्दल अचूक राहा. PublishPort मधील पत्ता हा होस्टचा पत्ता आहे. कंटेनरच्या आत, Ollama ने सर्व इंटरफेसेसवर लिसन करणे सुरू ठेवले पाहिजे, जे इमेजचे डीफॉल्ट आहे. Environment=OLLAMA_HOST=127.0.0.1 सेट केल्याने Ollama कंटेनरच्या स्वतःच्या लूपबॅकवर बाइंड होते आणि Podman पब्लिश झालेली ट्रॅफिक कंटेनरच्या नेटवर्क पत्त्यावर फॉरवर्ड करते, त्यामुळे प्रत्येक विनंती नाकारली जाते, अगदी होस्टकडून आलेली सुद्धा.

पोर्ट 11434 उघडे ठेवल्याने दोन प्रकारे नुकसान होऊ शकते. Ollama मध्ये ऑथेंटिकेशन नसल्यामुळे, जो कोणी या पोर्टपर्यंत पोहोचतो तो /api/tags द्वारे तुमचे मॉडेल्स पाहू शकतो, /api/generate वापरून तुमच्या CPU आणि बँडविड्थवर इन्फरन्स चालवू शकतो, तुमच्या डिस्कवर नवीन मॉडेल्स डाउनलोड करू शकतो आणि तुमचे मॉडेल्स डिलीट करू शकतो. दुसरे म्हणजे, रिमोट पोर्टवर साधे HTTP वापरल्याने प्रॉम्प्ट्स आणि रिस्पॉन्स प्लेन टेक्स्टमध्ये पाठवले जातात, त्यामुळे मार्गातील प्रत्येक मशीन ते वाचू शकते. जर पोर्ट सर्व्हरच्या बाहेर पडलेच नाही, तर या दोन्ही समस्या उद्भवत नाहीत.

तुमच्या वर्कस्टेशनवरून, SSH द्वारे पोर्ट फॉरवर्ड करा:

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

आता तुमच्या लॅपटॉपवरील http://127.0.0.1:11434 हे सर्व्हरच्या Ollama शी जोडलेले आहे, जे SSH सेशनच्या एनक्रिप्शनमध्ये सुरक्षित आहे. जर तुमच्या लॅपटॉपवर आधीच Ollama चालू असेल, तर लोकल बाइंड bind [127.0.0.1]:11434: Address already in use मुळे अपयशी ठरेल; अशा वेळी -L 11435:127.0.0.1:11434 वापरा आणि तुमच्या क्लायंटला 11435 वर पॉइंट करा.

जेव्हा ब्राउझर क्लायंटला याची गरज असते, तेव्हा त्यासमोर पासवर्डसह रिव्हर्स प्रॉक्सी ठेवा. 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 (transport layer security) द्वारे प्रमाणपत्र मिळवते, त्यामुळे ट्रॅफिक एनक्रिप्टेड असते. प्रथम तुमच्या क्लायंटची चाचणी घ्या: Ollama शी संवाद साधणाऱ्या अनेक टूल्समध्ये Authorization हेडरसाठी जागा नसते आणि ते बेसिक ऑथेंटिकेशनमुळे 401 Unauthorized एरर देऊन अपयशी ठरतील. SSH टनेलमध्ये अशी कोणतीही समस्या येत नाही, म्हणूनच येथे ती डीफॉल्ट शिफारस म्हणून दिली आहे.

मॉडेल पुल करा आणि संपूर्ण पाथ तपासा

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. दिसते, कारण इमेज पुलिंगची प्रक्रिया अजूनही सुरू असते. मॅन्युअली पुल करा किंवा 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 हे loopback ॲड्रेसवर सेट केले आहे. ती ओळ काढून टाका.

जनरेशन खूप हळू होते किंवा कंटेनर बंद (kill) होतो. GPU नसल्यास, इन्फरन्स CPU वर चालतो आणि मोठे मॉडेल नैसर्गिकरित्या हळू चालते. जर कंटेनर विनंती पूर्ण होण्याआधीच बंद होत असेल आणि लॉगमध्ये signal: killed दिसत असेल, तर याचा अर्थ कर्नलचा out-of-memory killer सक्रिय झाला आहे. अशा वेळी वरील तक्त्यातून लहान टॅग निवडा.

पिन केलेल्या इमेजला अपडेट करणे

पिनिंगचा अर्थ असा आहे की अपडेट्स ही एक अशी गोष्ट आहे जी तुम्ही स्वतः करता, ती आपोआप घडत नाही. Image= मधील ollama.container फाईल एडिट करा, त्यानंतर रीलोड आणि रीस्टार्ट करा:

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

मॉडेल्स bind mount मध्ये असतात, त्यामुळे इमेज बदलली तरी ते सुरक्षित राहतात. [Container] सेक्शनमधील AutoUpdate=registry हे अशा लोकांसाठी आहे जे moving tag वापरतात. फिक्स्ड व्हर्जन टॅगसोबत याचा काहीही उपयोग होत नाही, कारण त्या टॅगची सामग्री कधीही बदलत नाही. /home/ollama/ollama-data/models/manifests आणि .container फाईलचा बॅकअप घ्या आणि blobs वगळा: ते आकाराने मोठे असतात आणि नवीन मशीनवर ollama pull त्यांना पुन्हा डाउनलोड करते.

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 लेबल असते, त्यामुळे लिहिण्याची परवानगी नाकारली जाते आणि Ollama बंद होते. :Z ला Volume= ओळीत जोडा आणि त्यासाठी एक स्वतंत्र सब-डिरेक्टरी वापरा, कारण relabelling ही प्रक्रिया रिकर्सिव्ह असते आणि :Z ला संपूर्ण होम डिरेक्टरीवर पॉइंट केल्यास त्या वापरकर्त्याचा SSH की ॲक्सेस बंद होऊ शकतो. Named volumes ला Podman द्वारे योग्य लेबल्स लावली जातात, त्यामुळे त्यांना अतिरिक्त कशाचीही गरज नसते.

Ollama मॉडेलसाठी किती डिस्क स्पेस लागते?

ollama.com/library वर प्रकाशित केलेल्या डाउनलोड आकारापासून सुरुवात करा, जो gemma3:4b साठी 3.3 GB पासून ते qwen3:30b साठी 19 GB पर्यंत असतो. त्यात Podman इमेजची भर टाका आणि थोडी अतिरिक्त जागा शिल्लक ठेवा, कारण दुसरे मॉडेल डिस्कवर पहिल्या मॉडेलची जागा घेत नाही. पुल करण्यापूर्वी df -h /home आणि नंतर du -sh ~/ollama-data/models तपासा. RAM चे नियोजनही याच पद्धतीने करा: मॉडेल लोड असताना त्याला साधारणपणे त्याच्या फाईलच्या आकाराएवढी मेमरी आणि त्यासोबत कॉन्टेक्स्ट विंडोसाठी अतिरिक्त मेमरी लागते.

VPS वर 11434 पोर्ट उघडे ठेवणे सुरक्षित आहे का?

नाही. Ollama मध्ये कोणत्याही प्रकारची ऑथेंटिकेशन यंत्रणा नाही, त्यामुळे जो कोणी या पोर्टपर्यंत पोहोचेल तो तुमची मॉडेल्स पाहू शकतो, ती डिलीट करू शकतो, डिस्कवर नवीन मॉडेल्स डाउनलोड करू शकतो आणि तुमच्या CPU व बँडविड्थचा वापर करून इन्फरन्स चालवू शकतो. इंटरनेटवरून येणारा साधा HTTP ट्रॅफिक सर्व प्रॉम्प्ट्स आणि उत्तरे स्पष्ट मजकुरात (cleartext) पाठवतो. होस्ट साईडला 127.0.0.1 सह PublishPort=127.0.0.1:11434:11434 वर बाइंड करा, ss -ltnp | grep 11434 ने खात्री करा आणि त्यापर्यंत पोहोचण्यासाठी SSH टनेल किंवा पासवर्डची आवश्यकता असलेला रिव्हर्स प्रॉक्सी वापरा.

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