حلّ المجتمع

لا يستطيع Plex حذف الوسائط على ZimaOS: أذونات تحميل SMB، وهوية الحاوية، ووصول أكثر أمانًا للكتابة

A November 2025 thread where Plex could read media from a mounted share but failed to delete files. The community correctly focused on permissions, while the original poster eventually remounted CIFS with file_mode/dir_mode 0777 and noperm. The source did not establish that broad world-write permissions were the best permanent fix.

قدرة Plex على تشغيل ملف مع فشلها في حذفه تُعدّ مؤشرًا قويًا على وجود مشكلة في الأذونات. فصلاحية القراءة تختلف عن صلاحية الحذف/الكتابة. في الحالة الأصلية، كانت الوسائط موجودة على مشاركة ملفات مركّبة، وتمكّن Plex من قراءتها، لكن عملية الحذف أعادت الرسالة: «حدثت مشكلة أثناء حذف الملف».

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

‏«الجذر» داخل الحاوية ليس القصة الكاملة للأذونات

منح المستخدم صلاحية الجذر على المضيف لأن حاوية Plex بدت وكأنها تعمل بصفة الجذر. لكن حاوية Docker لا تزال تصل إلى نظام ملفات SMB/CIFS المرتبط عبر ربط مسار المضيف، وذلك وفق الملكية والوضع وقوائم التحكم بالوصول وخيارات التركيب الخاصة بالتركيب على المضيف.

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

يتطلب حذف ملف صلاحية الكتابة على الدليل الأب

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

طابق هوية الحاوية الفعلية مع إعدادات التركيب

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

افحص إعدادات الحاوية الحالية والملكية الفعلية التي يعرضها تركيب CIFS قبل تغيير PLEX_UID/PUID/PGID.

استخدم المصدر 0777 وnoperm كحل واسع النطاق

قام المنشور الأصلي بتركيب CIFS باستخدام خيارات تعادل:

file_mode=0777,dir_mode=0777,noperm

قد يجعل ذلك المشاركة قابلة للكتابة من قِبل أي هوية محلية تقريبًا، كما يعطّل عمليات التحقق المعتادة من الأذونات على جانب العميل. وهذا دليل مفيد على أن سياسة التركيب كانت تمنع Plex، لكنه لا ينبغي أن يكون الحل الدائم الأول.

فضّل هوية أو مجموعة مخصّصة للوسائط

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

إذا كان ينبغي لـ Plex قراءة معظم المكتبات فقط، ففكّر في جعل مجلدات مُدارة محددة فقط قابلة للكتابة.

تحقّق أيضًا من ربط وحدات تخزين Plex

ينبغي أن يستخدم Plex مسار الوسائط داخل الحاوية، بينما يربط ZimaOS ذلك المسار بتركيب المضيف. توضّح وثائق IceWhale الحالية هذه العلاقة بين المضيف والحاوية.

استخدم نموذج مسارات Docker الحالي في ZimaOS قبل تعديل الملكية.

يجب أن يسمح Plex أيضًا بحذف الوسائط

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

اختبر باستخدام ملف واحد يمكن الاستغناء عنه

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

الأسئلة الشائعة حول حذف Plex

هل تثبت قدرة Plex على قراءة ملف أنه يستطيع حذفه؟

لا. يتطلب الحذف صلاحية الكتابة على الدليل الذي يحتوي الملف.

هل نجح chmod/وضع التركيب 0777 في المصدر؟

أفاد المستخدم بنجاح العملية بعد إعادة تركيب CIFS بصلاحيات متساهلة جدًا، لكنه ليس التصميم المفضّل وفق مبدأ أقل صلاحية.

هل تكفي صلاحية الجذر على المضيف وحدها لإصلاح مشكلة حذف Plex من SMB؟

لا. تظل ملكية/وضع تركيب CIFS الفعلي وهوية الحاوية هما ما يحددان سلوك الكتابة.