ما دور PUID وPGID في Docker Compose؟

ما هي PUID وPGID فعلياً

PUID وPGID متغيرا بيئة تقرؤهما بعض صور الحاويات عند بدء التشغيل. لا يقرأ Docker هذين المتغيرين بنفسه. إنهما اصطلاح تستخدمه صور linuxserver.io وبعض الصور الأخرى. لذلك تتجاهلهما أي صورة لم تُبرمج لقراءتهما بصمت.

داخل صورة linuxserver.io يوجد مستخدم اسمه abc. يُنشأ هذا المستخدم وقت بناء الصورة، ويحمل UID (معرّف المستخدم) بقيمة 911 وGID (معرّف المجموعة) بقيمة 911. تبدأ الحاوية بصلاحيات root، وتشغّل نصوص التهيئة الخاصة بها. يعيد أحد هذه النصوص ترقيم ذلك المستخدم قبل حدوث أي شيء آخر:

groupmod -o -g "${PGID}" abc
usermod -o -u "${PUID}" abc

يسمح الخيار -o باستخدام معرّف مستخدم مستخدم بالفعل في موضع آخر. بعد ذلك، تخفّض التهيئة الصلاحيات وتشغّل التطبيق باسم abc. لذلك لا يصل PUID=1000 إلى Docker أبداً. يعيد المتغير ترقيم مستخدم داخل الحاوية قبل بدء التطبيق. وهذا يعني أن كل ملف ينشئه التطبيق على القرص لديك يكون مملوكاً للمستخدم ذي المعرّف 1000. إذا تركت PUID غير مضبوط، يحتفظ abc بالمعرّف 911. ولهذا تمتلئ bind mount غير المهيّأة بملفات مملوكة لـ911:911.

احصل على الرقمين باستخدام id

نفّذ هذا على المضيف، بصفتك المستخدم الذي يملك أدلة البيانات:

id

uid=1000(deploy) gid=1000(deploy) groups=1000(deploy),27(sudo),988(docker)

uid هو PUID الخاص بك، وgid هو PGID الخاص بك. لاستخدامهما في برنامج نصي، يطبع id -u وid -g الرقمين فقط. في معظم صور VPS الجديدة، يكون الحساب البشري الأول هو 1000:1000، لكن لا تفترض ذلك. قد يعطي الخادم الذي أُعيد بناؤه، أو الحساب الثاني الذي أُضيف لاحقاً، الرقم 1001 أو رقماً أعلى. والرقم الخاطئ هنا هو سبب المشكلة بالكامل. إذا كانت خدماتك تعمل تحت حساب خدمة مخصص بدلاً من مستخدم تسجيل الدخول الخاص بك، فنفّذ id thatuser وخذ الرقمين من الناتج.

لماذا تظهر ملفاتك بالمالك 911:911

تعرض ls -l معرّفاً رقمياً بدلاً من اسم عندما لا يطابقه أي حساب على المضيف. لا يوجد حساب بالمعرّف UID 911 على خادمك، لذلك لا يوجد اسم لعرضه. استخدم ls -ln لعرض الأرقام دائماً وإزالة الالتباس:

ls -ln /srv/appdata/sonarr

drwxr-xr-x 2 911 911 4096 Aug  7 09:12 Backups
-rw-r--r-- 1 911 911  512 Aug  7 09:12 config.xml

يوضح هذا الناتج أن الحاوية عملت باستخدام القيم الافتراضية المضمّنة. تحقّق من ذلك من داخل الحاوية بدلاً من التخمين:

docker exec sonarr id abc
docker compose logs sonarr | head -n 25

تعرض عملية التهيئة في linuxserver النتيجة في سجل بدء التشغيل على شكل سطرين:

User UID:    911
User GID:    911

إذا عرض هذان السطران القيمة 911 بعد ضبط PUID=1000 في ملف Compose، فهذا يعني أن المتغير لم يصل إلى الحاوية. السبب المعتاد هو أنك عدّلت docker-compose.yml ثم شغّلت docker compose restart، الذي يعيد استخدام الحاوية الحالية مع بيئتها الأصلية. تتطلب تغييرات البيئة استخدام docker compose up -d، إذ يعيد إنشاء الحاوية.

لماذا لا يمكنك حذف ملف كتبه الـcontainer

