حلّ المجتمع

إصلاح خطأ رفض الإذن في OSCam لقارئ FTDI على ZimaOS

OSCam could see an FTDI reader mapped as /dev/ttyUSB0 but returned errno 13 until the container user matched the device permissions.

كان القارئ متصلًا، لكن مستخدم الحاوية لم يتمكن من فتحه

أنشأ مضيف ZimaOS قارئ FTDI باسم /dev/ttyUSB0، وتم تمرير الجهاز إلى حاوية OSCam من LinuxServer. ومع ذلك، سجّل OSCam الخطأ errno=13 Permission denied.

أظهر المضيف جهاز الأحرف بالملكية root:dialout وبصلاحيات 660. وكانت الحاوية مُهيّأة باستخدام PUID=1000 وPGID=1000، لذلك لم يتطابق مستخدم التطبيق فيها مع المالك أو مجموعة dialout المسموح لها بفتح الجهاز.

حل تغيير هوية الحاوية لمشكلة الوصول إلى FTDI

كان الاختبار الأول المقترح هو تشغيل حاوية OSCam بصلاحيات المستخدم الجذر، عبر ضبط:

PUID=0
PGID=0

وظل الربط الحالي كما هو:

devices:
  - /dev/ttyUSB0:/dev/ttyUSB0

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

تعيين المجموعة هو البديل الأضيق نطاقًا

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

قبل تغيير الصلاحيات، تأكد من أن lsusb يرى جهاز FTDI وأن /dev/ttyUSB0 موجود. إذا كانت عقدة الجهاز غير موجودة، فالمشكلة تتعلق باكتشاف برنامج التشغيل أو سلوك إعادة الاتصال، لا بملكية الحاوية.

كانت مهلة CCcam اللاحقة مشكلة مختلفة

بعد نجاح الوصول إلى USB، واجه صاحب التجربة مهلةً عند الاتصال بـ CCcam. وحققت الردود في استخدام شبكة الجسر مقابل شبكة المضيف، والتوجيه، والشبكات الفرعية، وقواعد الجدار الناري، وما إذا كانت الخدمة البعيدة تستمع على العنوان المتوقع. وفي مرحلة ما، لم يتمكن العميل من اختبار اتصال الخادم أو الوصول إلى منفذ TCP الخاص به.

أفاد صاحب التجربة لاحقًا بأن تحديث صورة حاوية OSCam من LinuxServer حل السلوك المتبقي. ولم تُسجّل وسوم الصور التي كانت معطوبة وتلك التي أصلحت المشكلة بدقة، لذلك لا يمكن للنقاش تحديد حد فاصل دقيق للإصدار.

الأسئلة الشائعة

لماذا لم يؤدِّ الوضع ذو الصلاحيات المميزة إلى إصلاح ttyUSB0 تلقائيًا؟

ركز التشخيص الناجح على هوية العملية داخل الحاوية. فقد كانت لا تزال تعمل بمعرّف المستخدم ومعرّف المجموعة 1000، بينما كان الجهاز يسمح بالوصول للمستخدم الجذر ولمجموعة dialout.

ما التغيير الذي أكده صاحب التجربة لقارئ FTDI؟

غيّر PUID وPGID إلى 0، وأكد نجاح الطريقة الأولى المقترحة.

هل كانت مهلة الشبكة اللاحقة ناتجة عن صلاحيات USB؟

لا. فقد كانت مشكلة FTDI قد حُلّت بالفعل. وكانت المشكلة اللاحقة تتعلق بإمكانية الوصول عبر الشبكة أو بصورة الحاوية، وأُفيد بأنها عملت بعد إجراء تحديث.