آموزش نصب و راه‌اندازی Incus روی VPS

کانتینر سیستمی Incus چیست

کانتینرهای سیستمی Incus روی یک VPS، یک ماشین کامل با سیستم init و حساب‌های کاربری اختصاصی در اختیار شما قرار می‌دهند؛ این کانتینرها صرفاً یک پروسه با یک فایل‌سیستم متصل نیستند. کانتینر بوت می‌شود، یک init را به عنوان PID 1 اجرا می‌کند و به systemctl پاسخ می‌دهد. این کانتینر از هسته (kernel) میزبان استفاده می‌کند، بنابراین یک ماشین مجازی (VM) نیست. هر چیزی که بالاتر از سطح هسته قرار دارد، دقیقاً مانند یک ماشین واقعی رفتار می‌کند.

Incus فورک جامعهٔ کاربری LXD است که تحت پروژه Linux Containers نگهداری می‌شود. دستور کلاینت آن incus است. این ابزار همچنین با استفاده از --vm می‌تواند ماشین‌های مجازی واقعی را از طریق QEMU اجرا کند، اما کانتینر سیستمی دلیلی است که اکثر کاربران آن را نصب می‌کنند و موضوع اصلی ادامهٔ این راهنما نیز همین است.

چرا مقایسه‌های Docker گمراه‌کننده هستند

Docker یک پردازش واحد را بسته‌بندی می‌کند. Incus یک سیستم‌عامل کامل را بسته‌بندی می‌کند. مستندات Incus این تفاوت را به‌صراحت بیان کرده‌اند: «کانتینرهای اپلیکیشن (مانند آنچه Docker ارائه می‌دهد) یک پردازش یا برنامه واحد را بسته‌بندی می‌کنند. در مقابل، کانتینرهای سیستمی یک سیستم‌عامل کامل را شبیه‌سازی می‌کنند، مشابه آنچه روی یک میزبان یا ماشین مجازی اجرا می‌کنید.»

این تفاوت، نحوه تعامل روزمره شما با این ابزارها را تغییر می‌دهد.

• یک ایمیج Docker فاقد init است، بنابراین systemctl در داخل آن با شکست مواجه می‌شود. یک کانتینر Incus یک سیستم init را اجرا می‌کند، بنابراین سرویس‌ها و تایمرها دقیقاً همان‌طور که روی یک سرور عمل می‌کنند، کار می‌کنند.
• یک کانتینر Docker برای تخریب و بازسازی از طریق Dockerfile طراحی شده است. یک کانتینر Incus برای نگهداری، وصله‌کردن و گرفتن snapshot طراحی شده است.
• یک ایمیج Docker یک خروجی ساخت (build artefact) است که آن را به یک رجیستری ارسال می‌کنید. یک نمونه (instance) در Incus، وضعیتی روی دیسک در یک storage pool است که آن را با incus export جابه‌جا می‌کنید.
• Docker یک بار کاری (workload) را ایزوله می‌کند. Incus یک ماشین را ایزوله می‌کند، بنابراین یک کانتینر می‌تواند چندین بار کاری و چندین حساب کاربری را در خود جای دهد.

شما می‌توانید Docker را در داخل یک کانتینر سیستمی Incus اجرا کنید. اما نمی‌توانید Incus را در داخل یک کانتینر اپلیکیشن Docker اجرا کنید. اگر واقعاً به مدل «یک پردازش در هر کانتینر» با مرحله ساخت ایمیج نیاز دارید، Podman و Docker روی VPS اولین مقایسه‌ای است که باید مطالعه کنید. اگر به جای یک هسته (kernel) مشترک، به یک هسته مجزا برای هر بار کاری نیاز دارید، میکرو ماشین‌های مجازی Firecracker روی VPS مسیر متفاوتی را پیشنهاد می‌دهد.

آیا Incus روی VPS اجرا می‌شود؟

