إذا مُنح عضو جديد في ZimaOS صلاحية القراءة والكتابة من خلال واجهة المشاركة، لكنه لا يزال يتلقى رسالة «تم رفض الإذن»، فلا تشغّل فورًا أوامر تغيير الملكية بشكل تكراري عبر مجموعة التخزين. فقد اختبر موضوع المصدر في مارس 2026 عدة فرضيات تتعلق بالملكية، وأجرى إعادة ضبط كاملة، لكنه لم يتوصل إلى سبب جذري مؤكد.
تتمثل الطريقة المستدامة لاستكشاف الأخطاء وإصلاحها في فصل طبقة أذونات ZimaOS وSamba عن طبقة ملكية Linux الأساسية. أعد إنتاج المشكلة أولًا على مجلد جديد صغير، وقارن بين وصول المسؤول والعضو، ثم افحص مسار المضيف المحدد المتعلق بالمشكلة فقط.
بدت أذونات العضو صحيحة في الواجهة
تمكن حساب المسؤول من الوصول إلى البيانات، بينما مُنح حساب أُنشئ حديثًا باسم Andres صلاحية القراءة والكتابة، لكنه تلقى خطأ في الإذن عند فتح الملفات.
يدعم ZimaOS الحالي أذونات Samba لكل مستخدم
تميز وثائق ZimaOS الحالية بين وصول الأعضاء ووصول الضيوف، وتتيح للمدير منح المشاركة صلاحية القراءة أو القراءة والكتابة. وينبغي أن يتمكن العضو الذي لديه صلاحية القراءة والكتابة من تنزيل الملفات ورفعها وإعادة تسميتها وحذفها داخل المشاركة، شريطة إمكانية الوصول إلى نظام الملفات الأساسي.
إعداد Samba الحالي متعدد المستخدمين في ZimaOS هو نقطة الانطلاق الصحيحة قبل استخدام إصلاحات على مستوى الصدفة منسوخة من موضوع قديم.
إعادة إنتاج المشكلة على مجلد اختبار جديد تمامًا
أنشئ مجلد اختبار صغيرًا من خلال واجهة «الملفات» الحالية على قرص البيانات المقصود. شارك هذا المجلد فقط مع العضو الجديد بصلاحية القراءة والكتابة، ثم اتصل من جهاز العميل الخاص بالعضو باستخدام بيانات اعتماد ذلك العضو.
إذا عمل مجلد الاختبار، لكن فشلت المجلدات المُرحّلة أو الأقدم، فمن المرجح أن المشكلة مرتبطة بهذه المسارات أو بملكية الملفات فيها. وإذا فشل أيضًا المجلد الجديد تمامًا الذي أُنشئ عبر الواجهة، فالمشكلة أوسع نطاقًا، وينبغي التعامل معها باعتبارها مشكلة محتملة في الحساب أو Samba أو أذونات ZimaOS، لا في ملكية الملفات القديمة.
استخدم ملكية Linux كإشارة تشخيصية، لا كحل أعمى
فحص النقاش معرّفات المستخدمين وملكية الأدلة، ووجد مسارات ضمن /DATA/.media مملوكة لمستخدمين ومجموعات مختلفة في Linux. جعل ذلك احتمال عدم تطابق الملكية معقولًا بالنسبة إلى البيانات المُرحّلة.
اقتُرح تنفيذ أمر chown أنتجت العملية بعد ذلك العديد من أخطاء «العملية غير مسموح بها» داخل البيانات التي تديرها التطبيقات. وهذا تحذير من تطبيق أمر ملكية واحد على أشجار النظام أو AppData الواسعة. قد يؤدي تغيير الملكية بشكل递归 إلى تعطيل الحاويات أو الخدمات التي تتوقع معرّفات مستخدمين ومجموعات محددة.
استخدم id, ls -ld، وملف اختبار صغير لفهم المسار الذي يفشل بالضبط. لا تعدّل أدلة التطبيقات غير المرتبطة.
لم تكن إعادة ضبط المصنع حلًا مؤكدًا
بعد إعادة التهيئة وإعادة التثبيت، ظل الكاتب يبلغ عن أخطاء في أذونات الأعضاء. هذه النتيجة مهمة: لا توصِ بإعادة ضبط مدمّرة كحل اعتيادي لمشكلة وصول المستخدم.
ما ينبغي جمعه قبل الإبلاغ عن المشكلة
إذا ظل مجلد جديد أُنشئ عبر ZimaOS الحالي يفشل مع عضو جديد الإنشاء، فسجّل إصدار ZimaOS، ومسار المشاركة، وإعداد إذن العضو، ونظام تشغيل العميل، والخطأ الدقيق، وما إذا كان وصول المسؤول يعمل. وسجّل أيضًا ناتج id للحساب المعني و ls -ld للمسار المتأثر فقط.
هذا الدليل أكثر فائدة من تغيير آخر واسع النطاق للملكية. انتهى النقاش الأصلي إلى أن المجتمع اعتبر إعادة الإنتاج عبر تثبيت نظيف أمرًا غير متوقع ويستحق تحقيقًا أعمق، وليس إلى حل مؤكد من سطر واحد.
