لماذا يعيد Immich إنشاء الملفات المفقودة بمالك خاطئ؟

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

استخدم كائنًا واحدًا مُعاد إنشاؤه يمكن التخلص منه ودليلَه الأب. قارن UID/GID الرقميين وقوائم ACL على المضيف مع هوية الكاتب الفعلية داخل الحاوية، ثم حدّد ما إذا كان Immich أو ميزة كتابة الملفات الجانبية أو بروتوكول NAS أو عملية أخرى على المضيف هو الذي أنشأه فعليًا. تجنّب استخدام chown التكراري أو chmod 777 إلى أن تتعرّف على ذلك الكاتب.

قارن الملف المُعاد إنشاؤه بدليله الأب وبملف مجاور معروف سلامته

سجّل المالك والمجموعة والوضع وقائمة ACL والسمات الممتدة عند الحاجة، إضافة إلى UID/GID الرقميين للملف المُعاد إنشاؤه ودليله الأب وملف أقدم يعمل بصورة صحيحة. قد تكون الأسماء مضللة عبر NAS والحاوية؛ إذ تكشف المعرّفات الرقمية ما إذا كان «immich» في أحد النظامين يشير إلى الهوية نفسها في النظام الآخر.

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

حدّد العملية وUID/GID الفعليين اللذين يكتبان البديل

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

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

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

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

أصلح قاعدة الإنشاء بدلًا من إصلاح الملفات الموجودة مرارًا

صحّح أصغر حدّ مؤكد: وحّد UID/GID الخاص بالخدمة حيثما كان ذلك مدعومًا، أو أصلح وراثة المجموعة أو قائمة ACL في الدليل الأب، أو اضبط umask مناسبًا، أو غيّر تعيين المشاركة في NAS الذي يزوّدك بالهوية الخاطئة. حافظ على قدرة Immich وأي قارئ شرعي آخر على الوصول إلى الملفات الأصلية والملفات المُنشأة.

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

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

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

أعد إنشاء ملف واحد مرة أخرى وتحقق بعد إعادة التشغيل

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

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

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