این موضوع به نوع مجازی‌سازی VPS و هسته (kernel) آن بستگی دارد، بنابراین پیش از نصب هر چیزی، هر دو مورد را بررسی کنید. به صفحه تبلیغاتی ارائه‌دهنده سرویس اعتماد نکنید. این چهار دستور را روی سرور اجرا کنید.

systemd-detect-virt
uname -r
stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers

چاپ systemd-detect-virt یا kvm یا qemu به این معنی است که VPS شما یک ماشین مجازی با هسته اختصاصی خود است. این حالت ساده است، زیرا Incus در این شرایط دقیقاً مانند سخت‌افزار فیزیکی عمل می‌کند. چاپ lxc، lxc-libvirt یا openvz به این معنی است که VPS شما خود یک کانتینر است که از هسته ارائه‌دهنده استفاده می‌کند. کانتینرهای Incus در این حالت، کانتینرهای تو در تو (nested) هستند و این قابلیت تنها در صورتی کار می‌کند که ارائه‌دهنده آن را برای کانتینر شما فعال کرده باشد. شما نمی‌توانید این قابلیت را از داخل کانتینر فعال کنید، زیرا تنظیمات آن در سطح میزبان (host) قرار دارد که شما به آن دسترسی ندارید.

stat -fc %T /sys/fs/cgroup باید cgroup2fs را چاپ کند. هر خروجی دیگری به این معنی است که سرور از ساختار cgroup (گروه کنترل) نسخه 1 یا ترکیبی استفاده می‌کند که Incus فعلی از آن پشتیبانی نمی‌کند.

cat /sys/fs/cgroup/cgroup.controllers کنترل‌کننده‌های cgroup که به شما واگذار شده‌اند را فهرست می‌کند. Incus در مستندات خود blkio، cpuset، devices، freezer، memory و pids را به عنوان موارد مورد نیاز ذکر کرده است. در یک VPS تو در تو، این فهرست اغلب کوتاه‌تر از یک VPS مبتنی بر KVM است، زیرا ارائه‌دهنده انتخاب می‌کند چه منابعی را در اختیار شما قرار دهد. کنترل‌کننده‌ای که در این فایل وجود نداشته باشد، توسط Incus قابل استفاده نیست و در نتیجه محدودیت‌های نمونه (instance) که به آن وابسته هستند، برای شما در دسترس نخواهند بود.

نسخه هسته اهمیت بیشتری نسبت به گذشته پیدا کرده است. از اوت 2026، مستندات Incus دو حداقلِ متفاوت برای دو شاخه‌ای که توسط تیم اصلی نگهداری می‌شوند، ارائه می‌دهد. شاخه 6.0 LTS (پشتیبانی بلندمدت) بیان می‌کند: «حداقل نسخه هسته پشتیبانی‌شده 5.4 است.» شاخه پایدار فعلی بیان می‌کند: «حداقل نسخه هسته پشتیبانی‌شده 6.12 است.» سیستم‌عامل Ubuntu 24.04 سری 6.0 LTS را در مخزن خود بسته‌بندی کرده و آن را با هسته 6.8 همراه می‌کند که ترکیبی پشتیبانی‌شده است. نصب نسخه پایدار فعلی از مخزن اصلی روی همان هسته 6.8، شما را پایین‌تر از حداقلِ مستندشده قرار می‌دهد، بنابراین پیش از انتخاب مخزن، uname -r را مطالعه کنید.

اگر هدف شما استفاده از ماشین‌های مجازی کامل به جای کانتینرها است، محدودیت‌ها متفاوت و دشوارتر هستند. برای اطلاع از اینکه آیا VPS شما می‌تواند /dev/kvm را ارائه دهد، به مجازی‌سازی تو در تو روی VPS و برای حالتی که مالک سخت‌افزار هستید، به مقایسه Proxmox با یک VPS اجاره‌ای مراجعه کنید.

نصب Incus روی Ubuntu یا Debian

توزیع‌های Debian 13 و Ubuntu 24.04 و نسخه‌های جدیدتر، Incus را در مخازن رسمی خود ارائه می‌دهند.

sudo apt update
sudo apt install -y incus

