تثبيت Docker على Rocky Linux وAlmaLinux

تثبيت Docker على Rocky Linux وAlmaLinux

لتثبيت Docker على Rocky Linux أو AlmaLinux، أضف مستودع dnf الخاص بـDocker، وثبّت المحرك مع إضافة compose، ثم فعّل الخدمة. يتطلب ذلك أربعة أوامر، والخطوات متطابقة في التوزيعتين لأن كلتيهما إعادة بناء لـRed Hat Enterprise Linux (RHEL) وتشتركان في بنية الحزم نفسها. يعمل CentOS Stream بالطريقة نفسها.

التثبيت مختصر، لذلك يركّز معظم هذا الدليل على الاختلافات التي يفرضها Enterprise Linux (EL) مقارنةً بـUbuntu. قد يكون Podman قد تولّى الأمر docker في صورتك. يحظر SELinux الملفات المرتبطة عبر bind mount إلى أن تحمل التصنيف الصحيح. لا يفلتر Firewalld المنافذ التي ينشرها Docker، لذلك قد يكون منفذ الحاوية مفتوحاً على الإنترنت بينما يعرض firewall-cmd عدم وجود أي منفذ مفتوح.

لا تستخدم سكربت التسهيل الخاص بـDocker من get.docker.com. توضح وثائق Docker الخاصة أن استخدامه غير موصى به في بيئات الإنتاج. يعيد كتابة إعدادات المستودعات من دون طلب تأكيد، ولا يمكن تشغيله مرة أخرى بأمان لإجراء الترقية. تعني إضافة المستودع يدوياً أن dnf upgrade يتعامل مع Docker مثل أي حزمة أخرى على الخادم.

هل يجيب podman عن أمر docker بالفعل؟

تأتي Rocky Linux وAlmaLinux مع podman في مستودعاتهما الافتراضية، وتثبّته كثير من صور VPS تلقائياً. تذهب بعض الصور إلى أبعد من ذلك وتثبّت podman-docker، الذي يضع برنامج shell النصي في /usr/bin/docker لاستدعاء podman. لذلك ينفّذ podman كل أمر docker تكتبه، ويبدأ الدليل المكتوب لـDocker في عرض مخرجات غير متوقعة.

أول مؤشر هو شريط تنبيه. يتحقق البرنامج النصي /usr/bin/docker من وجود الملف /etc/containers/nodocker، وعندما يكون الملف مفقوداً يطبع سطراً واحداً قبل تنفيذ أي شيء:

Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.

قد يكون أحدهم قد أنشأ هذا الملف لإخفاء شريط التنبيه، لذلك لا تعتمد عليه وحده. اطلب من قاعدة بيانات الحزم تحديد الحزمة المالكة للملف التنفيذي:

command -v docker
rpm -qf "$(command -v docker)"

تعني إجابة تبدأ بـpodman-docker أن podman هو الذي يجيب. وتعني إجابة تبدأ بـdocker-ce-cli أن Docker الحقيقي هو المستخدم. إذا أبلغ rpm -qf عن عدم امتلاك أي حزمة للملف، فهذا يعني أن أحدهم ثبّته يدوياً، وعليك قراءة البرنامج النصي قبل الوثوق به.

ينفّذ Podman صور OCI نفسها، وهو خيار مناسب. إذا كنت تريده، فتوقف هنا. وإذا كنت تريد Docker Engine، فأزل الحزم المتعارضة أولاً. هذه هي القائمة التي توثقها Docker لنظام RHEL:

sudo dnf remove docker docker-client docker-client-latest docker-common \
  docker-latest docker-latest-logrotate docker-logrotate docker-engine podman runc

اقرأ ما يخطط dnf لإزالته معها قبل التأكيد. تكون القائمة قصيرة في صورة VPS جديدة. أما في خادم استخدمه أحدهم من قبل، فقد تؤدي إزالة podman إلى إزالة cockpit-podman أو أداة أخرى تعتمد عليها.

يمكن من حيث المبدأ إبقاء podman إلى جانب Docker: أزل podman-docker فقط، لكي يصبح الاسم docker متاحاً، وأزل runc، الذي تستبدله الحزمة containerd.io. تتعامل وثائق Docker مع podman بوصفه حزمة متعارضة، لذلك لا تدعم Docker هذا الترتيب. إذا استمر التثبيت في الإبلاغ عن تعارض، فاستخدم قائمة الإزالة الكاملة أعلاه.