تقارن النواة الأرقام، وليس الأسماء. تعمل الصدفة لديك باستخدام UID 1000. ويعود الملف إلى UID 911. أما الدليل الذي يحتويه فهو drwxr-xr-x ويعود أيضاً إلى 911، لذلك يحصل كل من المجموعة والآخرين على صلاحيتَي القراءة والتنفيذ، من دون الكتابة. يتطلب حذف ملف صلاحية الكتابة على دليله، وليس على الملف نفسه، لذلك تحصل على النتيجة التالية حتى عندما يبدو الملف نفسه غير ضار:

rm: cannot remove '/srv/appdata/sonarr/config.xml': Permission denied

يواجه الـcontainer الذي يكتب المشكلة نفسها من الجهة الأخرى. إذا كان دليل المضيف يعود إلى مستخدمك وبصلاحيات 755، بينما يعمل التطبيق باستخدام 911، تفشل أول عملية كتابة له مع Permission denied، ويعرض التطبيق ذلك بصياغته الخاصة. في تطبيق .NET مثل Sonarr أو Radarr، يظهر الخطأ على شكل UnauthorizedAccessException: Access to the path '/data/downloads' is denied. تخبرك سلسلة الصلاحيات الموجودة قبل اسم الملف بأي مجموعة من مجموعات الصلاحيات الثلاث تُطبَّق عليك فعلياً، كما أن قراءة drwxr-xr-x بشكل صحيح هي ما يحوّل هذا الخطأ من أمر غامض إلى نتيجة واضحة.

هذه مشكلة خاصة بـ bind mount. عندما ينشئ Docker named volume فارغاً ويربطه بمسار موجود في image، ينسخ محتويات ذلك المسار إلى volume، بما في ذلك الملكية وبتات الصلاحيات، لذلك يجد التطبيق دليلاً يملكه مسبقاً. لا يحصل bind mount على هذه المعالجة: إذ يربط Docker دليل المضيف كما هو تماماً. وهذا الاختلاف أحد الأسباب العملية لمعرفة متى يكون bind mount أفضل من named volume ومتى لا يكون كذلك.

إصلاح دليل توجد فيه مشكلة مسبقاً

يغيّر ضبط PUID وPGID سلوك التطبيق من الآن فصاعداً. لكنه لا يصلح بأثر رجعي الملفات الموجودة على القرص. أوقف الـstack، وصحّح الملكية بنفسك، ثم شغّله مرة أخرى:

docker compose down
sudo chown -R 1000:1000 /srv/appdata/sonarr
docker compose up -d

استخدم sudo chown -R "$(id -u):$(id -g)" /srv/appdata/sonarr إذا كنت تفضّل عدم كتابة الأرقام. نفّذ ذلك بعد إيقاف الحاوية، لأن تطبيقاً قيد التشغيل ويكتب في أثناء تنفيذ chown تكرارياً قد يترك شجرة الدليل مصحّحة جزئياً، ويسبب جولة ثانية مربكة من الأخطاء.

ما الذي لا يصلحه PUID وPGID

هذا هو الجزء الذي يفاجئ من نفّذ كل شيء بشكل صحيح. تنفّذ عملية التهيئة في linuxserver الأمر chown على ثلاثة مسارات فقط عند بدء التشغيل: /app و/config و/defaults. أما نقاط تحميل الوسائط فلا توجد في هذه القائمة. تُمرَّر /data و/downloads و/tv إلى التطبيق دون تعديل، لذلك إذا كانت ملكية الجانب الموجود على المضيف من نقاط التحميل لا تسمح لمستخدم الحاوية بالكتابة، تبدأ الحاوية بشكل سليم، وتعرض UID الصحيح في الشعار، ثم تفشل عند أول عملية استيراد.

هذا هو السلوك الصحيح. سيكون تنفيذ chown بشكل تكراري على مكتبة وسائط حجمها اثنا عشر تيرابايت عند كل بدء للحاوية كارثياً. لكنه يعني أن أدلة الوسائط مسؤوليتك، وهي نقاط التحميل التي تحدث فيها أخطاء الصلاحيات فعلياً. ولأن هذا النوع من الأعطال يظهر بصمت في سجل التطبيق بعد ساعات من ظهور الحاوية بحالة سليمة، فإن اختبار كتابة دوري مرتبط بخدمة ntfy على VPS الخاص بك، مع إرسال التنبيهات إلى هاتفك طريقة بسيطة ومنخفضة التكلفة لمعرفة المشكلة قبل أن يكشفها غياب الحلقات لمدة أسبوع.