در Debian، دستور incus-base پشتیبانی از کانتینر را بدون بخش‌های مربوط به ماشین مجازی نصب می‌کند. در Ubuntu، اگر به نمونه‌های --vm نیز نیاز دارید، qemu-system را اضافه کنید.

برای استفاده از نسخه‌ای جدیدتر از آنچه در توزیع شما موجود است، بسته‌های رسمی پروژه در pkgs.zabbly.com قرار دارند. این دستورات از فایل README مخزن اصلی پروژه استخراج شده‌اند.

sudo apt update && sudo apt install -y curl
sudo mkdir -p /etc/apt/keyrings/
sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
sudo sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-stable.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc
EOF'
sudo apt-get update
sudo apt-get install -y incus

سپس به کاربر خود دسترسی لازم برای اتصال به daemon socket را بدهید.

sudo usermod -aG incus-admin "$USER"
newgrp incus-admin
incus info

incus info اگر پیکربندی سرور را چاپ کند، یعنی سوکت به‌درستی کار می‌کند. خطای مجوز به این معناست که تغییر گروه هنوز در shell شما اعمال نشده است که newgrp incus-admin این مشکل را برای shell فعلی حل می‌کند و یک ورود مجدد (login) کامل، آن را به‌صورت دائمی برطرف می‌سازد. عضویت در گروه incus-admin را معادل دسترسی root روی میزبان در نظر بگیرید، زیرا دسترسی به این سوکت به معنای کنترل کامل بر daemonای است که با دسترسی root اجرا می‌شود. برخی توزیع‌ها یک گروه ساده incus نیز برای دسترسی محدود کاربران ایجاد می‌کنند.

اکنون daemon را مقداردهی اولیه (initialise) کنید.

sudo incus admin init

به جای استفاده از incus admin init --minimal، به سوالات پاسخ دهید. مسیر حداقلی، درایور ذخیره‌سازی dir را انتخاب می‌کند و بخش بعدی به این می‌پردازد که چرا این انتخاب اهمیت دارد.

یک نمونه اجرا کنید و از عملکرد آن مطمئن شوید.

incus launch images:debian/13 web
incus list
incus exec web -- bash

incus list باید web را به عنوان RUNNING با یک آدرس IPv4 در زیرشبکه incusbr0 نشان دهد. عدم دریافت آدرس به این معناست که DHCP (پروتکل پیکربندی پویای میزبان) تکمیل نشده است که بخش شبکه به آن می‌پردازد. کانتینری که در شروع کار شکست می‌خورد، دلیل آن را در incus info web --show-log چاپ می‌کند و خطاهای سطح daemon در sudo journalctl -u incus -n 50 ثبت می‌شوند. در یک VPS که دستور systemd-detect-virt خروجی lxc یا openvz را برمی‌گرداند، این اجرای نمونه، آزمون واقعی برای بررسی در دسترس بودن قابلیت nesting برای شماست.

چرا backend ذخیره‌سازی پیش‌فرض اهمیت دارد

backend ذخیره‌سازی تعیین می‌کند که آیا یک snapshot آنی است یا یک کپی کامل از دیسک container. این تنها انتخابی است که در زمان نصب انجام می‌دهید و بعداً نمی‌توان آن را به‌سادگی تغییر داد.

Incus از dir، btrfs، lvm، zfs، Ceph و چندین درایور راه دور پشتیبانی می‌کند. در یک VPS با یک دیسک، انتخاب واقعی بین dir و btrfs است.

درایور dir هر container را به صورت فایل‌ها و دایرکتوری‌های معمولی در مسیر /var/lib/incus نگهداری می‌کند. Incus آن را «بسیار کندتر از سایر درایورها» توصیف می‌کند، زیرا مجبور است هر image را باز کند و به جای ارجاع به بلوک‌های مشترک، کپی‌های واقعی ایجاد کند. یک snapshot از یک container با حجم 4 GiB، مقدار 4 GiB داده می‌نویسد و به همان اندازه‌ای که cp -a زمان می‌برد، طول می‌کشد. سهمیه‌بندی دیسک (Disk quotas) فقط روی ext4 یا XFS با فعال بودن project quotas در سطح فایل‌سیستم کار می‌کند، که در اکثر imageهای VPS به‌صورت پیش‌فرض فعال نیست؛ بنابراین محدودیت دیسک در یک pool از نوع dir اغلب بی‌اثر است.

