لماذا تتغير ملكية ملفات الحاوية بعد نسخ بيانات التطبيق؟

إيفا وونغ

IceWhale author

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

Why Do Container File Owners Change After Copying App Data?

تتغير ملكية ملفات الحاويات بعد النسخ عندما لا تُحفَظ قيم UID/GID الرقمية أو عندما تعيد بيئة التشغيل تعيينها أو كتابتها.

على جهاز NAS منزلي، قد يظهر الملف نفسه باسم مستخدم على المضيف وباسم آخر داخل الحاوية، لأن الملكية تُخزَّن كأرقام، بينما تحل كل بيئة هذه الأرقام من خلال قاعدة حسابات مختلفة. كما قد تستبدل عمليات النسخ التي تتم عبر واجهة رسومية أو مشاركة SMB أو أرشيف أو موجّه أو أداة ترحيل أو نقطة دخول الحاوية الملكيةَ أيضًا. شخّص الهوية الرقمية أولًا، ثم ميّز بين سلوك النسخ وإعدادات مستخدم بيئة التشغيل والبرامج النصية عند بدء التشغيل ومساحات أسماء المستخدمين وربط أنظمة الملفات عبر الشبكة قبل تغيير الأذونات على شجرة بيانات التطبيق بأكملها.

قارن UID وGID الرقميين قبل مقارنة أسماء المستخدمين

افحص المصدر والوجهة مع إظهار الملكية الرقمية، وليس الأسماء فقط. سجّل UID وGID والوضع وقوائم ACL والسمات الموسّعة ونظام الملفات لملف نموذجي واحد ودليلّه الأب على كل من المضيف وداخل الحاوية.

تُظهر عمليات الربط في Docker ملفات المضيف لعمليات قد تستخدم قاعدة مستخدمين مختلفة. يوضح نقاش مجتمعي حول أذونات Docker أن الوصول الموثوق يعتمد على تطابق UID/GID الرقميين، لا على تطابق أسماء المستخدمين وحدها.

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

حدّد ما إذا كان النسخ قد حافظ على الملكية أو أنشأها من جديد

دوّن مسار النسخ الدقيق: مدير ملفات المضيف أو cp أو rsync أو أرشيف tar أو عميل SMB/NFS أو استعادة نسخة احتياطية أو أمر نسخ Docker أو حاوية ترحيل مؤقتة. لكل طريقة إعدادات افتراضية مختلفة للمالك والمجموعة وقوائم ACL والسمات الموسّعة.

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

كرّر العملية باستخدام دليل اختبار صغير واحد، وافحص الملكية فورًا قبل بدء التطبيق. إذا كانت الأرقام خاطئة منذ البداية، فأصلح طريقة النسخ أو خيارات الاستعادة. وإذا تغيرت فقط بعد بدء التشغيل، فاترك النسخة كما هي وابحث في نقطة دخول الحاوية.

طابق مستخدم بيئة تشغيل الحاوية مع مالك التخزين على المضيف

افحص المستخدم الفعلي داخل الحاوية قيد التشغيل والمالك الرقمي لدليل بيانات التطبيق المرتبط. تحقق أيضًا من user: في Compose والمجموعات الإضافية ومتغيرات PUID/PGID الخاصة بالمنصة وأي إعدادات حساب خاصة بالصورة.

لا يمنح تشغيل الحاوية كمستخدم غير جذر تلقائيًا صلاحية الوصول إلى دليل على المضيف يملكه معرّف رقمي آخر. تعالج حالة في منتدى Docker المشكلة عبر مطابقة مستخدم الحاوية مع أذونات المضيف بدلًا من جعل الدليل قابلًا للكتابة للجميع.

اختر نموذج ملكية ثابتًا للتطبيق ووثّقه في Compose. أضف المجموعات المطلوبة فقط للوصول المشترك. تجنب chmod 777 لأنه يخفي عدم تطابق الهوية ويضعف العزل ولا يحافظ على المالك المقصود للملفات المستقبلية.

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

تحقق مما إذا كانت نقطة الدخول تغيّر الملكية عند بدء التشغيل

تبدأ العديد من الصور لفترة وجيزة بصلاحيات الجذر، وتنشئ الأدلة المفقودة، وتطبّق UID/GID مُعدّين، ثم تغيّر الملكية بشكل تكراري قبل خفض الصلاحيات. وقد يجعل هذا السلوك نسخة صحيحة تبدو وكأنها تغيرت تلقائيًا بعد أول تشغيل للحاوية.

قد توفر بيئات تشغيل الحاويات والصور أيضًا سلوكًا يغيّر ملكية نقاط الربط. تشير مشكلة في Podman إلى أن الخيار :U يمكنه إعادة كتابة ملكية المصدر، بينما قد تنفذ البرامج النصية لنقطة الدخول تغييرًا تكراريًا مشابهًا أثناء بدء تشغيل التطبيق.

شغّل الحاوية مرة واحدة مع إظهار السجلات وراقب شجرة اختبار صغيرة. ابحث في نقطة الدخول وملاحظات إصدار الصورة عن chown وترحيل المستخدم وPUID/PGID وخطوات إصلاح الأذونات. عطّل هذا السلوك أو قلّص نطاقه فقط عندما تدعم الصورة بديلًا ثابتًا.

ضع في الحسبان Docker بلا جذر ومساحات أسماء المستخدمين وأنظمة الملفات عبر الشبكة

يترجم Docker بلا جذر وإعادة تعيين مساحة أسماء المستخدمين معرّفات الحاوية إلى نطاق مضيف آخر. كما قد تعمل NFS وCIFS وبعض خيارات الربط في أجهزة NAS على إسقاط صلاحيات الجذر أو فرض UID وGID محددين على جميع الملفات.

يوضح تقرير عن أذونات Docker بلا جذر ظهور الملفات بملكية غير متوقعة لأن هوية الحاوية تُترجم عبر نطاق مضيف فرعي. وتتمثل الإشارة التشخيصية في تعيين ملكية مساحة أسماء المستخدمين، لا في فشل نسخ تقليدي.

تحقق مما إذا كان مسار البيانات محليًا أو NFS أو CIFS أو FUSE أو نظام ملفات مركّبًا آخر، ثم سجّل سلوك UID/GID وإسقاط الجذر وقوائم ACL الخاصة به. اختبر إنشاء الملكية من المضيف ومن الحاوية كلٌّ على حدة. لا تنفذ chown تكراريًا على مشاركة شبكية قبل فهم سياسة الهوية على الخادم.

أصلح الملكية انطلاقًا من هوية تطبيق معروفة

أوقف التطبيق، وانسخ البيانات الوصفية الحالية احتياطيًا، وحدد UID وGID الدقيقين، وأوضاع الأدلة والملفات، وقوائم ACL، وتسميات الأمان التي تتوقعها الصورة. صحّح المسارات التي يملكها التطبيق فقط، مع استثناء الوسائط المشتركة أو مجموعات البيانات غير المرتبطة.

يُعد دليل ZimaSpace حول الفصل بين أعطال الأذونات والربط للقراءة فقط هو الفحص التالي عندما لا تسمح الملكية الصحيحة بالكتابة رغم ذلك.

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