يثبت المصدر بوضوح أمرًا واحدًا: تمكّن qBittorrent من الوصول إلى مجلد Btrfs الخارجي المربوط، لكن العملية لم تتمكن من إنشاء مجلدها الفرعي incomplete. كان الخطأ هو رفض الإذن، وليس «المسار غير موجود». لذلك، فإن هوية نظام الملفات والأذونات هما طبقة استكشاف الأخطاء الأقوى.
لا يثبت النقاش الحل الدائم. فقد ذكر الرد الوحيد أن UID 1000 غير موجود على نظام ZimaOS ذلك، واقترح اختبار الحاوية بصلاحيات الجذر. ولم يعد صاحب المنشور الأصلي بنتيجة ناجحة. لذلك، ينبغي اعتبار تشغيل qBittorrent بصلاحيات الجذر اختبارًا تشخيصيًا محدودًا فقط، وليس إعدادًا نهائيًا موصى به.
كان ربط وحدة التخزين محددًا بوضوح
قام المصدر بربط:
/media/SSD-1TBStorage/Downloads → /downloadsداخل qBittorrent، حاول التطبيق إنشاء:
/downloads/incomplete/...وبما أن الخطأ كان «رفض الإذن»، فمن المرجح أن الربط كان موجودًا وأن الحاوية وصلت إلى نظام ملفات المضيف.
كان لمجلد المضيف إذن الكتابة للمجموعة
عرض المستخدم ما يلي:
drwxrwxr-x 1 1000 samba /media/SSD-1TBStorage/Downloadsوذكر أن الحاوية تعمل باستخدام UID/GID 1000. كما جرّب chown -R 1000:1000 وchmod -R 775.
ويعني ظهور الخطأ أن أحد هذه الافتراضات—الهوية الفعلية أثناء التشغيل، أو الوصول إلى المجلدات الأصلية، أو سلوك الربط، أو الأذونات الفعالة—كان غير مكتمل.
لا تفرض قيمة UID لنظام ZimaOS اعتمادًا على رد في منتدى
ذكر المجيب من المجتمع أن أول مستخدم في ZimaOS يستخدم UID 999 بدلًا من 1000. وحتى إن كان ذلك صحيحًا في إصدار معيّن، فقد تختلف معرّفات المستخدمين باختلاف المنصة والإصدار، كما قد تستخدم حاوية qBittorrent هوية منفصلة عبر PUID/PGID.
افحص إعدادات الحاوية الحالية الفعلية وهوية العملية بدلًا من التخمين.
يمكن لتشغيل الحاوية بصلاحيات الجذر تأكيد وجود مشكلة في طبقة الأذونات، لكنه لا ينبغي أن يكون دائمًا
إذا عملت الحاوية فقط عند تشغيلها باستخدام UID 0، فهذا يشير بقوة إلى أن المسار المربوط يمنع هوية التطبيق العادية. لكنه لا يعني أن qBittorrent ينبغي أن يستمر في العمل بصلاحيات الجذر.
ينبغي ألا يمتلك برنامج تنزيل معرّض لإدخالات الويب والشبكة سوى امتيازات نظام الملفات التي يحتاج إليها.
تحقق من كل مجلد أصلي في مسار المضيف
لا يكفي امتلاك إذن الكتابة على مجلد Downloads النهائي إذا تعذّر على هوية الحاوية اجتياز أحد المجلدات الأصلية. افحص المسار الكامل وأي قوائم للتحكم في الوصول، وليس بتات وضع المجلد الأخير فقط.
كان Btrfs مستخدمًا، لكن المصدر لم يثبت أن Btrfs تسبب في الفشل
كان محرك SSD يستخدم Btrfs، لكن الملكية والأذونات التقليدية في Unix تظل سارية. لا يثبت شيء في النقاش وجود خلل خاص بـ Btrfs، أو سياسة وحدة فرعية، أو ربط للقراءة فقط تسبب في الخطأ.
تحقق من حالة نظام الملفات المربوط قبل إلقاء اللوم على نوع نظام الملفات.
يعرض ZimaOS الحالي روابط مجلدات التطبيقات صراحةً
توضح وثائق IceWhale الحالية مسارات المضيف والحاوية، وتتيح للمستخدمين تعديل روابط تخزين التطبيقات من إعدادات التطبيق.
استخدم نموذج مسارات Docker الحالي في ZimaOS قبل تغيير الملكية.
استخدم مجلد تنزيل مخصصًا لـ qBittorrent
امنح qBittorrent صلاحية الكتابة إلى مجلد تنزيل/تجهيز مخصص لهذا الغرض بدلًا من وحدة وسائط أو نسخ احتياطي كاملة. وبذلك يمكن لـ Sonarr/Radarr استيراد الملفات المكتملة أو نقلها باستخدام أذوناتهما الخاصة الخاضعة للتحكم.
سير عمل أكثر أمانًا لإعداد الأذونات الدائم
- أكد الربط الدقيق بين مسار المضيف ومسار الحاوية.
- افحص UID/GID/PUID/PGID الفعلي لحاوية qBittorrent.
- افحص أذونات مجلد المضيف والمجلدات الأصلية.
- أنشئ مجلد اختبار صغيرًا ومخصصًا.
- امنح مستخدمًا أو مجموعةً محددة صلاحية الكتابة المطلوبة فقط.
- أعد تشغيل التطبيق واختبر تنزيلًا قانونيًا صغيرًا واحدًا.
الأسئلة الشائعة حول أذونات qBittorrent وBtrfs
هل تأكد حل المصدر النهائي؟
لا. ينتهي النقاش بعد رد واحد من المجتمع.
هل يثبت «رفض الإذن» غياب ربط وحدة تخزين Docker؟
لا. يعني ذلك عادةً أن المسار يمكن الوصول إليه، لكن العملية لا تستطيع تنفيذ عملية الكتابة المطلوبة.
هل ينبغي أن يعمل qBittorrent بصلاحيات الجذر بشكل دائم؟
لا. يمكن أن تكون صلاحيات الجذر اختبارًا تشخيصيًا، لكن ينبغي أن يستخدم الحل الدائم أقل قدر مطلوب من امتيازات نظام الملفات.