btrfs و zfs از نوع copy-on-write هستند، بنابراین یک snapshot فقط بلوک‌هایی را ثبت می‌کند که پس از آن تغییر می‌کنند. Incus این دو را به‌عنوان backendهای توصیه‌شده معرفی می‌کند. snapshotها تقریباً آنی می‌شوند. سهمیه‌بندی دیسک از طریق پشتیبانی داخلی فایل‌سیستم از quota کار می‌کند.

بیشتر پلن‌های VPS یک دیسک بدون پارتیشن اضافه به شما می‌دهند، بنابراین pool را روی یک فایل loop قرار دهید. اگر source= را مشخص نکنید، Incus این کار را برای شما انجام می‌دهد.

sudo apt install -y btrfs-progs
incus storage create fast btrfs size=30GiB
incus profile device set default root pool=fast
incus launch images:debian/13 web2 -s fast

بدون size=، یک pool مبتنی بر loop، مقدار 20% از فضای خالی دیسک را اشغال می‌کند، با حداقل 5 GiB و حداکثر 30 GiB. آن را به‌صورت آگاهانه تنظیم کنید. فایل loop یک فایل روی فایل‌سیستم ریشه شماست، بنابراین pool و میزبان (host) فضای خالی مشترکی دارند؛ این یعنی پر شدن pool باعث پر شدن دیسک میزبان می‌شود.

ZFS در Debian و Ubuntu یک ماژول DKMS است و نه یک ماژول درون هسته (in-tree)، بنابراین با هر ارتقای هسته بازسازی می‌شود و ممکن است پس از ارتقا در ساخت آن خطا رخ دهد. در سروری که روزانه آن را مانیتور نمی‌کنید، btrfs گزینه کم‌دردسرتر بین این دو است.

سه حالت شبکه‌بندی و آنچه هر کدام در معرض دید قرار می‌دهند

incus admin init یک پل مدیریت‌شده به نام incusbr0 ایجاد می‌کند و هر نمونه جدید را روی آن قرار می‌دهد. این یکی از سه روش برای اتصال یک کانتینر است و دو روش دیگر به این دلیل وجود دارند که روش اول، کانتینرهای شما را پشت NAT (ترجمه آدرس شبکه) پنهان می‌کند.

پل مدیریت‌شده (Managed bridge). incusbr0 یک زیرشبکه خصوصی دریافت می‌کند. میزبان اولین آدرس آن را در اختیار دارد و به عنوان دروازه عمل می‌کند؛ Incus روی آن DHCP و DNS (سیستم نام دامنه) را اجرا می‌کند و ترافیک خروجی با اعمال NAT منبع، از طریق آدرس عمومی میزبان خارج می‌شود. تا زمانی که شما دستور ندهید، هیچ چیزی از خارج به کانتینر نمی‌رسد. برای دسترسی، یک پورت را با استفاده از دستگاه proxy فوروارد کنید.

incus config device add web http proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80 nat=true

nat=true به جای پروکسی کردن از طریق یک اتصال فضای کاربری (userspace) جداگانه، با استفاده از قوانین netfilter فوروارد را انجام می‌دهد؛ بنابراین آدرس واقعی کلاینت در لاگ‌های کانتینر حفظ می‌شود. Incus تنها زمانی از این حالت پشتیبانی می‌کند که میزبان، دروازه نمونه باشد که دقیقاً همان مورد incusbr0 است.

