كيفية منع انحراف الأذونات في مجلدات بيانات Immich

يعني منع انحراف الصلاحيات في Immich جعل ملكية الملفات وقواعد الوصول قابلة للتنبؤ قبل أن تنشئ الحاويات المختلفة أو بروتوكولات NAS أو التحديثات أو مهام الصيانة ملفات جديدة بهويات مختلفة.

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

سجّل الهويات التي تقرأ كل مسار من مسارات Immich وتكتب فيه

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

أدرج العمليات التي تكتب خارج Immich في هذه الجردة. إذ يمكن لتحميلات SMB وعملاء NFS وأدوات النسخ الاحتياطي وبرامج الاستيراد وحاويات إدارة الوسائط وواجهة shell الخاصة بالمسؤول إنشاء ملفات جميعًا ضمن الشجرة نفسها. وإذا فعلت ذلك بهويات مختلفة، فقد تراكم المكتبة تدريجيًا ملاكًا وأنماط وصول تعمل لمسار واحد لكنها تفشل لمسار آخر.

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

استخدم نموذجًا مدروسًا للمالك والمجموعة المشتركة والحد الأدنى من الوصول

حدد الهوية التي ينبغي أن تملك البيانات التي يديرها التطبيق، وأي مجموعة مشتركة، إن وُجدت، تحتاج إلى الوصول. امنح كل سير عمل حقوق القراءة أو الكتابة التي يحتاجها فقط. تجنب جعل شجرة Immich بأكملها قابلة للكتابة من الجميع لمجرد أن حاوية واحدة لا تستطيع إنشاء صورة مصغرة أو نقل ملف مستورد.

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

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

اجعل صلاحيات الملفات الجديدة قابلة للتنبؤ

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

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

أنشئ ملف اختبار صغيرًا عبر كل مسار كتابة عادي: تحميل Immich، وسير عمل الاستيراد، ونقل SMB/NFS إن استُخدم، واستعادة النسخ الاحتياطي. افحص المالك والمجموعة والنمط وقائمة ACL بعد كل اختبار. وإذا نتجت عن مساري إنشاء ملفين نتائج غير متوافقة، فحل تعارض السياسة قبل استيراد مزيد من البيانات.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

امنع تغييرات نقاط التحميل والتحديثات من إعادة كتابة الملكية

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

قد تُدخل عمليات النقل والتخزين الشبكي هويات SMB/NFS مختلفة، ومعرّفات رقمية، وتوارثًا مختلفًا لقوائم ACL، وسلوكًا مختلفًا لـ umask. استخدم نقاط فشل تغيّر صلاحيات NAS كقائمة تحقق قبل التغيير كلما نُقلت بيانات Immich بين أنظمة ملفات أو طرق وصول مختلفة.

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

دقّق في الانحراف باختبارات صغيرة قابلة للتكرار

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

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

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