كان الحل المؤكد في هذا الموضوع هو ضبط مسار الحفظ الافتراضي في qBittorrent على مسار حاوية Docker /downloads، وليس مسار المضيف في ZimaOS. كان المستخدم قد وصّل القرص الصلب الثانوي بشكل صحيح؛ لكن qBittorrent كان يُوجَّه ببساطة إلى مسار لا يفهمه سوى المضيف.
لم يؤدِّ تغيير PUID/PGID إلى root إلى حل الحالة الأصلية. وبعد تصحيح المسار، أكد صاحب الموضوع صراحةً أن التنزيلات تعمل.
كيف بدت عملية الربط الأصلية
يمكن تلخيص الربط المهم كما يلي:
المضيف: /media/GERAL/Downloads → الحاوية: /downloads
يرى ZimaOS الجانب الأيسر، بينما يعمل qBittorrent داخل Docker، ولذلك ينبغي له عادةً استخدام الجانب الأيمن.
كان المسار الخاطئ داخل qBittorrent
كانت واجهة qBittorrent على الويب مضبوطة على /media/GERAL/Downloads. ولم يكن مسار المضيف هذا ظاهرًا للتطبيق داخل الحاوية.
يوثّق دليل مجلد qBittorrent الحالي الحالة المصدر نفسها والحل الذي تم التحقق منه.
لماذا لم يساعد PUID وPGID مع root
الأذونات وإمكانية رؤية المسار مشكلتان مختلفتان. لا يمكن لتشغيل التطبيق بصفة root أن يجعل مسار مضيف غير موصول يظهر سحريًا داخل الحاوية. تحقّق أولًا من مسار الحاوية؛ ولا تبحث في الملكية إلا إذا أعاد المسار الموصول الصحيح الخطأ Permission denied.
يتناول دليل أذونات qBittorrent المجاور نمط الفشل الثاني.
تستخدم صور Docker الحالية النمط نفسه
توثّق صورة qBittorrent الحالية من LinuxServer وحدة تخزين للتنزيلات موصولة إلى /downloads. راجع توثيق qBittorrent من LinuxServer قبل تغيير تعريف تطبيق مخصص.
الخلاصة
إذا كان ZimaOS يربط القرص المستهدف بالفعل داخل qBittorrent على المسار /downloads، فاستخدم /downloads أو مجلدًا فرعيًا تحته داخل qBittorrent. لا تلصق مسار المضيف في ZimaOS داخل التطبيق، إلا إذا كان ذلك المسار نفسه موصولًا أيضًا بالحاوية.
