فشل تحديث ووردبريس بسبب صلاحيات الملفات: تجربة نسخ فعلية

تحديث إضافة ووردبريس وقف عند Could not copy file او Permission denied؟ الرسالة مش دايما معناها ان رقم الصلاحية لازم يصير 777. المهم مين يملك الملفات، وتحت اي مستخدم PHP شغال، وهل هذا المستخدم قادر يكتب ويستبدل داخل المسار.

عملنا إضافة اختبار فيها ملف بإصدار 1.0.0 وحزمة تحديث محلية بإصدار 1.1.0. استخدمنا WP_Filesystem_Direct نفسه لنسخ الملف. اولا نجح النسخ. رجعنا النسخة القديمة، طبقنا قاعدة ACL تمنع الكتابة على مجلد الإضافة المحدد فقط، ففشل النسخ وبقي 1.0.0. رفعنا القاعدة واعدنا نفس العملية، فوصل 1.1.0 وتطابقت بصمة SHA-256.

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

النتيجة باختصار

• قبل المنع: copy رجعت true والملف صار 1.1.0.
• اثناء ACL: الملف والمجلد ظهرا غير قابلين للكتابة.
• copy رجعت false وسجلنا chmod(): Permission denied.
• الإصدار بقي 1.0.0 وما تطابق مع مصدر التحديث.
• بعد رفع المنع: نفس النسخ نجح ووصل 1.1.0 وبصمة المصدر تطابقت.

الحالة السليمة

هاي الخطوة مهمة عشان ما ننسب فشل موجود من البداية للصلاحيات. نفس المصدر والوجهة اشتغلوا قبل المنع، يعني الحزمة نفسها سليمة والمسار صحيح.

تطبيق منع الكتابة

اعدنا ملف 1.0.0، ثم طبقنا ACL على مجلد إضافة المختبر فقط. ما لمسنا مجلد plugins كله ولا ملفات الموقع. عند محاولة النسخ، رجعت الدالة false وبقي الملف القديم.

بعد استعادة الصلاحية

حذفنا قاعدة المنع واعدنا المحاولة من نفس المصدر. ما غيرنا الحزمة ولا اسم الملف. رجعت الدالة true وصار المحتوى 1.1.0 وتطابقت SHA-256.

فيديو توثيق التجربة الفعلية

هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.

ليش 755 و644 مش جواب كامل؟

على لينكس، 755 للمجلد و644 للملف ارقام شائعة، لكنها ما بتفيد اذا المالك والمجموعة غلط بالنسبة لمستخدم PHP. وعلى استضافة فيها suPHP او PHP-FPM pools قد يكون المستخدم مختلفا. افحص المستخدم الفعلي والملكية وACL وSELinux، مش الرقم وحده.

تشخيص مرتب

1. انسخ رسالة التحديث كاملة واسم اول ملف فشل.
2. افحص المساحة الحرة وinodes قبل الصلاحيات.
3. حدد مستخدم PHP ومستخدم SFTP ومالك الملف.
4. جرب انشاء ملف صغير داخل مجلد upgrade ومجلد الإضافة ثم احذفه.
5. افحص صلاحية المجلد والملف وكل مجلد اب في المسار.
6. راجع ACL او SELinux او حماية الاستضافة اذا الارقام تبدو صحيحة.
7. اصلح الملكية او قاعدة المنع في اضيق مسار، ثم اعد تحديثا واحدا.
8. تحقق من الإصدار والبصمة او سلامة الملفات بعد النجاح.

افحص المساحة اولا

رسالة تعذر النسخ ممكن تطلع لما القرص او inodes ممتلئة. التحديث يحتاج مساحة للملف المضغوط وفك الحزمة والنسخة الجديدة. اذا المساحة صفر، تغيير chmod ما رح يعمل فرق.

مجلد upgrade

ووردبريس يفك الحزم عادة داخل wp-content/upgrade. لازم يقدر ينشئ ويكتب ويحذف هناك، وبعدها يستبدل ملفات الإضافة. ممكن مجلد upgrade يشتغل لكن وجهة الإضافة لا، او العكس. اختبر الاثنين.

لا تستخدم 777 كحل دائم

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

اذا توقف التحديث بالنص

• لا تعيد الضغط بسرعة.
• افحص هل الإضافة بقيت بمجلد ناقص.
• خذ نسخة من قاعدة البيانات والملفات الموجودة.
• ارفع نسخة كاملة موثوقة يدويا اذا لزم.
• احذف ملف .maintenance فقط بعد التأكد ان عملية التحديث انتهت.
• افحص الواجهة ولوحة التحكم وسجل PHP.

شو ترسل للاستضافة؟

ارسل المسار الذي فشل، الوقت، مستخدم PHP، المالك والمجموعة، نتيجة محاولة كتابة صغيرة، المساحة وinodes، ورسالة النظام. هيك يقدروا يحددوا ownership او ACL او SELinux بدل ما يعطوك جوابا عاما.

حدود تجربتنا

التجربة تمت على Windows ACL لان النسخة محلية، بينما الاستضافات غالبا تستخدم Linux. السلوك الذي وثقناه حقيقي: مستخدم PHP منع من استبدال الملف ثم نجح بعد رفع المنع. اوامر الاصلاح نفسها تختلف حسب نظام الخادم، فلا تنسخ امر ACL من المختبر لاستضافتك.

تنظيف المختبر

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

الخلاصة

نفس نسخة ووردبريس ونفس الملف نجحا قبل المنع، فشلا مع ACL وبقي الإصدار القديم، ثم نجحا بعد استعادة الصلاحية. العلاج مش 777؛ العلاج تحديد المستخدم والملكية والمسار الذي يحتاج كتابة واصلاحه باقل صلاحية لازمة.