إضافة مستودع Docker باستخدام dnf config-manager

تنشر Docker حزم RPM لأنظمة Enterprise Linux في download.docker.com. يشير ملف المستودع إلى شجرة CentOS، وهي الشجرة التي يحل إليها Rocky Linux وAlmaLinux. وفقاً للوثائق التي راجعتها في أغسطس 2026، توفّر Docker هذا المستودع لـ CentOS Stream 9 وCentOS Stream 10.

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

أزال الإصدار 5 من dnf الوسيطة --add-repo، لذلك يفشل الأمر الثاني في الإصدارات الأحدث. تحقّق من الإصدار المثبّت لديك، ثم استخدم الصيغة المطابقة:

dnf --version

إذا طبع الأمر إصداراً من السلسلة 5.x، فاستخدم صيغة الأمر الفرعي بدلاً منها:

sudo dnf config-manager addrepo --from-repofile=https://download.docker.com/linux/centos/docker-ce.repo

تكتب الصيغتان الملف نفسه في /etc/yum.repos.d/docker-ce.repo. تفشل الصيغة الخاطئة برسالة تفيد بوجود وسيطة غير معروفة، بدلاً من تنفيذ شيء خاطئ بصمت، لذلك ستلاحظ المشكلة.

يعيّن ملف المستودع هذا baseurl إلى مسار يحتوي على $releasever، ويوسّع dnf قيمة هذا المتغير من حزمة الإصدار المثبّتة لديك. يعيّنه Rocky Linux وAlmaLinux إلى رقم الإصدار الرئيسي، لذلك تكون قيمته 9 في EL 9 و10 في EL 10. ولهذا يُحل مستودع CentOS بصورة صحيحة على خادم Rocky. أكّد نتيجة التوسيع قبل تثبيت أي حزم:

sudo dnf repoinfo docker-ce-stable

اقرأ السطر Repo-baseurl. يجب أن ينتهي بـ /9/x86_64/stable أو /10/x86_64/stable. إذا عيّن إصدارك $releasever إلى إصدار فرعي مثل 9.6، فسيعرض dnf الخطأ Status code: 404 لهذا الرابط عند جلب البيانات الوصفية. أصلح ذلك بتحرير /etc/yum.repos.d/docker-ce.repo واستبدال $releasever بالرقم الرئيسي المجرد.

تثبيت المحرك وملحق Compose

sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

خمسة حزم، ولكل منها وظيفة واحدة. docker-ce هو البرنامج الخفي، وdockerd. docker-ce-cli هو الأمر docker الذي تكتبه. containerd.io هو وقت تشغيل الحاويات الذي يديره البرنامج الخفي. تنشئ docker-buildx-plugin الصور. وتوفر docker-compose-plugin الأمر الفرعي docker compose.

لا تثبّت هذه الحزم ملفاً تنفيذياً باسم docker-compose يتضمن واصلة. كان ذلك خاصاً بـ Compose v1، الذي انتهى عمره في July 2023. يجب تحديث أي شيء يستدعي docker-compose ذي الواصلة إلى docker compose ذي المسافة.

يتوقف التثبيت الأول لاستيراد مفتاح توقيع Docker ويعرض بصمته. يأتي المفتاح من gpgkey=https://download.docker.com/linux/centos/gpg المحدد في ملف المستودع الذي أضفته للتو، لذلك قارن البصمة التي يعرضها dnf بعنوان URL هذا قبل قبول المفتاح.

يظهر أحد الأعطال كثيراً بما يكفي لتسميته. إذا أبلغ dnf بأن containerd.io يتطلب container-selinux ولم يوفره أي شيء، فإن مستودع AppStream معطّل. شغّل dnf repolist وتأكد من إدراج appstream، لأن container-selinux يُصدر ضمنه على EL 9 وEL 10.

شغّل Docker وتحقّق من عمله

sudo systemctl enable --now docker
sudo systemctl status docker --no-pager
sudo docker run --rm hello-world