ثلاث طرق للتحكم في المستخدم، ومتى تُستخدم كل منها

متغيرا البيئة PUID وPGID

يعمل هذا الخيار فقط مع الصور التي يقرأها entrypoint. وهو شائع لأن الحاوية تبدأ بصلاحيات root، وتجري إعدادها الخاص، وتصلح /config، ثم تخفّض الصلاحيات. وتستمر Docker Mods وcustom init scripts في العمل. لكنك تعتمد بذلك على اصطلاح بدلاً من ميزة توفرها المنصة، كما أن أسماء المتغيرات ليست موحّدة بين المشاريع.

المفتاح user: في Compose

هذه ميزة فعلية في Docker وتعمل مع كل صورة، لأن وقت تشغيل الحاوية يطبّقها قبل تشغيل تعليمات الصورة نفسها:

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    user: "1000:1000"

لا تعمل العملية بصلاحيات root إطلاقاً، حتى لفترة وجيزة، وهذا مكسب أمني حقيقي. لكنه يعطّل أيضاً أي جزء في entrypoint يحتاج إلى root. في صور linuxserver، يدعم المشروع هذا الخيار على أساس بذل جهد معقول، وفقط للصور التي اختبرها. وتتمثل القيود المحددة في أن PUID وPGID لن يكون لهما أي تأثير، ولن تعمل Docker Mods، ولن تعمل custom services، وستصبح مسؤولاً عن صلاحيات كل volume موصول. ويقرن النمط الموثق لديهم هذا الخيار مع /run قابل للكتابة:

user: 1000:1000
tmpfs:
  - /run:uid=1000,gid=1000,exec
security_opt:
  - no-new-privileges=true

يفاجئ أحد الآثار الشكلية بعض المستخدمين. لا يملك user: رقمي إدخالاً مطابقاً في /etc/passwd الخاص بالحاوية، لذلك تعرض الأدوات داخلها whoami: cannot find name for user ID 1000. يظل المعرّف صالحاً ويعمل الوصول إلى الملفات بصورة طبيعية. الذي يفشل فقط هو البحث عن الاسم.

Rootless Docker

يشغّل Rootless Docker الـdaemon نفسه بصلاحيات المستخدم غير المميّز، ولذلك لا يعمل أي شيء على الخادم بصلاحيات root الفعلية. ويغيّر ذلك حسابات الملكية بالكامل. يُطابق UID 0 داخل الحاوية مع UID المستخدم المضيف الذي يشغّل Rootless Docker، بينما يُطابق UID n داخل الحاوية، لأي n قيمته 1 أو أكثر، مع subuid + (n - 1)، حيث يكون subuid أساس النطاق المخصّص لك في /etc/subuid و/etc/subgid. ويتوقع Docker وجود 65,536 معرّفاً فرعياً على الأقل هناك.

اقرأ هذا الربط مرة أخرى، لأنه يعكس النصيحة المعتادة. في Rootless Docker، تنشئ الحاوية التي تكتب بصلاحيات root ملفات يملكها المستخدم نفسه. أما الحاوية التي تكتب بالمعرّف UID 1000 فتنشئ ملفات يملكها معرّف فرعي يقع تقريباً حول 100999، ولا يستطيع shell الخاص بك الوصول إليها. لذلك تكون قيمة PUID الصحيحة في daemon يعمل بصلاحيات root هي القيمة الخاطئة هنا. تحل الآليتان المشكلة نفسها على مستويين مختلفين، ويؤدي استخدامهما معاً دون تحقق إلى أن تجد نفسك أمام دليل تحتاج إلى sudo لحذفه. إذا اخترت التشغيل دون root، فاختبر ملكية ملف واحد تكتبه على خادمك قبل نقل مكتبة إليه.

