SSD Nodes Learn 🎉 VPS از $5.50/ماه
راهنماها Matt Connorتوسط Matt Connor

اجرای Ollama در Podman بدون دسترسی root روی VPS

راهنمای کامل اجرای Ollama با Podman به صورت rootless. یاد بگیرید چگونه با استفاده از Quadlet و فعال‌سازی lingering، سرویس خود را پس از reboot در سرور مدیریت کنید.

اجرای Ollama در Podman بدون دسترسی root روی VPS

برای اجرای Ollama در Podman بدون دسترسی root روی یک سرور، پنج شرط باید برقرار باشد که در راهنماهای دسکتاپ معمولاً نادیده گرفته می‌شوند. یک کاربر بدون امتیاز (unprivileged) اختصاصی مالک container است. قابلیت lingering برای آن کاربر فعال است تا container پس از خروج شما از سیستم همچنان در حال اجرا باقی بماند. یک فایل Quadlet مدیریت container را به systemd می‌سپارد تا پس از reboot، سرویس به‌طور خودکار بالا بیاید. دایرکتوری مدل‌ها در توزیع‌هایی که SELinux را اعمال می‌کنند، باید دارای برچسب (label) مناسب باشد. API فقط روی loopback گوش می‌دهد و شما از طریق یک تونل SSH (secure shell) به آن دسترسی پیدا می‌کنید.

Ollama یک سرور برای مدل‌های زبانی بزرگ (LLM) است. این برنامه وزن‌های مدل را روی دیسک ذخیره کرده، آن‌ها را در حافظه بارگذاری می‌کند و به درخواست‌های HTTP در پورت 11434 پاسخ می‌دهد. این سرویس فاقد سیستم ورود، کلید API و حساب کاربری است، بنابراین شبکه تنها ابزار کنترل دسترسی شماست. Podman کانتینرها را بدون daemon و بدون دسترسی root اجرا می‌کند، بنابراین هر چیزی که از کانتینر خارج شود، با سطح دسترسی یک کاربر معمولی و بدون امتیاز خواهد بود. اگر ابتدا به مقایسه محیط‌های اجرا نیاز دارید، تفاوت Podman و Docker روی VPS را مطالعه کنید. اگر ترجیح می‌دهید کلاً از کانتینرها صرف‌نظر کنید، نصب مستقیم Ollama روی VPS مسیر کوتاه‌تری است.

سرویس SSD Nodes در میان ایمیج‌های خود Fedora را ارائه می‌دهد و Fedora به‌صورت پیش‌فرض هم Podman و هم SELinux (لینوکس با امنیت ارتقایافته) را به همراه دارد. تمام دستورات زیر روی هر توزیعی که Podman نسخه 5 یا جدیدتر داشته باشد، قابل اجرا هستند.

چرا نسخه لپ‌تاپ در سرور نیاز به تغییر دارد

مجله Fedora در تاریخ 5 اوت 2026 یک راهنمای شفاف درباره این پشته منتشر کرد: اجرای محلی Ollama با Podman روی Fedora Linux، نوشته Yazan Monshed. این یک شروع خوب برای آشنایی با ابزارهاست. با این حال، این راهنما برای لپ‌تاپ نوشته شده و چهار مورد از انتخاب‌های آن در ماشینی که دارای IP عمومی است، رفتار متفاوتی دارند.

  • این راهنما کانتینر را با یک podman run -d ساده شروع می‌کند. کانتینری که به‌صورت دستی اجرا شود، پس از reboot دوباره بالا نمی‌آید، زیرا دستوری برای شروع خودکار آن صادر نشده است.
  • از تگ متغیر ollama/ollama استفاده می‌کند. روی لپ‌تاپ، شما همان روزی که رفتار تغییر می‌کند متوجه می‌شوید. در سرور، اولین نشانه، اسکریپتی است که یک‌شبه از کار افتاده است.
  • با استفاده از -p 11434:11434 پورت را منتشر می‌کند که تمام اینترفیس‌ها را bind می‌کند. پشت یک روتر خانگی، این کار از اینترنت غیرقابل‌دسترسی است. اما روی یک VPS، این کار به معنای یک API استنتاج عمومی بدون رمز عبور است.
  • با کاربر لاگین شما اجرا می‌شود. در سرور، حسابی که مالک کانتینر است نباید مالک هیچ چیز دیگری باشد، تا در صورت نفوذ (break-out)، مهاجم تنها به یک دایرکتوری home خالی دسترسی داشته باشد.