تترك حزم RPM الخاصة بـDocker البرنامج الخفي متوقفاً ومعطلاً بعد التثبيت. لذلك تظهر هذه الخطوة في صفحة Docker الخاصة بـCentOS، ولا تظهر في صفحة Ubuntu، حيث تشغّل حزمة deb الخدمة تلقائياً. إذا تخطّيت enable، فسيستمر Docker في العمل حتى إعادة التشغيل التالية، ثم يبقى متوقفاً ويتسبب في توقف جميع الحاويات معه.

يجب أن يعرض systemctl status القيمة Active: active (running). ويجب أن تطبع حاوية hello-world القيمة This message shows that your installation appears to be working correctly. ثم تنتهي. إذا طبعت بدلاً من ذلك خطأ صلاحيات على /var/run/docker.sock، فقد حذفت sudo، ويعالج قسم مجموعة docker أدناه ذلك.

تحقّق من إضافة compose بشكل منفصل، لأنها حزمة مختلفة وقد تكون مفقودة رغم أن المحرك يعمل جيداً:

docker compose version

تبدو النتيجة السليمة مثل Docker Compose version v2.x.x. استعادة خدماتك بعد إعادة التشغيل مسألة منفصلة عن تمكين البرنامج الخفي، وتحدد سياسات إعادة التشغيل ما إذا كانت خدمات Compose ستعود عند الإقلاع.

لماذا يؤدي bind mount إلى رفض الإذن؟

تشغّل Rocky Linux وAlmaLinux ‏SELinux (Security-Enhanced Linux) بوضع enforcing افتراضياً. تحقّق من ذلك باستخدام getenforce، الذي يطبع Enforcing.

تعمل حاويات Docker ضمن نوع SELinux ‏container_t، ولا يمكن لهذا النوع قراءة الملفات وكتابتها إلا إذا كانت موسومة بـcontainer_file_t. يحمل الدليل الذي أنشأته على المضيف الوسم الذي يمنحه له المسار الأب، وهذا الوسم ليس container_file_t. تُرفض العملية داخل الحاوية رغم أن المالك والمجموعة والصلاحيات تبدو صحيحة من جهة المضيف. أعد إنتاج المشكلة بثلاثة أوامر:

sudo mkdir -p /srv/site
echo hello | sudo tee /srv/site/index.html
sudo docker run --rm -v /srv/site:/usr/share/nginx/html:ro nginx:alpine cat /usr/share/nginx/html/index.html

تطبع الحاوية:

cat: can't open '/usr/share/nginx/html/index.html': Permission denied

يوضح أمران السبب. يطبع ls -ldZ /srv/site الوسم، ويكون المسار الواقع تحت /srv موسوماً بـsystem_u:object_r:var_t:s0، وليس container_file_t. ثم يطبع sudo ausearch -m avc -ts recent سجل التدقيق الخاص بالنواة، الذي يحتوي على avc: denied { read }، وهو حقل scontext= يسمّي container_t، وحقل tcontext= يسمّي الوسم الذي رأيته للتو على الدليل. عدم التطابق بين هذين الحقلين يفسّر المشكلة بالكامل.

الحل هو إضافة لاحقة إلى وسيط volume. يعيد Docker وسم المسار نيابةً عنك:

sudo docker run --rm -v /srv/site:/usr/share/nginx/html:ro,z nginx:alpine cat /usr/share/nginx/html/index.html

تعيد :z بالأحرف الصغيرة وسم المحتوى بوصفه مشتركاً، لذلك يمكن لعدة حاويات استخدام الدليل نفسه. أما :Z بالأحرف الكبيرة فتعيد وسمه بوصفه خاصاً وغير مشترك، وتربطه بحاوية واحدة؛ وعندها تُرفض قراءة الحاوية الثانية للمسار نفسه. استخدم :z لأي محتوى يصل إليه sidecar أو حاوية نسخ احتياطي أيضاً. واستخدم :Z لدليل قاعدة بيانات تملكه حاوية واحدة.

تتضمن وثائق Docker تحذيراً يستحق التكرار، لأن إعادة الوسم تتم بصورة تكرارية. إن إجراء bind mount لدليل نظام مثل /home أو /usr باستخدام :Z «يجعل جهازك المضيف غير قابل للتشغيل، وقد تحتاج إلى إعادة وسم ملفات الجهاز المضيف يدوياً». وجّه هذه اللواحق إلى الأدلة التي أنشأتها للحاوية، ولا تستخدمها مطلقاً مع مسار نظام.

