يحدّد المصدر طبقة الملكية الفعلية بشكل صحيح: عندما تنشئ حاوية دليلًا داخل مجلد ZimaOS موصول، فإن الدليل الجديد يرث عادةً هوية العملية التي تعمل داخل الحاوية وسلوك umask الخاص بها، وليس الأذونات التي كنت تأمل أن يفرضها المجلد الأب تلقائيًا.
ولهذا السبب قد ينتهي الأمر بمجلد أب قابل للكتابة عالميًا إلى احتواء مجلدات فرعية جديدة مملوكة لـ root:root وبأذونات 0755. فإذا كان التطبيق يعمل بامتيازات root ويستخدم umask افتراضيًا، فمن المتوقع أن تكون المجلدات الفرعية مملوكة لـ root، ما لم تدعم الصورة PUID/PGID أو مستخدمًا محددًا للحاوية أو وراثة مجموعة setgid أو أذونات ACL الافتراضية أو نموذج أذونات آخر.
كان مثال المصدر مجلد نسخ احتياطي موصولًا
وصف المستخدم مسارًا مثل:
/media/Daten/Backupحيث أصبحت المجلدات الفرعية المنشأة حديثًا:
root:root
drwxr-xr-xوبذلك كان بإمكان مستخدم غير root، مثل UID 999، قراءة الملفات في تلك المجلدات الفرعية الجديدة، لكنه لم يكن قادرًا على إنشائها.
لا يفرض المجلد الأب ذو الأذونات 0777 ملكية المجلدات الفرعية
يسمح إذن الكتابة في المجلد الأب لعملية الحاوية بإنشاء مجلد فرعي، لكنه لا يجعل المجلد الفرعي يرث مالك المجلد الأب أو مجموعته تلقائيًا، إلا إذا تم إعداد قواعد نظام الملفات أو المجموعة لهذا السلوك.
تحدد UID/GID الخاصة بالمنشئ وumask الخاصة بالعملية النتيجة المعتادة.
استخدم PUID/PGID فقط عندما تدعمهما صورة الحاوية
توفّر العديد من الصور المستندة إلى LinuxServer متغيري البيئة PUID وPGID. أما الصور الأخرى فقد تتجاهل هذين المتغيرين تمامًا، وتتطلب استخدام الحقل user: في Docker أو إعدادات خاصة بالتطبيق.
تطلب إرشادات Syncthing الحالية من IceWhale صراحةً الاستعلام عن معرّفات مستخدم ZimaOS الفعلية باستخدام:
id -u username
id -g usernameثم إدخال هذه القيم في حقلي PUID/PGID الخاصين بالتطبيق.
راجع مثال PUID/PGID الحالي في ZimaOS.
تتحكم umask في بتات الأذونات التي تُزال عند الإنشاء
سينشئ تطبيق ينشئ المجلدات بوضع أساسي 0777، مع umask شائعة بقيمة 022، مجلدات بأذونات 0755. وقد تستخدم بيئة العمل التعاونية القائمة على المجموعة umask مختلفة إذا كان التطبيق يدعم ذلك.
لا تضبط umask شديدة التساهل على مستوى النظام لمجرد إصلاح تطبيق واحد.
يمكن أن تساعد setgid في الحفاظ على مجموعة مشتركة في المجلدات الفرعية الجديدة
في أنظمة الملفات الأصلية في Linux، يمكن أن يؤدي ضبط بت setgid على مجلد مشترك إلى جعل العناصر الفرعية المنشأة حديثًا ترث مجموعة المجلد. ويكون ذلك مفيدًا عندما تتعاون خدمات أو مستخدمون متعددون عمدًا من خلال مجموعة واحدة.
لكنها لا تغيّر معرّف مستخدم العملية المنشئة، وقد لا تعمل بالطريقة نفسها على نقاط توصيل NTFS/exFAT التي تحاكي ملكية Unix من خلال خيارات التوصيل.
توفّر قوائم ACL الافتراضية وراثة أكثر وضوحًا
في أنظمة الملفات التي تدعم قوائم ACL الخاصة بـ POSIX، يمكن لإدخالات ACL الافتراضية تحديد الأذونات التي تحصل عليها العناصر الفرعية الجديدة. وغالبًا ما يكون ذلك أنظف من تشغيل chmod تكراري بعد كل مهمة نسخ احتياطي.
ينبغي التحقق مما إذا كانت واجهة ZimaOS الحالية توفّر سير عمل كاملًا لقوائم ACL لمسار تخزين معين قبل الاعتماد على إعدادات مقتصرة على الصدفة.
كان المصدر طلب ميزة، وليس إعدادًا موجودًا في ZimaOS
طلب الكاتب تحكمًا عامًا في PUID/PGID، وخيارًا للوراثة، ومعالجة umask، ودعم setgid، وواجهة رسومية للإصلاح التكراري. ولا يتضمن النقاش ردًا من IceWhale يؤكد تنفيذ هذه الميزات.
لا تعرض قائمة الطلبات على أنها خيارات حالية في الإعدادات.
أصلح هوية التطبيق قبل تغيير القرص بأكمله تكراريًا
إذا كان تطبيق النسخ الاحتياطي يعيد إنشاء مجلدات مملوكة لـ root باستمرار، فإن تشغيل chown -R بعد كل مهمة يعالج العَرَض فقط. اضبط هوية الحاوية والمجموعة وumask بشكل صحيح أولًا، ثم أصلح شجرة الملفات المتأثرة فقط.
تتيح إعدادات تطبيقات ZimaOS الحالية للمستخدمين فحص تعيينات وحدات التخزين وإعدادات التطبيق، بينما تعتمد متغيرات الأذونات الدقيقة على الصورة.
الأسئلة الشائعة حول ملكية المجلدات الموصولة
لماذا قد يصبح مجلد فرعي مملوكًا لـ root:root تحت مجلد أب قابل للكتابة؟
لأن العملية داخل الحاوية أنشأته بامتيازات root، ولأن المجلد الأب لا يتجاوز هوية المنشئ تلقائيًا.
هل يعمل PUID وPGID مع كل صور Docker؟
لا. فهما اصطلاحان خاصان ببيئة الصورة، وليسَا متغيرين عامين في Docker.
هل أكدت IceWhale وجود خيار عام لوراثة الأذونات في المصدر؟
لا. فالنقاش عبارة عن طلب ميزة من دون تأكيد تنفيذها.