هیچ‌کدام از این موارد برای ماشینی که راهنما برای آن نوشته شده، اشتباه نیست. هر مورد صرفاً تصمیمی است که وقتی دستگاه از همه جا در دسترس است و کسی پشت آن ننشسته، باید دوباره بازنگری شود.

ایجاد کاربر بدون دسترسی ریشه (unprivileged) و بررسی subuid

در حالت Rootless Podman، شناسه‌های کاربری (UID) داخلی کانتینر به بلوکی از شناسه‌های استفاده‌نشده روی میزبان (host) نگاشت می‌شوند. این بلوک در فایل‌های /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 شناسه را مشخص می‌کند:

/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 را چاپ کند. پیش از ایجاد 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 به دنبال user bus در مسیر $XDG_RUNTIME_DIR/bus می‌گردد و sudo -i این متغیر را تنظیم نمی‌کند. آن را به‌صورت دستی در هر shell مدیریتی که برای کنترل این سرویس استفاده می‌کنید، تنظیم نمایید:

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

محل ذخیره‌سازی مدل‌ها و میزان فضای دیسک مورد نیاز

Ollama وزن‌های مدل را در مسیر /root/.ollama/models داخل کانتینر می‌نویسد. با Bind کردن یک دایرکتوری از home کاربر به این مسیر، فایل‌ها در جایی قرار می‌گیرند که می‌توانید آن را اندازه‌گیری کنید: /home/ollama/ollama-data/models. فایل‌های Blob به عنوان فایل‌های content-addressed در models/blobs ذخیره می‌شوند و models/manifests شامل ایندکس کوچکی است که نام آن‌ها را در خود نگه می‌دارد. اگر به‌جای آن از یک named volume استفاده کنید، همان‌طور که در پست Fedora Magazine آمده است، همین ساختار درختی در /home/ollama/.local/share/containers/storage/volumes/<volume>/_data قرار می‌گیرد.

پیش از دانلود هر چیزی، فضای دیسک را تخمین بزنید. حجم‌های دانلود اعلام‌شده، حداقل فضای مورد نیاز را به شما نشان می‌دهند.

ChartPublished download size per Ollama model tag, ollama.com/library, checked 13 August 2026
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 گیگابایت دانلود دارد. بزرگ‌ترین آن‌ها، یعنی qwen3:30b، به میزان 19 گیگابایت دانلود دارد. خودِ image کانتینر نیز علاوه بر این‌ها در فضای ذخیره‌سازی Podman قرار می‌گیرد، بنابراین هر دو عدد را با استفاده از podman system df و df -h /home با هم بررسی کنید. یک مدل در زمان بارگذاری، تقریباً به اندازه‌ حجم فایل خود به RAM نیاز دارد، به‌علاوه فضایی برای context window؛ بنابراین یک مدل 19 گیگابایتی روی یک VPS با 16 گیگابایت رم اجرا نخواهد شد.

##
تگ ایمیج را ثابت (Pin) کنید و از نام کامل رجیستری استفاده کنید

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

از یک تگ نسخه منتشرشده استفاده کنید، برای مثال 0.32.9 تا اوت 2026، و نه latest. تگ ثابت به این معناست که با ری‌استارت در ساعت 04:00، همان باینری که تست کرده‌اید اجرا می‌شود؛ بنابراین هر تغییری در رفتار، ناشی از تغییراتی است که خودتان اعمال کرده‌اید. Docker Hub همچنین تگ‌های -rc و -rocm را برای نسخه‌های مشابه منتشر می‌کند؛ مگر اینکه از GPU مدل AMD استفاده کنید، تگ ساده را انتخاب کنید.