في Compose، توضع اللاحقة ضمن السلسلة نفسها:

services:
  web:
    image: nginx:alpine
    volumes:
      - /srv/site:/usr/share/nginx/html:ro,z

من السهل الوقوع في حدّين. لا يستطيع الخيار --mount تعيين وسم SELinux إطلاقاً، لذلك استخدم -v عندما تحتاج إلى تعيينه. لا تحتاج named volumes إلى لاحقة، لأن Docker يوسم الأدلة التي ينشئها تحت /var/lib/docker/volumes بنفسه.

لا تعطّل SELinux. استخدم sudo setenforce 0 لاختبار يستغرق دقيقة واحدة فقط: إذا عملت الحاوية عندها، فالمشكلة في وسم، و:z هو الحل. أعد تفعيله فوراً باستخدام sudo setenforce 1. في Enterprise Linux، يكون permission denied على bind mount ناتجاً عن سببين منفصلين يبدوان متطابقين من داخل الحاوية. الأول هو وسم SELinux. والثاني هو ملكية المستخدم والمجموعة الرقمية العادية، وهي المشكلة التي صُممت متغيرات PUID وPGID لحلها. يعرض ls -lnZ الوضع والمالك الرقمي والوسم في سطر واحد، لتعرف أي مشكلة تواجهها.

لماذا يمكن الوصول إلى منفذ منشور مع أن firewalld يبدو مغلقاً؟

يُعد firewalld جدار الحماية الافتراضي في Rocky Linux وAlmaLinux. تحقّق من تشغيله باستخدام sudo systemctl is-active firewalld. انشر منفذاً الآن وتحقّق مما يعتبره firewalld مفتوحاً:

sudo docker run -d --name web -p 8080:80 nginx:alpine
sudo firewall-cmd --list-ports

يطبع firewall-cmd سطراً فارغاً. من جهاز آخر، يعرض curl -I http://YOUR_SERVER_IP:8080/ النتيجة HTTP/1.1 200 OK. المنفذ مفتوح على الإنترنت، بينما لا يعرض جدار الحماية أي شيء عنه.

السبب هو المسار الذي تسلكه الحزمة. ترشّح قواعد المناطق في firewalld حركة المرور الموجّهة إلى الخادم نفسه. أما المنفذ المنشور فلا تكون الحزمة موجّهة إلى الخادم؛ إذ يثبّت Docker قاعدة NAT للوجهة (ترجمة عنوان الشبكة) تعيد كتابة الوجهة إلى عنوان الحاوية قبل وصول الحزمة إلى مسار الإدخال في الخادم، لذلك يمرّر kernel الحزمة بدلاً من تسليمها محلياً. ثم يضع Docker واجهات الجسر الخاصة به في منطقة firewalld المسماة docker، والتي يكون هدفها ACCEPT، ويضيف سياسة تمرير باسم docker-forwarding تسمح بالتمرير من أي منطقة إلى منطقة docker. لذلك لا ترى قواعد منطقتك الحزمة.

لا يحتاج الإصلاح الأنظف إلى قاعدة جدار حماية. اربط جانب الخادم من النشر بواجهة loopback وضع reverse proxy أمامه:

sudo docker rm -f web
sudo docker run -d --name web -p 127.0.0.1:8080:80 nginx:alpine
curl -I http://127.0.0.1:8080/

يعرض curl المحلي النتيجة HTTP/1.1 200 OK، ولا يعود الطلب نفسه من جهاز آخر متصلاً. يُنشر أي منفذ لا يتضمن عنوان خادم في وسيطة -p على كل الواجهات، لذلك اعتبر استخدام -p 8080:80 دون عنوان قراراً بتعريض الخدمة للعامة.

عندما تحتاج إلى إتاحة خدمة لبعض العناوين ومنعها عن عناوين أخرى، يوفّر Docker سلسلة مخصّصة لذلك. تُعالج DOCKER-USER قبل قواعد القبول الخاصة بـDocker، لذلك تبقى القاعدة التي تضعها هناك بعد إعادة تشغيل Docker وإعادة كتابة سلاسله:

sudo iptables -I DOCKER-USER -i enp1s0 ! -s 203.0.113.10 -j DROP
sudo iptables -S DOCKER-USER