بالنسبة إلى معظم حزم الخدمات المستضافة ذاتياً على VPS واحد، يُعدّ استخدام PUID وPGID مع daemon يعمل بصلاحيات root الخيار العملي، لأن الصور مبنية وموثّقة وفق هذا النمط. استخدم user: عندما يذكر README الخاص بالصورة أنّها اختُبرت وفق هذا النمط، أو عندما تشغّل صورة رسمية من الجهة المطوّرة لا تدعم PUID إطلاقاً. تندرج مساحة عمل للمستندات مثل مثيل AFFiNE مستضاف ذاتياً على VPS واحد ضمن الحالة الأخيرة، لأن أياً من حاوياتها لا يقرأ PUID، ولأن ملكية دليل قاعدة البيانات والملفات المرفوعة يحددها runtime، لا أي إعداد في كتلة البيئة. وينطبق الأمر نفسه على مكتب دعم Chatwoot مستضاف ذاتياً، حيث تكتب حاوية Rails وعامل Sidekiq التابع لها في دليل uploads واحد، ولا يقرأ أيٌّ منهما PUID؛ لذلك يجب أن تتوافق ملكية ذلك الدليل مع المستخدم الذي تعمل به الصورة مسبقاً. ولا يتغير ذلك في حزمة أحدث أيضاً، لذا فإن منح كل شخص في الفريق وكيل OneCLI معزولاً خاصاً به يترك أدلة مساحة العمل الخاصة بكل شخص ودليل بيانات Postgres مملوكة للمستخدم الذي تعمل به كل صورة مسبقاً، ما يجعلها مشكلة user: وchown بدلاً من كونها مشكلة PUID. وإذا وضعت واجهة API واحدة مستضافة ذاتياً أمام Codex وClaude Code وHermes، فستحصل على الترتيب نفسه، لأن تلك الصورة تعمل باستخدام مستخدم مضمّن خاص بها، كما أن bind mount الذي يحتوي على قاعدة بياناتها ومفاتيحها المخزنة يتخذ ملكية ذلك المستخدم.

حالة حزمة الوسائط: مجموعة واحدة مشتركة بين الحاويات

تتوقف المسألة عن كونها نظرية عند استخدام حزمة وسائط arr مع Sonarr وRadarr وعميل تنزيل. يكتب عميل التنزيل ملفاً مكتملًا في /data/downloads. ثم ينشئ Sonarr رابطاً صلباً لذلك الملف أو ينقله إلى /data/media. لكي يعمل الرابط الصلب، تحتاج الحاويتان إلى صلاحية الكتابة في الشجرة نفسها. وإذا كان عميل التنزيل يعمل بالمعرّف 1000 بينما يعمل Sonarr بالمعرّف 1001، فستمتلك إحدى الحاويتين ملفات لا تستطيع الأخرى إلا قراءتها.

الحل هو إنشاء مجموعة مشتركة تستخدمها كل حاوية في الحزمة بوصفها PGID:

sudo groupadd -g 13000 media
sudo usermod -aG media deploy
sudo chown -R deploy:media /srv/media
sudo find /srv/media -type d -exec chmod 2775 {} +
sudo find /srv/media -type f -exec chmod 0664 {} +

إنّ 2 الموجود في بداية 2775 هو بت setgid. يعني هذا البت في الدليل أن كل ملف ودليل فرعي جديد يُنشأ داخله يرث المجموعة media بدلاً من وراثة المجموعة الأساسية الخاصة بالمنشئ. لذلك يستمر هذا الترتيب مع عمليات التنزيل الجديدة من دون إعادة تشغيل chown. سجّل الخروج ثم سجّل الدخول مجدداً، أو شغّل newgrp media، قبل التحقق من صلاحياتك. فالمجموعة التي تُضاف باستخدام usermod -aG لا تظهر في جلسة shell مفتوحة مسبقاً.

داخل الحاوية، يعيد groupmod -o -g 13000 abc ترقيم المجموعة abc إلى 13000، لكي يكتب abc باستخدام GID نفسه لمجموعة المضيف media. تحتفظ كل حاوية في الحزمة بـPUID الخاص بها، وتشترك في PGID واحد. ويشمل ذلك الحاويات اللاحقة في السلسلة التي تقرأ مكتبة الوسائط المكتملة فقط، مثل Jellyfin نفسه والواجهات التي يضيفها المستخدمون إليه، مثل Halcyon التي تعرض تلك المكتبة كمتجر فيديو من حقبة التسعينيات يمكن التجول فيه.