macvlan. کانتینر آدرس MAC (کنترل دسترسی رسانه) مخصوص به خود را در شبکه فیزیکی میزبان دریافت می‌کند. در اکثر پلتفرم‌های VPS این روش با شکست مواجه می‌شود، زیرا پورت سوئیچ مجازی به آدرس MAC ماشین مجازی شما محدود شده است و فریم‌های مربوط به آدرس‌های دیگر را حذف می‌کند. محدودیت دومی نیز وجود دارد که حتی در صورت کارکردن روش، کاربران را دچار مشکل می‌کند. Incus مستند کرده است که «دستگاه‌های macvlan، با وجود توانایی برقراری ارتباط بین خود و دنیای خارج، نمی‌توانند با دستگاه والد خود صحبت کنند. این بدان معناست که اگر نیاز دارید نمونه‌های شما با خود میزبان صحبت کنند، نمی‌توانید از macvlan استفاده کنید.»

مسیریابی‌شده (Routed). این حالتی است که معمولاً روی یک VPS با آدرس‌های اضافی کار می‌کند. Incus این دستگاه را به عنوان ابزاری معرفی می‌کند که «یک جفت دستگاه مجازی برای اتصال میزبان به نمونه ایجاد کرده و مسیرهای ایستا (static routes) و ورودی‌های proxy ARP/NDP را تنظیم می‌کند تا نمونه بتواند به شبکه یک رابط والد تعیین‌شده بپیوندد». ARP پروتکل تفکیک آدرس است. کانتینر یک آدرس عمومی را حفظ می‌کند. میزبان به جای آن به درخواست‌های ARP پاسخ می‌دهد، بنابراین ارائه‌دهنده همچنان فقط آدرس MAC میزبان را می‌بیند.

incus config device add web eth0 nic nictype=routed parent=enp1s0 ipv4.address=203.0.113.20

نام رابط والد را از ip route show default بردارید. ایمیج‌های فعلی از نام‌هایی مانند enp1s0 یا ens3 استفاده می‌کنند و به‌ندرت از eth0. نام‌گذاری دستگاه به عنوان eth0، تنظیمات ارائه‌شده توسط پروفایل default را بازنویسی می‌کند، بنابراین کانتینر به جای پل، روی رابط مسیریابی‌شده قرار می‌گیرد. نتیجه را از داخل با ip a و ip route بررسی کنید.

چرا یک کانتینر به سرویسی روی میزبان دسترسی پیدا می‌کند

یک کانتینر روی incusbr0 دارای فضای نام شبکه (network namespace) اختصاصی خود است. این کانتینر هیچ مرز فایروالی در برابر میزبان ندارد. میزبان روی آن پل (bridge) در آدرس gateway قرار دارد، بنابراین از داخل کانتینر، میزبان یک همسایه با دسترسی مستقیم است و هر سرویس میزبان که به 0.0.0.0 متصل (bind) شده باشد، در آنجا پاسخ می‌دهد.

خودتان این موضوع را بررسی کنید. روی میزبان، لیست سرویس‌هایی که در حال گوش دادن هستند را مشاهده کنید.

sudo ss -tlnp

سپس، از داخل یک کانتینر، به gateway که ip route گزارش می‌دهد متصل شوید.

ip route show default
nc -zv 10.0.0.1 6379

اگر یک دیتابیس، یک endpoint برای متریک‌ها یا یک پنل مدیریتی روی میزبان به 0.0.0.0 متصل باشد، این بررسی موفقیت‌آمیز خواهد بود. فایروال شبکهٔ ارائه‌دهندهٔ شما هرگز آن بسته (packet) را ندیده است، زیرا بسته هرگز از ماشین خارج نشده است. این همان نکتهٔ غافلگیرکننده در اکثر پرسش‌های «چگونه به آن دسترسی پیدا کرد» است: کانتینر توسط NAT از اینترنت ایزوله شده، اما توسط هیچ‌چیز از میزبان ایزوله نشده است.

سرویس‌های میزبان را تا حد امکان به 127.0.0.1 متصل کنید. سپس پل را روی میزبان فیلتر کنید. در سیستمی که از ufw استفاده می‌کند، سیاست پیش‌فرض deny ترافیک کانتینر به میزبان را مسدود می‌کند که باعث اختلال در DNS و DHCP سرویس Incus می‌شود؛ راهکاری که مستندات Incus ارائه می‌دهد sudo ufw allow in on incusbr0 است. آن دستور واحد، تمام پورت‌های میزبان را برای تمام کانتینرها باز می‌کند. به‌جای آن، فقط دسترسی‌های مورد نیاز کانتینرها را مجاز کنید.

