حلّ المجتمع

عضو ZimaOS يستطيع فتح مجلد مشترك على الكمبيوتر، لكنه يتلقى رسالة «تم رفض الإذن» على أندرويد: اعزل طبقة العميل

A May 2026 ZimaOS 1.6.1 thread where a newly created member had Read & Write access to a share and could open it from a computer, but two Android phones returned Permission Denied in ZimaClient even after reinstall. The thread ended without an IceWhale-confirmed fix, so the strongest evidence isolates the problem to the mobile/session/authentication path rather than the basic share ACL.

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

لا يثبت ذلك وجود خطأ محدد في ZimaClient، إذ لم يشخّص أي موظف من IceWhale الموضوع في ذلك النقاش. لكنه يعني أن تفسير «لقد نسيت منح العضو صلاحية الوصول» غير مكتمل. يدعم ZimaOS الحالي رسميًا صلاحيات المجلدات لكل مستخدم، لذا ينبغي أن تقارن عملية إعادة الاختبار الحالية بين استخدام بيانات الاعتماد نفسها عبر ZimaClient وSMB المباشر قبل تغيير قوائم التحكم بالوصول (ACL) على الخادم.

إعدادات مشاركة Samba في ZimaOS التي تمنح العضو esinaga صلاحية القراءة والكتابة
أظهرت المشاركة نفسها أن العضو الجديد لديه صلاحية القراءة والكتابة.
إعدادات أعضاء ZimaOS التي تُظهر تفعيل مجلد esinaga بصلاحية القراءة والكتابة
أظهرت قائمة المجلدات على مستوى الحساب أيضًا تفعيل المشاركة نفسها للعضو.

أكّد أولًا قائمة التحكم بالوصول إلى المشاركة من جانب الخادم

تتوقع إرشادات IceWhale الحالية الخاصة بـSamba متعدد المستخدمين أن يعيّن المدير عضوًا إلى المجلد المشترك ويختار القراءة أو القراءة والكتابة.

استخدم سير عمل مشاركة الأعضاء الحالي في ZimaOS.

يوضح اختبار الكمبيوتر أن بيانات اعتماد العضو يمكن أن تعمل

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

يقلل فشل هاتفين يعملان بنظام Android من احتمال وجود تثبيت تالف واحد للتطبيق

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

اختبر SMB مباشرًا من Android

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

أما إذا فشل كلا الاختبارين، فراجع بيانات اعتماد SMB بدقة، وتنسيق اسم المستخدم، والأحرف الخاصة، وحالة الحساب على الخادم.

أنه جلسة ZimaClient الحالية بالكامل

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

أعد الاختبار على إصداري ZimaOS وZimaClient الحاليين

كان المصدر يستخدم ZimaOS 1.6.1. وقد تغيّر كل من ZimaOS الحالي وعملاء الأجهزة المحمولة. وتؤكد وثائق ZimaOS الحالية أن الصلاحيات مرتبطة بحسابات ZimaOS وأن ZimaClient يوفر الوصول المحلي وعن بُعد.

كان انقطاع اتصال الهاتف لاحقًا عرضًا منفصلًا

ذكر صاحب المنشور لاحقًا أن النسخ الاحتياطي من الهاتف كان يعمل، لكن اتصال الهاتف كان ينقطع كثيرًا. ولم يثبت النقاش ما إذا كان ذلك هو مشكلة الصلاحيات نفسها، أو مشكلة في الشبكة أو الاتصال بين النظيرين (P2P)، أو تراجعًا آخر في العميل.

تعامل مع «تم رفض الإذن» و«فقد الاتصال» كحالتَي اختبار منفصلتين، ما لم تُظهر السجلات سببًا مشتركًا.

الأسئلة الشائعة حول وصول الأعضاء من Android

هل كانت صلاحيات العضو مهيّأة بوضوح في المصدر؟

نعم. أظهرت لقطات الشاشة العضو والمجلد مع صلاحية القراءة والكتابة.

هل عمل المجلد من جهاز كمبيوتر؟

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

هل أكد النقاش وجود إصلاح من IceWhale؟

لا. انتهى النقاش والمشكلة على Android لا تزال دون حل.