آموزش اجرای Ollama با Podman rootless روی VPS

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

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

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

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

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

مجله Fedora در تاریخ 5 August 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

Podman در حالت rootless، شناسه‌های کاربری (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 وارد سیستم شود. شما از طریق کاربر مدیر خود و با استفاده از 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 داخل container می‌نویسد. با mount کردن یک دایرکتوری از home کاربر روی این مسیر، فایل‌ها در محلی قرار می‌گیرند که قابل اندازه‌گیری است: /home/ollama/ollama-data/models. فایل‌های blob به عنوان محتوای آدرس‌دهی‌شده در models/blobs ذخیره می‌شوند و models/manifests شامل ایندکس کوچکی است که نام آن‌ها را در خود دارد. اگر به‌جای آن از یک named volume استفاده کنید، همان‌طور که در پست Fedora Magazine آمده است، ساختار درختی مشابه در /home/ollama/.local/share/containers/storage/volumes/<volume>/_data قرار می‌گیرد. در هر دو حالت، ollama pull و ollama run وزن‌ها را در همان ساختار درختی می‌نویسند و تفاوت این دو دستور تنها در این است که آیا پس از پایان دانلود، یک نشست چت باز می‌شود یا خیر.

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

[
  {
    "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، نام کوتاه در یک systemd unit ترمینالی برای پرسش و پاسخ ندارد و 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 را دانلود (pull) کند، زیرا زمان پیش‌فرض 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 را پاسخ دهد.

در مورد اینکه کدام سمت را متصل می‌کنید دقیق باشید. آدرس در PublishPort آدرس میزبان است. در داخل کانتینر، Ollama باید همچنان روی تمام اینترفیس‌ها گوش دهد که تنظیم پیش‌فرض ایمیج است. تنظیم Environment=OLLAMA_HOST=127.0.0.1 باعث می‌شود Ollama به loopback خودِ کانتینر متصل شود و Podman ترافیک منتشرشده را به آدرس شبکه کانتینر هدایت کند، بنابراین هر درخواستی حتی از سمت میزبان رد می‌شود.

باز بودن پورت 11434 از دو جهت برای شما هزینه دارد. Ollama هیچ احراز هویتی ندارد، بنابراین هر کسی که به این پورت دسترسی پیدا کند می‌تواند مدل‌های شما را از طریق /api/tags لیست کند، با استفاده از /api/generate روی CPU و پهنای باند شما استنتاج (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 [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 کردن image هنوز در حال اجرا بوده است. عملیات 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 در لاگ‌ها متوقف می‌شود، توسط قابلیت out-of-memory 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] برای کسانی است که از یک tag متغیر استفاده می‌کنند؛ این گزینه در کنار یک version tag ثابت هیچ کار مفیدی انجام نمی‌دهد، زیرا محتوای آن tag هرگز تغییر نمی‌کند. از /home/ollama/ollama-data/models/manifests و فایل .container نسخه پشتیبان تهیه کنید و از blobs صرف‌نظر کنید: آن‌ها حجیم هستند و ollama pull در صورت انتقال به یک سیستم جدید، آن‌ها را دوباره دریافت می‌کند.

FAQ

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

نمونه systemd کاربر و دایرکتوری /run/user/<uid> آن، با پایان یافتن آخرین نشست (session) کاربر از بین می‌روند و به تبع آن، تمام کانتینرهای 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، اگر یک دایرکتوری از میزبان (host) را bind mount می‌کنید، پاسخ مثبت است. کانتینر در دامنه container_t اجرا می‌شود و دایرکتوری‌های موجود در پوشه home دارای برچسب user_home_t هستند؛ در نتیجه عملیات نوشتن رد شده و Ollama متوقف می‌شود. عبارت :Z را به خط Volume= اضافه کنید و از یک زیرپوشه اختصاصی استفاده کنید، زیرا تغییر برچسب (relabeling) به صورت بازگشتی انجام می‌شود و اعمال :Z روی کل دایرکتوری home، دسترسی SSH key کاربر را مختل می‌کند. حجم‌های نام‌گذاری شده (Named volumes) به‌طور خودکار توسط 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، به RAM نیاز دارد.

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

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