كيفية اختبار صلاحية الكتابة في Jellyfin دون تغيير بيانات الإنتاج

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

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

تأكّد من المسار الذي يراه جِلي‌فين فعليًا

ابدأ من داخل جِلي‌فين أو حاويته، لا من صدفة أوامر المضيف. قد يُقدَّم دليل على المضيف مثل /mnt/media/movies قد يُقدَّم إلى جِلي‌فين على أنه /media/movies، لذا قد يثبت اختبار الأذونات على مسار المضيف وحده شيئًا غير صحيح.

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

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

تحقّق من هوية وقت التشغيل قبل اختبار الأذونات

اعثر على معرّف المستخدم (UID) ومعرّف المجموعة (GID) اللذين تستخدمهما عملية جِلي‌فين. في تثبيت لينكس أصلي، يكون هذا عادةً جِلي‌فين حساب خدمة؛ داخل حاوية، قد يكون معرّف مستخدم/مجموعة رقميًا يوفّره وقت التشغيل. قارن تلك الهوية بالمالك والمجموعة وبتات الوضع وقوائم التحكم بالوصول (ACLs) على الدليل الهدف.

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

استخدم أوامر فحص للقراءة فقط مثل id, stat, namei -lأو getfacl عند توفره. إذا كان أحد الأدلة الأصلية يفتقر إلى إذن التنفيذ لهوية Jellyfin، فقد يكون للمجلد النهائي أذونات واسعة، ومع ذلك يظل الوصول إليه متعذرًا.

استخدم دليل فحص مؤقتًا على وحدة التخزين نفسها

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

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

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

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

افصل بين أذونات المضيف وعمليات التركيب للقراءة فقط داخل الحاوية

عندما يشير المضيف إلى أن الدليل قابل للكتابة، بينما يُبلغ الفحص داخل الحاوية عن نظام ملفات للقراءة فقط، فلا تُرخِ أذونات المضيف. إن عملية تركيب الربط المُعرَّفة باستخدام ro يمنع الكتابة بصرف النظر عن chmod أو chown على المضيف.

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

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

تحقّق من الإجراء على مستوى التطبيق دون لمس الوسائط

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

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

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

توقّف قبل تطبيق تغييرات أذونات تكرارية واسعة النطاق

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

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

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