بعد ذلك، اضبط UMASK=002 في كل حاوية linuxserver ضمن الحزمة. هذه هي الخطوة التي يغفل عنها المستخدمون. القيمة الافتراضية في هذه الصور هي UMASK=022، وهي تزيل بت الكتابة الخاص بالمجموعة من كل ملف جديد. لذلك تُنشأ الملفات بصلاحيات 0644، ولا تعود المشاركة التي أعددتها للتو مفيدة. ينتج 002 ملفات بصلاحيات 0664 وأدلة بصلاحيات 0775، وتستطيع المجموعة الكتابة:

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=002
      - TZ=Etc/UTC
    volumes:
      - /srv/appdata/sonarr:/config
      - /srv/media:/data
    restart: unless-stopped

ينبغي وضع هاتين القيمتين في ملف .env بجوار ملف Compose، لكي تقرأ الحزمة بأكملها تعريفاً واحداً:

PUID=1000
PGID=13000

يقرأ Compose ذلك الملف تلقائياً لاستبدال القيم بأسلوب ${PUID}، وهي الآلية نفسها المستخدمة مع بيانات الاعتماد. وتنطبق هنا أيضاً ممارسات إبقاء القيم خارج docker-compose.yml ووضعها في ملف .env، مع اختلاف أن هذين الرقمين ليسا سريين.

تحقق من العملية كاملة بدلاً من الوثوق بالإعدادات. اكتب ملفاً من داخل إحدى الحاويات واقرأه من المضيف:

docker exec sonarr touch /data/downloads/permtest
ls -ln /srv/media/downloads/permtest

تُظهر النتيجة السليمة أن PUID الخاص بك هو المالك، وأن 13000 هي المجموعة، وأن -rw-rw-r-- هي الصلاحيات. إذا ظهرت المجموعة بالصيغة 1000، فهذا يعني أن بت setgid مفقود من ذلك الدليل. وإذا ظهرت الصلاحيات بالصيغة -rw-r--r--، فهذا يعني أن متغير UMASK لم يُطبّق. تحقق من أنك أنشأت الحاوية من جديد بدلاً من إعادة تشغيلها. احذف ملف الاختبار باستخدام rm /srv/media/downloads/permtest عند الانتهاء.

ما المتغير الذي تستخدمه كل صورة

تستخدم صور linuxserver.io المتغيرات PUID وPGID وUMASK. يستخدم Paperless-ngx أسماء مختلفة للفكرة نفسها: USERMAP_UID وUSERMAP_GID، وكلاهما تكون قيمته الافتراضية 1000، وتطلب وثائقه قراءتهما من id -u وid -g. وتعرض خوادم الصور التباين نفسه: لدى PhotoPrism زوج المتغيرات الخاص به PHOTOPRISM_UID وPHOTOPRISM_GID، بينما لا يوفر Immich بديلاً مماثلاً، ويترك مستخدم الحاوية لقيمة Docker في المفتاح user:. لذلك فإن الاختيار بين PhotoPrism وImmich يحدد أيضاً آلية إدارة الملكية التي ستستخدمها لمكتبة الصور الأكبر على الخادم. تأتي كثير من الصور الرسمية من المشاريع الأصلية، بما فيها صور قواعد البيانات وخوادم الويب الشائعة، بمستخدم مضمّن ثابت، وتتوقع منك استخدام user: أو تركه كما هو. تطرح عمليات النشر الصغيرة لتطبيق واحد السؤال نفسه. لذلك، عند تشغيل متتبع تمارين openGym مستضاف ذاتياً، تحقّق من المستخدم الفعلي الذي تعمل به حاويته قبل ربط bind mount بها، لأن الدليل الذي يحتوي قاعدة بياناتها سيرث هذه القيمة سواء عيّنت PUID أم لا. ويندرج مرحّل الوصول عن بُعد ضمن الفئة نفسها. لذلك، عند تشغيل خادم RustDesk relay الخاص بك، يصل زوج مفاتيح Ed25519 الذي يكتبه hbbs عند التشغيل الأول إلى bind mount مملوكاً للمستخدم الذي انتهت الصورة من استخدامه، ويكون chown على المضيف هو التصحيح الوحيد المتاح لك. وينطبق الأمر نفسه على البنية التحتية التي تضيفها لاحقاً. فعند وضع Authentik أمام تطبيقاتك لتوفير تسجيل دخول موحّد، ستشغّل صور الخادم وPostgres وRedis الرسمية، وهي لا تقرأ PUID إطلاقاً، وتأتي ملكية وحدات التخزين الخاصة بها من بيئة التشغيل، لا من entrypoint يمكنك إعداده.

