تشخيص Unable to create directory في ووردبريس: فحص الكتابة داخل uploads

تحاول رفع صورة فيظهر «Unable to create directory»؟ تعني الرسالة أن ووردبريس لم يستطع إنشاء المجلد المطلوب، وقد يكون السبب صلاحياته أو المساحة المتاحة أو مسارا غير صحيح. سنبدأ بفحوص بسيطة من لوحة التحكم، ثم نحدد المعلومات التي ترسلها للاستضافة إذا احتجت مساعدتها.

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

القراءة ليست الكتابة

قد يعرض ووردبريس الصور الموجودة لأنه يستطيع قراءتها، لكنه يفشل عند رفع صورة أو إنشاء مجلد شهر جديد. لذلك نختبر ثلاث طبقات: هل المسار موجود؟ هل يراه PHP قابلا للكتابة؟ وهل يستطيع إنشاء ملف صغير ثم حذفه؟ الاختبار الثالث يحسم حالات تكون فيها نتيجة الصلاحية النظرية مختلفة عن التنفيذ بسبب المالك أو ACL أو قيود الاستضافة.

خطة التشخيص دون cPanel

1. من الأدوات ← صحة الموقع ← معلومات، دون مسار uploads وحالة نظام الملفات إن ظهرت.
2. افتح الوسائط وحاول رفع ملف صغير معروف النوع. سجل الرسالة والوقت، ولا تكرر عشرات المحاولات.
3. إذا لاحظت أن تحديث الإضافات يفشل أيضا، دون ذلك للدعم؛ لا تبدأ تحديثا جديدا لمجرد اختبار الصلاحيات.
4. أرسل للاستضافة المسار والوقت والعملية التي فشلت، واطلب فحص مالك المجلد وصلاحيات حساب PHP ومساحة القرص وInodes.
5. بعد الإصلاح ارفع صورة، أنشئ نسخة صغيرة، ثم احذف الملف التجريبي من الوسائط.

لماذا لا ننصح بـ777؟

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

تمييز الصلاحيات عن المساحة

امتلاء المساحة أو بلوغ الحد الأقصى لعدد الملفات والمجلدات، الذي تسميه الاستضافة Inodes، قد يسبب فشل الكتابة أيضا. كذلك قد تمنع قاعدة open_basedir مسارا خارج النطاق. اطلب من الدعم الأرقام لا عبارة «كل شيء جيد»: المساحة الحرة، عدد Inodes، مالك uploads، وحساب PHP. ثم أعد تجربة واحدة. هذا يوفر دليلا يصلح أيضا عند متابعة مقال أخذ نسخة كاملة دون cPanel.

تفاصيل التجربة ونتيجتها

تاريخ التجربة: 19 أغسطس 2026؛ ووردبريس: 7.0.4؛ PHP: 8.3.30؛ مكان التنفيذ وأدواته: wp-content/uploads داخل النسخة المحلية.

استخدمنا wp_is_writable ثم أنشأنا ملف Probe مؤقتا وحذفناه. نجحت الكتابة داخل uploads، بينما فشلت في مسار Z غير الموجود كما توقعنا.

تحقق إضافي، 19 أغسطس 2026: فحصنا wp_is_writable ثم أنشأنا ملفًا مؤقتًا وحذفناه، وقارنّاه بمسار غير موجود. عدم وجود المسار ليس إثباتا لرفض صلاحياته. هذا الفحص يثبت نجاح كتابة ملف في uploads وفشل مسار غير موجود، ولا يغير الملكية أو الصلاحيات ولا يبرر استخدام 777.

توضيح تحريري، 17 سبتمبر 2026: الاختبار التاريخي قارن uploads بمسار غير موجود، لا بمجلد موجود مُنعت الكتابة فيه. أزيلت البطاقات المصورة التي استخدمت وصف «المسار المحجوب» حتى لا توحي بأن رفض الصلاحيات قد أُعيد إنتاجه في التجربة التاريخية. تبقى نتيجة إنشاء الملف وحذفه داخل uploads كما سُجلت، ولا تبرر تغيير الصلاحيات إلى 777.

اختبار إضافي: مجلد موجود تُمنع الكتابة فيه ثم تُستعاد

تاريخ التنفيذ: 17 سبتمبر 2026، الساعة 12:50 UTC. نُفذ هذا الاختبار المستقل بواسطة PHP CLI بالإصدار 8.3.30 على Windows، تحت حساب التشغيل نفسه وفي مجلد مؤقت معزول. لم تُغيّر صلاحيات الموقع المنشور، ولم يُستخدم مجلد uploads الحقيقي.

1. أنشأنا مجلد الاختبار وتأكدنا من وجوده، ثم كتب PHP ملفًا جديدًا بنجاح: 29 بايت.
2. حُفظت صلاحيات المجلد الأصلية، وأضيف منع إنشاء الملفات للحساب نفسه داخل هذا المجلد فقط باستخدام Windows ACL. بقي المجلد موجودًا، لكن إنشاء ملف جديد فشل برسالة Permission denied، وأعاد is_writable القيمة false.
3. استُرجعت الصلاحيات الأصلية في مسار تنظيف finally. أعيد تشغيل كود الكتابة نفسه باسم ملف اختبار جديد، فنجح وكتب 29 بايت.

السجل الفعلي المختصر

PHP: 8.3.30 | OS: Windows | execution: CLI
before:  directory_exists=true, is_writable=true,  file_created=true,  bytes_written=29
denied:  directory_exists=true, is_writable=false, file_created=false, error=Permission denied
restored: directory_exists=true, is_writable=true, file_created=true,  bytes_written=29
original_access_restored=true

ما تثبته النتيجة: أمكن إعادة إنتاج رفض كتابة فعلي في مجلد موجود وعلاجه بإعادة صلاحياته، دون خلطه بفشل مسار غير موجود. هذا اختبار لنظام الملفات بهوية PHP نفسها، وليس اختبار رفع عبر لوحة ووردبريس، ولا يحدد أرقام chmod المناسبة لاستضافة Linux. في الاستضافة الحقيقية يجب فحص المستخدم الذي يشغّل PHP والمالك والمجموعة وACL؛ لا تنقل قواعد Windows أو تمنح 777 للموقع.

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

المصادر

• مشكلة مستخدم لم يستطع إنشاء Backup أو مجلد إضافة.
• WordPress: صلاحيات الملفات والمجلدات.