sudo ufw allow in on incusbr0 to any port 53 proto udp
sudo ufw allow in on incusbr0 to any port 53 proto tcp
sudo ufw allow in on incusbr0 to any port 67 proto udp
sudo ufw route allow in on incusbr0
sudo ufw route allow out on incusbr0

دو قانون ufw route همان مواردی هستند که اجازه می‌دهند ترافیک نمونه (instance) از طریق میزبان به اینترنت عبور کند. بدون آن‌ها، سیاست routed در ufw بسته‌های فوروارد شده را drop می‌کند، بنابراین کانتینرها یک آدرس دریافت می‌کنند اما به هیچ مقصدی نمی‌رسند.

اسنپ‌شات‌ها و پروفایل‌ها

اسنپ‌شات (Snapshot) یک کپی لحظه‌ای از instance در داخل storage pool مربوطه است.

incus snapshot create web pre-upgrade
incus info web
incus snapshot restore web pre-upgrade
incus snapshot delete web pre-upgrade

دستور incus info web اسنپ‌شات‌های موجود برای هر instance را فهرست می‌کند. زمان‌بندی آن‌ها را می‌توانید برای هر instance به‌صورت جداگانه تنظیم کنید.

incus config set web snapshots.schedule=@daily
incus config set web snapshots.expiry=4w

یک اسنپ‌شات در همان pool، روی همان دیسک و در همان سرور ذخیره می‌شود. این قابلیت شما را در برابر ارتقاهای ناموفق محافظت می‌کند، اما در برابر خرابی دیسک یا حذف شدن instance محافظتی ارائه نمی‌دهد. برای پشتیبان‌گیری، از incus export استفاده کنید؛ فایلی که باید از سرور خارج شود.

incus export web /root/web-backup.tar.gz
incus import /root/web-backup.tar.gz

پروفایل (Profile) مجموعه‌ای نام‌گذاری‌شده از کلیدهای پیکربندی و دستگاه‌هایی است که به instanceها اعمال می‌شود. هر instance به‌صورت پیش‌فرض از پروفایل default استفاده می‌کند، مگر اینکه خلاف آن را تعیین کنید؛ این پروفایل همان چیزی است که دیسک ریشه (root disk) و رابط شبکه را برای instance فراهم می‌کند. ویرایش default باعث تغییر در تمام instanceهایی می‌شود که از آن استفاده می‌کنند؛ این ویژگی بسیار کاربردی است و روشی است که مدیران سیستم از طریق آن، شبکه را به‌طور هم‌زمان از بیست کانتینر جدا می‌کنند.

incus profile create small
incus profile set small limits.memory=512MiB
incus profile set small limits.cpu=1
incus launch images:debian/13 api -p default -p small

پروفایل‌ها به ترتیب اعمال می‌شوند، بنابراین کلیدی که در آخرین پروفایل لیست‌شده تنظیم شده باشد، اولویت دارد. برای مشاهده پیکربندی نهایی که یک instance در نهایت دریافت کرده است، از incus config show api --expanded استفاده کنید.

اجرای Docker داخل یک کانتینر Incus

اجرای Docker داخل یک کانتینر سیستمی Incus نیازمند فعال‌سازی قابلیت nesting است، زیرا Docker فضاهای نام (namespaces) و mountهای اختصاصی خود را ایجاد می‌کند که کانتینرها به‌صورت پیش‌فرض اجازهٔ ایجاد آن‌ها را ندارند.

incus config set web security.nesting=true
incus restart web

