لماذا يعيد Jellyfin إنشاء الملفات المفقودة بمالكٍ غير صحيح؟
عادةً ما يعيد Jellyfin إنشاء الملفات بمالك غير صحيح عندما تختلف هوية الخدمة النشطة عن مالك الدليل، أو عندما يستخدم مسار استيراد ثانٍ معرّف UID/GID مختلفًا.
هل تؤثر المشكلة في الأعمال الفنية التي نُزّلت حديثًا فقط أم في كل ملف يكتبه Jellyfin؟ قارن بين ملف يعمل بشكل صحيح، وملف أُنشئ حديثًا، وهوية الحاوية النشطة، والوجهة المرتبطة قبل تشغيل أي أمر تكراري لتغيير الأذونات. الهدف هو إصلاح التوارث، لا تكرار معالجة الأعراض.
أثبت أي هوية ومسار نفّذا عملية الكتابة
افحص المستخدم والمجموعات في الحاوية قيد التشغيل، ثم افحص نقطة الربط الفعلية بدلًا من الاعتماد على ملف Compose الموجود على القرص. تأكد من أن مساري إعدادات Jellyfin وذاكرة التخزين المؤقت قابلان للكتابة، مع إبقاء الوسائط للقراءة فقط عندما لا تكون صلاحية الكتابة مطلوبة. يساعد فحص الأذونات متعدد الطبقات على التمييز بين ظهور الملفات على المضيف، والربط داخل الحاوية، وهوية الخدمة.
إذا كان المضيف يرى الملف لكن الحاوية لا تستطيع ذلك، فأصلح نقطة الربط. وإذا كانت الحاوية تستطيع الكتابة لكن المالك غير صحيح، فتابع إلى اختبار الهوية والتوارث.
إذا كانت الملفات المستوردة فقط تملكًا غير صحيح، فقارن بين UID/GID وقناع umask الخاص بالمستورد وتلك الخاصة بـ Jellyfin. وإذا كان كل ملف جديد غير صحيح، فتحقق من قائمة التحكم بالوصول الافتراضية وسلوك setgid للدليل الأب.
تحقق من umask والمجموعات وقوائم التحكم بالوصول وعامل الاستيراد
قارن بين UID/GID ووضع أذونات الدليل الأب وبين العملية التي تنشئ الملف. قد يكتب برنامج تنزيل أو مهمة مجدولة أو حاوية جانبية عبر حاوية مختلفة، حتى إذا كان Jellyfin يعرض العنصر لاحقًا. تحقق من المجموعات الإضافية وقوائم التحكم بالوصول الافتراضية قبل تغيير شجرة الأدلة بأكملها.
لا تستخدم تغييرًا تكراريًا للأذونات يجعل الملفات قابلة للكتابة عالميًا باعتباره حلًا دائمًا. طابق هوية الخدمة مع المجموعة المقصودة، أو اجعل المجموعة المشتركة وقائمة التحكم بالوصول الافتراضية محددتين بوضوح للدلائل المطلوبة للتعاون فقط.
اختبر ملفًا جديدًا واحدًا عبر مسار الاستيراد الفعلي بعد تغيير الهوية. لا تقيّم الإصلاح بناءً على ملفات أُنشئت قبل إعادة إنشاء الحاوية أو الحاوية الجانبية.
أصلح التوارث وتحقق بعد إعادة الإنشاء
طبّق أصغر تغيير ممكن في الملكية أو قائمة التحكم بالوصول على الدليل المتأثر، وأنشئ ملف اختبار واحدًا من جديد، ثم تحقق من مالكه ووضع أذوناته. أعد إنشاء الحاوية وأعد تشغيل المضيف، ثم كرر عملية الاستيراد نفسها للتأكد من استمرار الإصلاح بعد النشر وترتيب نقاط الربط.
صعّد المشكلة عندما تعود تغييرات الملكية بعد إعادة إنشاء نظيفة، أو عندما يتجاهل نظام الملفات ملكية POSIX، أو عندما تتنافس خدمات متعددة على إدارة المسار نفسه. احتفظ بالملف العامل وبإعدادات Compose أثناء تضييق نطاق الجهة التي تكتب.
إذا تغيرت الملكية بعد إعادة التشغيل، فإن نقطة الربط أو النشر يطبّق هوية مختلفة. احتفظ بإعدادات Compose العاملة قبل تغيير شجرة نظام الملفات مجددًا.
تحقق من الملكية بعد إعادة التشغيل وإعادة الاستيراد
أعد إنشاء الحاوية، وأعد تشغيل المضيف، واستورد ملف اختبار مضبوطًا واحدًا. أكّد المالك والمجموعة ووضع الأذونات وظهور الملف في Jellyfin من المضيف والحاوية معًا.
أبقِ الإصلاح عندما ترث الملفات الجديدة المجموعة المقصودة ويتمكن Jellyfin من القراءة أو الكتابة في الدلائل المطلوبة لسير العمل فقط. لا تمنح صلاحية كتابة واسعة لشجرة الوسائط بأكملها.
صعّد المشكلة عندما يواصل نظام الملفات أو طبقة قوائم التحكم بالوصول أو الكتّاب المتعددون تغيير الملكية بعد إعادة الاستيراد المضبوطة.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
كيفية تحسين اتصالات قاعدة بيانات Jellyfin للحاويات المتزامنة
ابدأ بمالك واحد لقاعدة البيانات، وقِس سلوك القفل في SQLite؛ ولا تُضف واجهة خلفية مختلفة إلا عندما يبرّر التزامن والاسترداد هذا التعقيد.
كيفية منع تكرار المهام أو عمليات الاستيراد في Jellyfin
ينشأ العمل المكرر عادةً بسبب تداخل أدوات الجدولة أو وجود أكثر من جهة كتابة؛ عيّن مسؤولًا واحدًا، ومسارًا واحدًا، وفحصًا واحدًا لاكتمال العمل.
كيفية إصلاح Jellyfin بعد امتلاء وحدة تخزين قاعدة البيانات الخاصة به
أوقف عمليات الكتابة، وحافظ على قاعدة البيانات وملفات WAL، وحرّر مساحةً دون حذف الحالة عشوائيًا، ثم تحقّق من السلامة والتكامل ومن عبء العمل الأصلي.