لذلك، راجع README الخاص بكل صورة قبل نسخ كتلة بيئية بين المشاريع. يمرر Docker أي متغير بيئة تعيّنه إلى أي حاوية، سواء قرأه شيء داخلها أم لا. وينتج عن PUID لا يستهلكه أي مكوّن عدم وجود خطأ أو تحذير أو تأثير. تعمل الحاوية بالمستخدم الذي انتهى Dockerfile الخاص بها من تحديده، ويمكنك معرفة ذلك من ملكية الملفات التي تكتبها. أجرِ هذه المراجعة قبل إضافة أي شيء جديد إلى الخادم، بما في ذلك حزمة فحص أمني open-kritt مستضافة ذاتياً، إذ يوضح ملف Compose ما إذا كانت الصور تحترم PUID، أو ما إذا كانت ملكية الأدلة التي تربطها ثابتة ومحددة من الصور نفسها.

FAQ

لماذا تعود ملكية ملفات Docker لدي إلى 911:911؟

يمثل 911 كلاً من UID وGID للمستخدم abc المضمّن في صور linuxserver.io. ظهور هذه القيم يعني أن الحاوية بدأت من دون تعيين PUID وPGID، ولذلك أبقى سكربت التهيئة القيم الافتراضية المضمّنة. يعرض ls -l الأرقام الخام لأن أياً من الحسابات على الخادم المضيف لا يملك المعرّف 911، ولذلك لا يوجد اسم لعرضه. عيّن PUID وPGID إلى ناتج id، ثم أعد إنشاء الحاوية باستخدام docker compose up -d، وبعد ذلك أصلح ملكية الملفات الموجودة باستخدام sudo chown -R 1000:1000 على الدليل المتأثر.

هل يعمل PUID وPGID مع كل صورة Docker؟

لا. فهما ليسا ميزة في Docker، ولا يقرأهما Docker أبداً. يعملان فقط مع الصور التي يقرأ مدخلها الخاص هاتين القيمتين ويستدعي usermod وgroupmod قبل بدء التطبيق. ينطبق ذلك على عائلة linuxserver.io وبعض المشاريع التي نسخت هذا النمط. تستخدم مشاريع أخرى أسماء مختلفة، مثل USERMAP_UID وUSERMAP_GID في paperless-ngx. في الصورة التي لا تقرأ أياً منهما، تُقبل المتغيرات ويُتجاهل محتواها من دون أي تحذير.

هل أستخدم PUID وPGID أم مفتاح user: في Docker Compose؟

استخدم PUID وPGID عندما تدعمهما الصورة، لأن entrypoint يستمر في العمل بصفة root مدة كافية لإصلاح /config وبدء خدماته الخاصة بصورة صحيحة. استخدم user: عندما لا تدعم الصورة PUID، أو عندما يذكر README الخاص بها أنها مختبرة للعمل دون root. في صورة linuxserver، يؤدي تعيين user: إلى جعل PUID وPGID غير فعّالين، وإيقاف Docker Mods والخدمات المخصصة، وجعل صلاحيات كل volume موصول مسؤوليتك أنت.

لدى Sonarr قيمة PUID الصحيحة، لكنه لا يزال عاجزاً عن نقل الملفات. ما المشكلة؟

تحقق من ثلاثة أمور بالترتيب. أولاً، افحص mount الوسائط نفسه: إذ لا تنفذ التهيئة chown إلا على /app و/config و/defaults، ولذلك يحتفظ /data أو /downloads بملكيته الموجودة على الخادم المضيف. ثانياً، افحص المجموعة المشتركة: إذا كان عميل التنزيل وSonarr يعملان باستخدام GID مختلف، فلن يتمكن أي منهما من تعديل ملفات الآخر. لذلك امنح كل حاوية في المجموعة نفسها PGID. ثالثاً، افحص umask: تكتب القيمة الافتراضية للصورة UMASK=022 الملفات بالصيغة 0644 من دون بت الكتابة للمجموعة، مما يلغي فائدة المجموعة المشتركة بالكامل. عيّن UMASK=002 واضبط بت setgid على الأدلة باستخدام chmod 2775 لكي ترث الملفات الجديدة المجموعة.