كان خطأ الصلاحيات في الواقع خلطًا بين المسارات
احتاج أحد مستخدمي ZimaOS إلى تعديل ملف config.php الخاص بـ Nextcloud لإضافة عنوان tailnet إلى النطاقات الموثوقة. لم تُجدِ أوامر مثل chown وusermod نفعًا، لأن السؤال الأول لم يكن مَن يملك الملف، بل أي مساحة أسماء لنظام الملفات يستخدمها الأمر.
توصّل النقاش إلى إجابة ناجحة بعد أن فحص المستخدم نقاط تحميل حاوية Nextcloud. ظهر الملف نفسه في مسار على مضيف ZimaOS ومسار آخر داخل الحاوية. ولا يمكن أن يعمل إدخال مسار الحاوية من المضيف لمجرد أنه يبدو صحيحًا في دليل خاص بـ Nextcloud.
افحص نقطة تحميل الحاوية قبل تغيير الصلاحيات
حدّد أولًا حاوية Nextcloud قيد التشغيل:
docker ps --format "table {{.Names}}\t{{.Image}}"ثم افحص نقاط تحميلها، مع استبدال العنصر النائب باسم الحاوية الفعلي:
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'في هذه الحالة، أظهر الناتج ما يلي:
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlيمثّل الجانب الأيسر مسار المضيف، بينما يمثّل الجانب الأيمن المسار كما يظهر من داخل الحاوية. يفسّر هذا الربط سبب عدم حل المشكلة عند تغيير دليل غير ذي صلة أو إدخال مسار الحاوية من المضيف.
استخدم مسار المضيف عند التعديل من ZimaOS
من موجّه أوامر مضيف ZimaOS، عثر المستخدم على الملف في:
/DATA/AppData/nextcloud/var/www/html/config/config.phpلذلك يكون أمر التعديل المطابق على المضيف هو:
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpقبل التعديل، أوصى النقاش بالتحقق من الملف والدليل الأب معًا:
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configكان وضع الملف الملحوظ 640 ومالكه www-data:www-data. هذه المعلومات مهمة، لكن العائق النهائي ظل متعلقًا بسياق المسار. وقد نصّ الرد صراحةً على عدم تطبيق تغييرات عشوائية على الملكية قبل تحديد مصدر نقطة الربط الفعلية.
استخدم مسار الحاوية فقط بعد الدخول إليها
البديل هو الدخول إلى الحاوية قيد التشغيل ثم تعديل الملف من داخلها:
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpداخل الحاوية، يُعد /var/www/html/config/config.php مسارًا صحيحًا. أما من المضيف، فيشير المسار نفسه إلى نظام الملفات الجذر الخاص بالمضيف، وليس إلى دليل Nextcloud المرتبط.
كان تحذير إعدادات Docker مشكلة منفصلة
طبع كل من docker inspect وdocker exec تحذيرًا يفيد بتعذّر فتح /DATA/.docker/config.json. حدّد الرد أن هذا تحذير متعلق بإعدادات واجهة سطر أوامر Docker، وليس سبب مشكلة الوصول إلى ملف Nextcloud. وتمكّن المستخدم من المتابعة بعد فهم الفرق الصحيح بين مسار المضيف ومسار الحاوية.
الأسئلة الشائعة
لماذا لم يؤدِّ تغيير الملكية إلى إصلاح ملف إعدادات Nextcloud؟
طُبّقت الأوامر قبل التحقق من مصدر نقطة الربط الفعلية. فتغيير الصلاحيات على دليل مضيف خاطئ لا يؤثر في الملف الموجود داخل مسار بيانات Nextcloud المرتبط.
هل ينبغي تعديل config.php من المضيف أم من داخل الحاوية؟
يمكن استخدام أي من الطريقتين. استخدم مسار المصدر الكامل /DATA/AppData/... من المضيف، أو ادخل إلى الحاوية أولًا ثم استخدم /var/www/html/.... لا تخلط بين سياقي المسارات.