نام میزبان رجیستری را نیز بنویسید. در Fedora، نام کوتاه در یک unit فایل systemd ترمینالی ندارد که درخواست تایید (prompt) کند و unit با خطای زیر شکست می‌خورد:

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

Pull کردن دستی ایمیج پیش از اجرا اختیاری است، اما مفید است؛ زیرا دانلود چند گیگابایتی را از بازه زمانی timeout شروع unit خارج می‌کند.

واحد Quadlet که پس از reboot باقی می‌ماند

Quadlet تولیدکنندهٔ systemd برای Podman است. شما یک فایل .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 اولین شروعی را پوشش می‌دهد که هنوز باید image را دانلود کند، زیرا زمان پیش‌فرض 90 ثانیه برای دانلود دو گیگابایت کافی نیست و systemd شروع آن را به عنوان شکست‌خورده متوقف می‌کند. OLLAMA_KEEP_ALIVE=30m یک مدل را بین درخواست‌ها در حافظه نگه می‌دارد و آن را پس از پنج دقیقه تخلیه نمی‌کند؛ معایب و مزایای این کار در نگهداری مدل Ollama در حافظه آمده است. اگر هر بخشی از اصطلاحات systemd در اینجا برای شما جدید است، نحوه عملکرد سرویس‌ها و تایمرهای systemd در یک VPS خودِ واحدها را پوشش می‌دهد.

چرا دایرکتوری مدل در SELinux خطای permission denied می‌دهد

در توزیع‌های Fedora، RHEL، Rocky و AlmaLinux، سیستم امنیتی SELinux به‌صورت پیش‌فرض در حالت enforcing قرار دارد. یک پردازش کانتینر در دامین container_t اجرا می‌شود و دایرکتوری موجود در home کاربر با برچسب 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

عبارت :Z در انتهای خط Volume= راه‌حل این مشکل است. این عبارت دایرکتوری میزبان را به container_file_t تغییر برچسب می‌دهد و آن را با یک دسته MCS (امنیت چند-دسته‌ای) خصوصی مهر می‌کند که فقط همین کانتینر آن را داراست. استفاده از :z با حروف کوچک، از یک برچسب اشتراکی استفاده می‌کند که برای زمانی مناسب است که دو کانتینر بخواهند یک دایرکتوری واحد را بخوانند.

یک هشدار در مورد :Z وجود دارد، زیرا این دستور مخرب است و بدون پرسش عمل می‌کند. تغییر برچسب به‌صورت بازگشتی (recursive) انجام می‌شود. اگر آن را به /home/ollama اشاره دهید، تمام فایل‌های موجود در آن دایرکتوری home تغییر برچسب داده می‌شوند که باعث از کار افتادن دسترسی کلیدهای SSH برای آن کاربر خواهد شد. همیشه برای :Z یک زیردایرکتوری اختصاصی در نظر بگیرید که حاوی هیچ فایل دیگری نباشد. Named volumeها به این کار نیازی ندارند، زیرا Podman هنگام ایجاد آن‌ها، برچسب‌گذاری را به‌درستی انجام می‌دهد. اگر به اطلاعات جامع‌تری نیاز دارید، مبانی SELinux برای سرور مفاهیم contextها و booleanها را توضیح می‌دهد. در توزیع‌های Ubuntu و Debian به‌جای آن از AppArmor استفاده می‌شود؛ در این سیستم‌ها :Z هیچ عملی انجام نمی‌دهد و باقی ماندن آن در unit فایل، بی‌ضرر است.

بستن پورت 11434 و دسترسی به API از طریق SSH

PublishPort=127.0.0.1:11434:11434 سمت میزبان را به loopback محدود می‌کند. آن را تأیید کنید:

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 باید همچنان روی تمام اینترفیس‌ها گوش دهد، که تنظیم پیش‌فرض image است. تنظیم Environment=OLLAMA_HOST=127.0.0.1 باعث می‌شود Ollama به loopback خودِ کانتینر bind شود و Podman ترافیک منتشرشده را به آدرس شبکه کانتینر هدایت کند، بنابراین هر درخواستی حتی از سمت میزبان نیز رد می‌شود.