مستندات Incus در security.nesting این قابلیت را به‌عنوان «آیا اجازهٔ nesting داخل instance داده شود» تعریف می‌کند و مقدار پیش‌فرض آن برای کانتینرها false است. دو نکتهٔ دیگر مستقیماً از بخش FAQ در Incus استخراج شده‌اند. یک کانتینر نمی‌تواند ماژول‌های هسته (kernel modules) را بارگذاری کند؛ بنابراین ماژول موردنیاز Docker باید روی میزبان (host) بارگذاری شده و در incus config set web linux.kernel_modules overlay,br_netfilter فهرست شود. همچنین، ایجاد یک فایل /.dockerenv داخل کانتینر باعث می‌شود Docker از برخی بررسی‌هایی که در محیط nested با شکست مواجه می‌شوند، صرف‌نظر کند.

روی میزبان‌های Ubuntu 24.04، محدودیت‌های فضای نام کاربری بدون امتیاز (unprivileged user namespace) در AppArmor می‌تواند مانع از اجرای pivot_root شود که runc انجام می‌دهد. Docker داخل کانتینر پیام زیر را چاپ می‌کند:

failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error jailing process inside rootfs: pivot_root .: permission denied

و در dmesg میزبان، خطی حاوی apparmor="DENIED" operation="pivotroot" class="mount" مشاهده می‌شود. تنظیمی که کاربران معمولاً به سراغ آن می‌روند kernel.apparmor_restrict_unprivileged_userns است. غیرفعال کردن آن راهکار مطمئنی نیست: گزارش باگ رسمی Incus برای این مورد خاص نشان می‌دهد که تنظیم آن روی 0 مشکل را حل نکرده است. پیش از تغییر تنظیمات امنیتی پیش‌فرض، ابتدا dmesg را برای مشاهدهٔ دلیل مسدودسازی (denial) مطالعه کنید تا مطمئن شوید مشکل واقعاً از AppArmor است.

اگر ترجیح می‌دهید کانتینرها را مستقیماً روی VPS اجرا کنید و یک لایه را حذف کنید، اجرای Docker روی VPS این پیکربندی را به‌طور مستقل پوشش می‌دهد.

Failure modes, with the strings you will see

Instances lose all network after you install Docker on the host. The Incus documentation names the cause: "Docker sets the global FORWARD policy to drop, which prevents Incus from forwarding traffic and thus causes the instances to lose network connectivity." Instances keep their addresses and reach nothing. Set ip-forward-no-drop to true in /etc/docker/daemon.json, then make forwarding persistent and let the bridge through Docker's own chain.

echo "net.ipv4.conf.all.forwarding=1" | sudo tee /etc/sysctl.d/99-forwarding.conf
sudo systemctl restart systemd-sysctl
sudo iptables -I DOCKER-USER -i incusbr0 -j ACCEPT
sudo iptables -I DOCKER-USER -o incusbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Those iptables rules do not survive a reboot on their own. Persist them.

Containers stop starting with a cgroup error. The Incus FAQ documents this one. A message about Failed to mount "/sys/fs/cgroup" usually means a VPN client on the host mounted the net_cls cgroup v1 controller over cgroup v2, which Incus uses. sudo umount /sys/fs/cgroup/net_cls clears it.

Instance gets no IPv4 address. incus list shows it running with an empty address column. DHCP replies from the host are being dropped, most often by a host firewall that does not know about the bridge. On ufw, sudo ufw allow in on incusbr0 to any port 67 proto udp restores it. Watch the requests arrive with sudo tcpdump -ni incusbr0 port 67.

Instance refuses to start on a nested VPS. Read incus info <name> --show-log first, then sudo journalctl -u incus -n 50. If systemd-detect-virt said lxc or openvz, the missing piece is on the provider's side, and no setting inside your VPS changes it.

Snapshots are slow and the disk keeps filling. You are on a dir pool. incus storage list prints the driver for each pool. Moving to a copy-on-write pool means creating the new pool, copying instances into it with incus copy web web-new -s fast, then deleting the originals once you have checked the copies start.

FAQ

آیا کانتینر Incus همان کانتینر Docker است؟