استخرج اسم الواجهة من ip route show default بدلاً من افتراض eth0، لأن صور EL الحالية تستخدم أسماء مثل enp1s0 أو ens3. في Rocky وAlmaLinux، يُعد الأمر iptables طبقة توافق فوق nftables، وتظهر سلاسل Docker من خلاله. تختفي القواعد المضافة بهذه الطريقة بعد إعادة التشغيل ما لم تحفظها، لذلك اكتبها في وحدة systemd بعد التأكد من ملاءمتها.

أغلق Docker Engine 28.0، الذي صدر في 2025، ثغرة مجاورة: أصبح الوصول الموجّه مباشرة إلى منافذ الحاويات التي لم تُنشر محجوباً في سلسلة DOCKER. لا يؤثر هذا التغيير في المنافذ المنشورة، لذلك ما سبق كله ما زال ينطبق على الإصدارات الحالية. من المفيد اعتماد عادة تشغيلية واحدة: بعد أي sudo firewall-cmd --reload، اختبر المنفذ المنشور مرة أخرى. إذا توقف عن الاستجابة، يعيد sudo systemctl restart docker تثبيت قواعد Docker.

يواجه مديرو Ubuntu المشكلة نفسها من خلال أداة مختلفة، وهي سبب تجاهل منافذ Docker المنشورة لقواعد ufw. مسار NAT هو السبب في الحالتين. الذي يتغير هو جدار الحماية الموجود أمامه فقط.

إضافة مستخدم غير root إلى مجموعة docker

سرعان ما يصبح إدخال sudo قبل كل أمر docker مملاً، وتلغي مجموعة docker الحاجة إلى ذلك:

sudo usermod -aG docker $USER
newgrp docker
docker run --rm hello-world

يعدّل usermod -aG الملف /etc/group، لكن shell الحالي يحتوي بالفعل على قائمة مجموعاته، لذلك لا يسري التغيير حتى تبدأ جلسة جديدة. يبدأ newgrp docker shell مع إرفاق المجموعة، ما يتيح لك الاختبار فوراً. وتلتقط جلسات SSH الجديدة التغيير تلقائياً.

كن واضحاً بشأن الصلاحيات التي تمنحها هذه المجموعة. تمنح العضوية صلاحية الكتابة إلى /var/run/docker.sock، وأي شيء يمكنه الاتصال بذلك socket يستطيع أن يطلب من daemon بدء container يحمّل نظام ملفات المضيف. يوضح أمر واحد معنى ذلك:

docker run --rm -v /:/host alpine wc -l /host/etc/shadow

يقرأ هذا الأمر ملفاً لا يستطيع قراءته إلا root، من حساب لا يملك صلاحيات sudo. وتذكر وثائق Docker الخاصة بما بعد التثبيت الأمر نفسه: تمنح مجموعة docker صلاحيات مكافئة لصلاحيات root. أضف حساباً إليها فقط إذا كنت ستمنحه أيضاً sudo. إذا كنت تُعدّ حسابات على خادم جديد، فاحسم هذا الأمر ضمن بقية إعداد حسابات المستخدمين بأقل قدر من الصلاحيات على VPS، وليس بعد ذلك.

يوفّر Docker أيضاً وضع rootless الذي يشغّل daemon كمستخدم غير ذي صلاحيات. وله مسار تثبيت مستقل، ويغيّر طريقة عمل برامج تشغيل التخزين والمنافذ الأقل من 1024، لذلك خطط له كمشروع مستقل، وليس كخيار تضيفه لاحقاً.

الخطوة التالية

لديك الآن المحرك، وCompose plugin، وخدمة تستمر في العمل بعد إعادة التشغيل، والسلوكيات الثلاثة الخاصة بـEL الموثقة أعلاه. الخطوة التالية هي compose.yaml لكل خدمة، ويشرح تركيب ملف Compose تنسيق الملف والأوامر التي تديره. إذا كان هذا أول مضيف حاويات تستخدمه، فستتناول تشغيل Docker على VPS مسائل تحديد الموارد والتخزين ونظافة الصور التي لا يغطيها هذا الدليل.

FAQ

هل يعمل مستودع Docker الخاص بـCentOS على Rocky Linux وAlmaLinux؟