باز بودن پورت 11434 از دو جهت برای شما هزینه دارد. Ollama هیچ احراز هویتی ندارد، بنابراین هر کسی که به این پورت دسترسی پیدا کند می‌تواند مدل‌های شما را از طریق /api/tags لیست کند، با استفاده از CPU و پهنای باند شما از طریق /api/generate عملیات inference انجام دهد، مدل‌های جدید روی دیسک شما دانلود کند و مدل‌های موجود را حذف نماید. دوم اینکه، HTTP ساده به یک پورت راه دور، درخواست‌ها و پاسخ‌ها را به صورت متن آشکار (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 ندارند و در برابر احراز هویت پایه با یک 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 برمی‌گرداند؛ این کار پس از یک وقفه کوتاه برای بارگذاری وزن‌ها از دیسک انجام می‌شود. du باید عددی نزدیک به حجم دانلود اعلام‌شده را گزارش کند. سپس بخشی را که کل این راهنما درباره آن است، اثبات کنید:

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

active به معنای باقی ماندن (lingering) است و نشان می‌دهد که بخش [Install] و daemon-reload وظایف خود را به‌درستی انجام داده‌اند. inactive به این معناست که یکی از این سه مورد وجود ندارد.

حالت‌های شکست و پیام‌های مرتبط

کانتینر پس از reboot ناپدید می‌شود. ابتدا loginctl show-user ollama --property=Linger را بررسی کنید، زیرا بدون Linger=yes، نمونه systemd کاربر هرگز در زمان بوت اجرا نمی‌شود. اگر قابلیت lingering فعال است، ممکن است بخش [Install] در فایل .container وجود نداشته باشد یا فایل را ویرایش کرده باشید اما دستور systemctl --user daemon-reload را اجرا نکرده باشید.

Error: statfs /home/ollama/ollama-data: no such file or directory. منبع bind mount باید پیش از شروع کانتینر وجود داشته باشد. Podman دایرکتوری‌های میزبان را برای شما ایجاد نمی‌کند. دستور mkdir -p ~/ollama-data را به عنوان کاربر ollama اجرا کنید.

شروع سرویس پس از 90 ثانیه شکست می‌خورد. دستور journalctl --user -u ollama.service مقدار Start operation timed out. Terminating. را نشان می‌دهد، زیرا عملیات دریافت (pull) ایمیج هنوز در حال اجرا بوده است. ایمیج را به‌صورت دستی دریافت کنید یا TimeoutStartSec=900 را حفظ کنید.

کانتینر شروع شده و بلافاصله خارج می‌شود. دستورات podman logs ollama و sudo ausearch -m avc -ts recent در کنار هم به شما می‌گویند که آیا مشکل از برچسب SELinux است یا خیر. یک AVC که به container_t و user_home_t اشاره دارد، به این معنی است که :Z وجود ندارد.

درخواست‌ها از سمت میزبان رد می‌شوند. دستور curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused با سرویس active معمولاً به این معنی است که OLLAMA_HOST روی یک آدرس loopback در داخل کانتینر تنظیم شده است. آن خط را حذف کنید.

تولید (Generation) بسیار کند است یا کانتینر کشته می‌شود. بدون GPU، استنتاج (inference) روی CPU انجام می‌شود و یک مدل بزرگ ذاتاً کند است. کانتینری که در میانه درخواست با خطای signal: killed در لاگ‌ها متوقف می‌شود، توسط مکانیزم OOM killer هسته سیستم‌عامل کشته شده است؛ بنابراین یک تگ کوچک‌تر از جدول بالا انتخاب کنید.

به‌روزرسانی یک image ثابت‌شده (pinned)

ثابت‌سازی (Pinning) به این معناست که به‌روزرسانی‌ها کاری هستند که شما انجام می‌دهید، نه اتفاقی که به‌صورت خودکار رخ می‌دهد. فایل Image= را در ollama.container ویرایش کنید، سپس تنظیمات را reload و سرویس را restart کنید:

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

مدل‌ها در bind mount قرار دارند، بنابراین با تغییر image، بدون تغییر باقی می‌مانند. پارامتر AutoUpdate=registry در بخش [Container] برای کاربرانی است که از تگ‌های متغیر (moving tag) استفاده می‌کنند؛ این پارامتر در کنار یک تگ نسخه ثابت (fixed version tag) هیچ کاربرد مفیدی ندارد، زیرا محتوای آن تگ هرگز تغییر نمی‌کند. از /home/ollama/ollama-data/models/manifests و فایل .container نسخه پشتیبان تهیه کنید و از blobها صرف‌نظر کنید: آن‌ها حجیم هستند و ollama pull در صورت انتقال به یک سیستم جدید، آن‌ها را مجدداً دریافت می‌کند.

FAQ

چرا کانتینر rootless Podman من پس از خروج از سیستم متوقف می‌شود؟

نمونه systemd کاربر و دایرکتوری /run/user/<uid> آن با پایان یافتن آخرین نشست کاربر از بین می‌روند و تمام کانتینرهای rootless نیز همراه با آن متوقف می‌شوند. دستور sudo loginctl enable-linger ollama را اجرا کنید و تأیید کنید که loginctl show-user ollama --property=Linger مقدار Linger=yes را چاپ می‌کند. پیش از ایجاد unit مربوط به Quadlet، قابلیت lingering را فعال کنید، زیرا دایرکتوری runtime که unit به آن نیاز دارد، تنها پس از فعال‌سازی lingering ایجاد می‌شود.

آیا به برچسب‌های SELinux روی دایرکتوری مدل Ollama نیاز دارم؟

در توزیع‌های Fedora، RHEL، Rocky و AlmaLinux، اگر یک دایرکتوری میزبان را bind mount می‌کنید، پاسخ مثبت است. کانتینر در دامنه container_t اجرا می‌شود و دایرکتوری موجود در پوشه home دارای برچسب user_home_t است، بنابراین عملیات نوشتن رد شده و Ollama متوقف می‌شود. عبارت :Z را به خط Volume= اضافه کنید و یک زیردایرکتوری اختصاصی برای آن در نظر بگیرید، زیرا تغییر برچسب به‌صورت بازگشتی (recursive) انجام می‌شود و اعمال :Z روی کل دایرکتوری home، دسترسی SSH key کاربر را مختل می‌کند. Named volumeها توسط Podman به‌درستی برچسب‌گذاری می‌شوند و به تنظیمات اضافی نیاز ندارند.

یک مدل Ollama به چه مقدار فضای دیسک نیاز دارد؟

محاسبات خود را از حجم دانلود منتشرشده در ollama.com/library آغاز کنید که از 3.3 گیگابایت برای gemma3:4b تا 19 گیگابایت برای qwen3:30b متغیر است. حجم ایمیج Podman را نیز به آن اضافه کنید و مقداری فضای خالی در نظر بگیرید، زیرا مدل دوم جایگزین مدل اول روی دیسک نمی‌شود. پیش از pull کردن از df -h /home و پس از آن از du -sh ~/ollama-data/models برای بررسی استفاده کنید. برای RAM نیز همین‌گونه برنامه‌ریزی کنید: یک مدل هنگام بارگذاری تقریباً به اندازه حجم فایل خود به حافظه نیاز دارد، به‌علاوه فضای مورد نیاز برای context window.

آیا باز کردن پورت 11434 روی یک VPS امن است؟

خیر. Ollama بدون هیچ‌گونه احراز هویتی عرضه می‌شود، بنابراین هر کسی که به این پورت دسترسی پیدا کند می‌تواند مدل‌های شما را لیست یا حذف کند، مدل‌های جدیدی روی دیسک شما دانلود کند و از CPU و پهنای باند شما برای اجرای inference استفاده کند. همچنین، پروتکل HTTP ساده روی اینترنت، تمام promptها و پاسخ‌ها را به‌صورت متن آشکار (cleartext) ارسال می‌کند. سمت میزبان را با استفاده از PublishPort=127.0.0.1:11434:11434 به 127.0.0.1 محدود کنید، با ss -ltnp | grep 11434 وضعیت را تأیید کنید و از طریق یک SSH tunnel یا یک reverse proxy که نیاز به رمز عبور دارد، به آن متصل شوید.

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