خیر. Docker یک پردازش یا برنامهٔ واحد را بسته‌بندی می‌کند. یک کانتینر سیستمی Incus، یک سیستم‌عامل کامل را شبیه‌سازی می‌کند که دارای init، کاربران، سرویس‌ها و مدیر بستهٔ مخصوص به خود است. شما یک کانتینر Incus را نگهداری و مانند یک سرور وصله‌گذاری (patch) می‌کنید. کانتینر Docker را دور می‌اندازید و آن را از روی یک image دوباره می‌سازید. شما می‌توانید با تنظیم security.nesting=true روی کانتینر، Docker را داخل یک کانتینر Incus اجرا کنید. عکس این موضوع امکان‌پذیر نیست.

آیا می‌توانم Incus را روی یک VPS اجرا کنم؟

روی یک KVM VPS، بله. اگر systemd-detect-virt خروجی kvm یا qemu را نشان دهد، شما هسته (kernel) اختصاصی خود را دارید و Incus دقیقاً مانند سخت‌افزار عمل می‌کند. اگر خروجی lxc، lxc-libvirt یا openvz باشد، VPS شما خود یک کانتینر است؛ بنابراین کانتینرهای Incus در داخل آن به‌صورت تو در تو (nested) هستند و تنها در صورتی کار می‌کنند که ارائه‌دهندهٔ سرویس، قابلیت nesting را برای کانتینر شما فعال کرده باشد. همچنین uname -r را بررسی کنید، زیرا تا اوت 2026، شاخهٔ پایدار فعلی Incus حداقل هسته 6.12 را مستند کرده است، در حالی که شاخه 6.0 LTS نسخه 5.4 را مستند کرده است.

برای Incus روی یک VPS کدام storage backend را انتخاب کنم؟

از btrfs روی یک فایل loop استفاده کنید، مگر اینکه یک block device اضافه برای اختصاص دادن داشته باشید. درایور dir بسیار کندتر از سایرین مستند شده است، زیرا به‌جای استفاده از copy-on-write، فایل‌ها را کپی می‌کند؛ بنابراین هر snapshot کل کانتینر را دوباره می‌نویسد. incus admin init --minimal گزینه dir را انتخاب می‌کند، به همین دلیل پاسخ دادن به پرسش‌های تعاملی ارزش دو دقیقه وقت گذاشتن را دارد. pool را با incus storage create fast btrfs size=30GiB ایجاد کنید.

چرا کانتینر Incus من می‌تواند به سرویسی که روی host اجرا می‌شود دسترسی داشته باشد؟

زیرا bridge پیش‌فرض incusbr0، میزبان (host) را در همان زیرشبکهٔ کانتینر و در آدرس gateway قرار می‌دهد و هیچ فیلتری بین آن‌ها وجود ندارد. هر سرویس میزبان که به 0.0.0.0 متصل (bind) شده باشد، در آنجا پاسخ می‌دهد و فایروال ارائه‌دهندهٔ شما هرگز این بسته‌ها را نمی‌بیند، زیرا آن‌ها هرگز از ماشین خارج نمی‌شوند. سرویس‌های میزبان را به 127.0.0.1 متصل کنید و روی یک میزبان با ufw، به‌جای دسترسی کلی sudo ufw allow in on incusbr0، فقط اجازه ورود DNS و DHCP را روی incusbr0 بدهید.

چگونه از یک کانتینر Incus نسخه پشتیبان تهیه کنم؟

incus export web /root/web-backup.tar.gz نمونه (instance) و snapshotهای آن را در یک فایل می‌نویسد و incus import آن را روی همان سرور یا سرور دیگری بازیابی می‌کند. snapshotهایی که با incus snapshot create گرفته می‌شوند، نسخه پشتیبان نیستند: آن‌ها در همان storage pool و روی همان دیسک قرار دارند، بنابراین در برابر یک به‌روزرسانی ناموفق مقاوم‌اند اما در برابر خرابی سرور خیر. آن‌ها را با incus config set web snapshots.schedule=@daily زمان‌بندی کنید و فایل‌های خروجی را از روی دستگاه کپی کنید.