نعم. أضف https://download.docker.com/linux/centos/docker-ce.repo باستخدام dnf config-manager. يحتوي baseurl في ذلك الملف على $releasever، ويستبدله Rocky Linux وAlmaLinux برقم الإصدار الرئيسي، لذلك يحل جهاز EL 9 المسار CentOS 9، بينما يحل جهاز EL 10 المسار CentOS 10. أكّد عملية الاستبدال باستخدام sudo dnf repoinfo docker-ce-stable واقرأ السطر Repo-baseurl. يعني ظهور Status code: 404 عند جلب dnf للبيانات الوصفية أن المتغير استُبدل بإصدار فرعي، ويؤدي تعديل /etc/yum.repos.d/docker-ce.repo لاستخدام الرقم الرئيسي المجرد إلى إصلاح المشكلة.

هل يمكن تثبيت Docker وpodman على الخادم نفسه؟

تدرج وثائق Docker podman وrunc كحزمتين متعارضتين، وتطلب إزالة كلتيهما قبل تثبيت Docker Engine. يتمثل التعارض الفعلي في حزمة podman-docker، التي تملك /usr/bin/docker وتحول كل أمر docker إلى أمر podman. شغّل rpm -qf "$(command -v docker)" لمعرفة الحزمة التي تملك ذلك المسار. إذا بدأ الناتج بـpodman-docker، فإن podman هو الذي يستجيب. لا يدعم Docker تشغيل المحركين معاً بهذا الترتيب، لذلك اختر أحدهما على الخادم المهم.

لماذا يحصل الحاوي على خطأ رفض الإذن عند استخدام bind mount؟

يكون SELinux في وضع الإنفاذ افتراضياً على Rocky Linux وAlmaLinux. تعمل الحاويات بالنوع container_t، ولا يمكنها الوصول إلا إلى الملفات الموسومة بـcontainer_file_t، لذلك يحمل الدليل الذي أنشأته الوسم الخطأ ويُرفض الوصول إليه بغض النظر عن مالكه ووضعه. أكّد ذلك باستخدام ls -ldZ على مسار المضيف وsudo ausearch -m avc -ts recent، الذي يطبع avc: denied مع سياقيْن غير متطابقين. أضف :z إلى وسيطة volume للمحتوى المشترك بين الحاويات، أو :Z للمحتوى الخاص بحاوية واحدة. لا توجّه :Z مطلقاً إلى /home أو /usr، لأن إعادة الوسم تكرارية وستؤدي إلى تعطيل المضيف.

هل أحتاج إلى فتح منفذ في firewalld لنشر منفذ حاوية؟

لا، وهذه هي المشكلة. تعيد قاعدة NAT في Docker كتابة عنوان الوجهة قبل وصول الحزمة إلى مسار الإدخال في المضيف، لذلك لا تفحصها قواعد المناطق في firewalld. كما يضع Docker جسورَه في منطقة firewalld المسماة docker، مع الهدف ACCEPT. يمكن الوصول إلى حاوية بدأت باستخدام -p 8080:80 من الإنترنت، بينما لا يطبع sudo firewall-cmd --list-ports أي شيء. انشر الخدمة على عنوان محدد باستخدام -p 127.0.0.1:8080:80 عندما يجب أن يتمكن المضيف وحده من الوصول إليها، أو أدرج قواعد التصفية في السلسلة DOCKER-USER، التي يعالجها Docker قبل قواعد القبول الخاصة به.

هل تُعد إضافة مستخدمي إلى مجموعة docker آمنة؟

إنها تمنحه صلاحيات root. يستطيع عضو مجموعة docker الكتابة إلى /var/run/docker.sock، ثم يقرأ docker run --rm -v /:/host alpine wc -l /host/etc/shadow ملفاً لا يمكن الوصول إليه إلا بواسطة root من حساب لا يملك صلاحيات sudo. وتذكر وثائق Docker الخاصة بالإعداد بعد التثبيت التكافؤ نفسه. أضف فقط الحسابات التي كنت ستثق بها أصلاً مع sudo، واستمر في استخدام sudo docker للحسابات المشتركة أو حسابات الخدمات. يُعد الوضع بلا root بديلاً عند الحاجة إلى تشغيل الحاويات تحت مستخدم غير متمتع بالصلاحيات، وهو مسار تثبيت منفصل وليس إعداداً.