خطای Permission در فایل‌های وردپرس

یکی از آن روزهایی را به یاد می‌آورم که مشتری‌ام با صدای نگران زنگ زد و گفت «سایت من فقط یک فایل آپلود نمی‌کند». اول فکر کردم مشکل از اندازه فایل است؛ اما وقتی لاگ سرور را باز کردم، پیام روشن بود: Permission denied. آن یک جمله ساده، دو ساعت وقت گرفت تا ریشه‌اش را پیدا کنم — چون خطای Permission در وردپرس، همیشه آن‌قدر که پیامش ساده است، ساده نیست. این خطا می‌تواند از یک فایل با مجوز اشتباه تا یک سیاست امنیتی سرور، لایه‌های مختلفی داشته باشد. در این مقاله، همان مسیر را باز می‌کنم که در پروژه‌های واقعی برای تشخیص و رفع این خطا طی می‌کنم.

اگر با ساختار پایه‌ای وردپرس و لایه‌بندی‌اش آشنایی ندارید، پیش از این مقاله وردپرس چیست و چگونه شروع کنیم را بخوانید؛ چون خطاهای Permission فقط وقتی معنا پیدا می‌کنند که لایه‌بندی فایل، پوشه، کاربر و گروه روی سرور را بشناسید.

خطای Permission دقیقاً چیست؟

در سیستم‌های لینوکس — که اکثر سرورهای وردپرس روی آن‌ها اجرا می‌شوند — هر فایل و پوشه، مجموعه‌ای از مجوزها دارد که تعیین می‌کند چه کاربری می‌تواند آن را بخواند، بنویسد یا اجرا کند. وقتی PHP سعی می‌کند به فایلی دسترسی بگیرد که مجوز لازم را ندارد، با پیام Permission denied متوقف می‌شود. این خطا در وردپرس خودش را در قالب‌های مختلف نشان می‌دهد: ناتوانی در آپلود تصویر، ناتوانی در نصب افزونه، خطا در ذخیرهٔ تنظیمات، یا صفحهٔ سفید.

نکتهٔ کلیدی این است که خطای Permission، یک مسئلهٔ محیطی است، نه یک باگ در کد. یعنی هیچ افزونه‌ای به‌تنهایی نمی‌تواند آن را رفع کند؛ چرا که ریشهٔ مسئله در لایهٔ سیستم‌عامل و پیکربندی سرور است. همین ویژگی، تشخیص را دشوار می‌کند — چون کاربر عادی که فقط با پیشخوان وردپرس کار می‌کند، به آن لایه دسترسی ندارد.

تجربه‌ام می‌گوید در بیش از هشتاد درصد موارد، این خطا به‌خاطر مجوز پوشه یا مالکیت اشتباه فایل رخ می‌دهد. باقی موارد، به سیاست‌های سرور، محدودیت‌های هاست، یا تنظیمات امنیتی مرتبط است.

خطای Permission، شبیه در بسته‌ای است که کلیدش در جیب شما نیست؛ کلید در یک لایه پایین‌تر از وردپرس است، جایی که فقط با FTP یا SSH به آن دسترسی دارید.

خطاهای Permission انواعی دارند

وقتی کاربر می‌گوید «سایت من خطای Permission می‌دهد»، در واقع ممکن است با یکی از چند سناریوی متفاوت روبه‌رو باشد. تفکیک این سناریوها، نیمی از راه‌حل است:

هر کدام از این سناریوها، مسیر تشخیص و رفع خودش را دارد. مهم این است که اول بفهمید با کدام‌یک طرف هستید، بعد سراغ تنظیم مجوز بروید. رفع کورکورانهٔ مجوزها (مثلاً chmod -R 777) بزرگ‌ترین اشتباهی است که در این مسیر دیده‌ام.

مدل مجوز در لینوکس: کاربر، گروه، مجوز

برای اینکه بفهمید چطور باید مجوزها را تنظیم کنید، اول باید مدل آن را بفهمید. در لینوکس، هر فایل به یک کاربر (Owner) و یک گروه (Group) تعلق دارد. سه سطح دسترسی وجود دارد: خواندن (r)، نوشتن (w)، اجرا (x). و این دسترسی‌ها به سه گروه اعمال می‌شوند:

• کاربر مالک — کاربری که فایل به نامش ثبت شده.
• گروه مالک — گروه کاربری که فایل به آن تعلق دارد.
• سایرین — بقیهٔ کاربران سیستم.

در نمایش عددی، این سه گروه با سه عدد سه‌رقمی نشان داده می‌شوند؛ مثلاً 755 یعنی کاربر مالک می‌تواند بخواند، بنویسد و اجرا کند (۷)، گروه و سایرین فقط می‌توانند بخوانند و اجرا کنند (۵ و ۵). این مدل، در مقالات انگلیسی به شکل «owner-group-others» یا به اختصار ugo شناخته می‌شود.

مسئلهٔ همیشگی در وردپرس این است که فایل‌ها معمولاً با کاربر FTP (که شما با آن آپلود می‌کنید) ثبت می‌شوند، اما کد PHP با کاربر وب‌سرور (مثلاً www-data یا apache) اجرا می‌شود. اگر این دو کاربر با هم یکی نباشند و مجوزهای فایل هم اجازهٔ نوشتن به وب‌سرور ندهد، به خطای Permission می‌خورید. این پدیده، در هاست‌های اشتراکی بیشتر دیده می‌شود و در ادامه مفصل دربارهٔ آن صحبت می‌کنم.

مجوزهای درست برای وردپرس کدامند؟

قاعدهٔ استانداردی که وردپرس در مستندات خودش توصیه می‌کند، و من در پروژه‌های خودم همیشه رعایتش کرده‌ام:

نکتهٔ مهم: این اعداد برای کاربر مالک قابل‌نوشتن هستند، نه برای گروه و سایرین. یعنی اگر وب‌سرور با یک کاربر متفاوت از مالک اجرا می‌شود، ممکن است نتواند در این فایل‌ها بنویسد. در این حالت، راه‌حل درست، تغییر مالکیت است نه افزایش مجوز. متأسفانه، خیلی از کاربران به‌جای تغییر مالکیت، مجوز را به 777 بالا می‌برند که ریسک امنیتی جدی دارد. در بخش بعدی، دربارهٔ این موضوع دقیق‌تر صحبت می‌کنم.

قاعدهٔ طلایی مجوز در وردپرس: پوشه‌ها 755، فایل‌ها 644، هیچ‌چیز هرگز 777. تنها استثناها، پوشه‌های موقت و کش هستند که در شرایط خاص می‌توانند 775 داشته باشند.

نشانه‌های رایج خطای Permission

پیش از اینکه به سراغ فنی بروید، این نشانه‌ها را در سایت خودتان چک کنید؛ هرکدام یک سرنخ دقیق است:

• پیام «The uploaded file could not be moved to wp-content/uploads» — یعنی پوشهٔ uploads اجازهٔ نوشتن ندارد.
• پیام «Could not create directory» هنگام نصب افزونه یا قالب.
• پیام «Installation failed: Destination folder already exists» — که گاهی به‌خاطر مجوز پوشه است، گاهی به‌خاطر باقی‌ماندهٔ نصب قبلی.
• پیام «Unable to write to file» در زمان ذخیرهٔ تغییرات در فایل‌های قالب.
• صفحهٔ سفید یا خطای ۵۰۰ که با خطای Permission denied در لاگ همراه است.

سه مورد اول، بیش از نیمی از مواردی هستند که در تجربه‌ام دیده‌ام. اگر با یکی از آن‌ها روبه‌رو هستید، مستقیم به بخش مربوطه در همین مقاله بروید.

روش گام‌به‌گام تشخیص

ترتیبی که در پروژه‌های خودم طی می‌کنم، از سریع‌ترین به دقیق‌ترین است:

1. آیا سایت بعد از یک تغییر خاص این خطا را می‌دهد؟ اگر بله، آن تغییر را برگردانید — معمولاً مشکل حل می‌شود.
2. چه کسی مالک فایل است؟ از طریق FTP یا SSH، مجوز و مالکیت فایل مشکل‌دار را ببینید.
3. آیا خطا در عملیات خاص رخ می‌دهد؟ مثلاً فقط در آپلود یا فقط در نصب افزونه.
4. آیا در لاگ خطا، مسیر فایل مشخص شده؟ این مسیر، دقیقاً به شما می‌گوید کجا دنبال کنید.
5. آیا هاست‌تان سیاست خاصی دارد؟ بعضی هاست‌ها، برای امنیت، مجوز نوشتن فایل‌های PHP را از کاربر وب‌سرور می‌گیرند.

برای فعال‌سازی لاگ خطا، در wp-config.php پیش از خط /* That's all, stop editing! */ اضافه کنید:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

لاگ در wp-content/debug.log ذخیره می‌شود و مسیر دقیق فایل مشکل‌دار را نشان می‌دهد. اگر با خطای ۵۰۰ نیز روبه‌رو هستید، خطای ۵۰۰ وردپرس چیست و چگونه رفع می‌شود را بخوانید؛ چون بعضی از آن‌ها ریشه‌شان در Permission است.

رفع خطای آپلود در پوشهٔ uploads

شایع‌ترین خطای Permission، در پوشهٔ wp-content/uploads رخ می‌دهد. این پوشه، جایی است که وردپرس تصاویر، PDF و فایل‌های مدیا را ذخیره می‌کند. اگر مجوز آن اشتباه باشد، کاربر نمی‌تواند چیزی آپلود کند.

تشخیص: از طریق FTP یا File Manager، پوشهٔ wp-content و زیرپوشهٔ uploads را باز کنید. روی پوشهٔ uploads کلیک راست کنید و گزینهٔ Permissions یا Change Permissions را انتخاب کنید. مجوز باید 755 باشد.

رفع: اگر مجوز پوشه 755 نیست، آن را به 755 تغییر دهید. اگر پوشهٔ uploads به‌کلی وجود ندارد، آن را بسازید و مجوز 755 بدهید. وردپرس خودش داخل آن، پوشه‌های سال و ماه را با مجوز 755 می‌سازد.

یک نکتهٔ ظریف: در بعضی هاست‌ها، مجوز پوشه باید 775 باشد تا کاربر وب‌سرور بتواند در آن بنویسد. اگر هاست شما این تنظیم را دارد، آن را رعایت کنید. اما مجوز 777 هرگز توصیه نمی‌شود، چون هر کاربر یا فرآیندی روی سرور می‌تواند در فایل‌های شما دست ببرد. موضوع امنیت این تصمیم را در بهترین افزونه‌های امنیتی وردپرس هم به تفصیل بررسی کرده‌ام.

رفع خطا در فایل wp-config.php

فایل wp-config.php، قلب تنظیمات وردپرس است و حاوی اطلاعات حساسی مثل رمز دیتابیس. توصیهٔ امنیتی وردپرس این است که مجوز این فایل 600 یا حداکثر 644 باشد. اگر مجوز اشتباه باشد، یا نمی‌توانید تغییرات در آن ذخیره کنید، یا بدتر، سایت به‌خطر می‌افتد.

تشخیص: از طریق FTP، مجوز فایل wp-config.php را چک کنید. اگر 644 است، امن و کاربردی است.

رفع: اگر مجوز را روی 666 یا 777 می‌بینید، سریعاً به 644 یا 600 تغییر دهید. اگر خطای Permission می‌گیرید و نمی‌توانید تغییر دهید، به‌احتمال زیاد مالک فایل با کاربر FTP فعلی شما یکی نیست. در این حالت، از پشتیبانی هاست بخواهید مالکیت را برای شما اصلاح کند. مالکیت، موضوعی است که در بخش بعدی مفصل بررسی می‌کنم.

نکتهٔ مهم امنیتی: هرگز فایل wp-config.php را روی 777 نگذارید — حتی موقت. در این حالت، هر کاربر و فرآیند روی سرور می‌تواند آن را بخواند یا تغییر دهد، که با توجه به اطلاعات دیتابیس درونش، یک فاجعهٔ امنیتی است.

رفع خطا در نصب یا آپدیت افزونه

اگر در زمان نصب افزونه، پیام‌های مثل «Could not create directory» یا «Could not copy file» می‌بینید، مسئله معمولاً در مجوز پوشهٔ wp-content/plugins یا مالکیت آن است.

تشخیص: مجوز پوشهٔ plugins باید 755 باشد و محتوای داخل آن هم به‌همین شکل. اگر پوشه مجوز درست دارد، ولی خطا ادامه دارد، مسئله مالکیت است.

رفع: اگر با FTP آپلود می‌کنید، مطمئن شوید که فایل‌های آپلودی با کاربری ثبت می‌شوند که وب‌سرور بتواند در آن‌ها بنویسد. در هاست‌های اشتراکی، معمولاً کاربر FTP و کاربر وب‌سرور یکی هستند؛ اما در بعضی هاست‌ها (خصوصاً VPS) متفاوت هستند. راه‌حل بلندمدت این است که هم مالکیت فایل‌ها را اصلاح کنید، هم مجوزها را استاندارد نگه دارید.

نکتهٔ عملی از تجربه: اگر افزونه‌ای در نصب ناموفق است و پیام «Destination folder already exists» می‌دهد، اول پوشهٔ ناقص همان افزونه را از wp-content/plugins حذف کنید، سپس نصب را دوباره امتحان کنید. باقی‌ماندهٔ نصب قبلی، یکی از علل رایج خطاهایی است که کاربر گمان می‌کند خطای Permission است. برای انتخاب افزونه‌های معتبر و کم‌دردسر، فهرست افزونه‌های ضروری وردپرس نقطهٔ شروع مناسبی است.

رفع خطا در ویرایش فایل قالب

وردپرس به‌طور پیش‌فرض، ویرایشگر فایل قالب را در پیشخوان فعال نگه می‌دارد. اگر در زمان ویرایش فایل‌های قالب، پیام «Unable to write to file» یا «Permission denied» می‌بینید، دو سناریو وجود دارد:

سناریوی اول — مجوز فایل: فایل قالب مجوز 644 ندارد. از طریق FTP، مجوز را اصلاح کنید.

سناریوی دوم — سیاست امنیتی سرور: بعضی هاست‌ها یا افزونه‌های امنیتی، دسترسی نوشتن PHP به فایل‌های قالب را می‌گیرند. در این حالت، ویرایشگر پیشخوان کار نمی‌کند و باید از FTP استفاده کنید. این رفتار، از منظر امنیتی، بهتر است تا اینکه همیشه باز باشد. اگر با این سیاست روبه‌رو شدید، آن را دور نزنید؛ فقط از FTP یا از ویرایشگر محلی استفاده کنید.

نکتهٔ کلیدی از تجربه: هر بار که در پیشخوان، ویرایشگر فایل را باز می‌کنید، یک ریسک امنیتی برای سایت باز می‌کنید. اگر حمله‌ای رخ دهد و به پیشخوان دسترسی پیدا کند، مهاجم می‌تواند کد مخرب به قالب اضافه کند. ساده‌ترین راه برای بستن این ریسک، خاموش‌کردن ویرایشگر پیشخوان است — موضوعی که در بخش «سخت‌سازی امن» باز می‌کنم.

مالکیت فایل‌ها: چالش پنهان هاست اشتراکی

گاهی اوقات مجوزها همه درست هستند، اما سایت همچنان خطای Permission می‌دهد. در این حالت، مقصر مالکیت (Ownership) است، نه مجوز. این مسئله، بیشتر در هاست‌هایی دیده می‌شود که کاربر FTP و کاربر وب‌سرور با هم یکی نیستند.

برای درک ساده، فرض کنید فایل شما مالکش user123 است (کاربر FTP)، ولی PHP با کاربر apache اجرا می‌شود. اگر فایل مجوز 644 داشته باشد، کاربر apache نمی‌تواند در آن بنویسد. راه‌حل‌های ممکن:

• تغییر مالکیت: فایل‌ها را به کاربر وب‌سرور (مثلاً www-data یا apache) تخصیص دهید. این کار از طریق SSH و با دستور chown انجام می‌شود. در هاست‌های اشتراکی که SSH ندارید، از پشتیبانی هاست بخواهید.
• افزودن به گروه مشترک: کاربر FTP و وب‌سرور را در یک گروه مشترک قرار دهید و مجوز پوشه‌ها را 775 بگذارید.
• استفاده از suPHP یا PHP-FPM با مالکیت تطبیقی: بعضی هاست‌ها PHP را با کاربر مالک فایل اجرا می‌کنند. این بهترین حالت است، چون نیازی به تغییر مالکیت ندارید.

در پروژه‌هایی که با هاست‌های اشتراکی کار می‌کردم، همیشه از پشتیبانی هاست می‌خواستم که ساختار مالکیت و کاربر PHP را برای من روشن کند. دانستن این که PHP با کدام کاربر اجرا می‌شود، تصمیم‌گیری دربارهٔ مالکیت را ساده‌تر می‌کند.

مجوزها تعیین می‌کنند چه کسی می‌تواند به فایل دسترسی بگیرد؛ مالکیت تعیین می‌کند چه کسی صاحب تصمیم است. تا وقتی هر دو درست نباشند، خطای Permission ادامه دارد.

تنظیم مجوز با FTP و SSH

دو ابزار برای تنظیم مجوز در اختیار دارید: FTP (از طریق رابط گرافیکی) و SSH (از طریق خط فرمان). روش FTP ساده‌تر است اما برای حجم زیاد فایل، آهسته. روش SSH سریع‌تر است و می‌توانید مجوز تمام فایل‌ها را با یک دستور تغییر دهید.

دستورات پرکاربرد SSH:

# تنظیم مجوز تمام پوشه‌ها به 755
find /path/to/wordpress -type d -exec chmod 755 {} \;

# تنظیم مجوز تمام فایل‌ها به 644
find /path/to/wordpress -type f -exec chmod 644 {} \;

# تنظیم مالکیت فایل‌ها به کاربر و گروه دلخواه
chown -R user:group /path/to/wordpress

# بررسی مجوز یک فایل خاص
ls -l /path/to/file

نکتهٔ حیاتی: پیش از اجرای این دستورات روی سایت زنده، حتماً یک بکاپ کامل بگیرید. حتی اگر ساده به نظر می‌رسند، تغییر مجوزها روی حجم بالا می‌تواند عواقب ناخواسته‌ای داشته باشد. راهنمای بکاپ در چگونه از سایت وردپرسی بکاپ بگیریم آمده است.

نکتهٔ دیگر: اگر با دستور chmod -R 777 سایت خود را برای چند ثانیه در دسترس نوشتن عموم قرار داده‌اید، حتماً بلافاصله مجوزها را برگردانید. حتی یک دقیقه ماندن روی 777، می‌تواند به نفوذ منجر شود. اگر می‌خواهید بدانید چه پیش می‌آید، بهترین افزونه‌های امنیتی وردپرس نمونه‌های واقعی را روایت می‌کند.

مجوزهای شل و خطر امنیتی آن

شایع‌ترین راه‌حل غلطی که در فروم‌های وردپرس می‌بینم: «همه مجوزها را روی 777 بگذار تا مشکل حل شود.» این راه‌حل، شاید مشکل را در ظاهر حل کند، اما در واقع یک درِ باز امنیتی برای حمله‌کنندگان می‌سازد. من در ده‌ها پروندهٔ نفوذ وردپرسی که عیب‌یابی کرده‌ام، شاهد بوده‌ام که سایت‌های آسیب‌پذیر اغلب با مجوزهای باز پوشه‌ها و فایل‌ها مواجه بوده‌اند.

چرا 777 خطرناک است؟ چون اجازه می‌دهد هر کاربر و فرآیندی روی سرور، در فایل‌های شما بنویسد. روی هاست اشتراکی که ده‌ها سایت دیگر هم روی همان سرور هستند، یک سایت آسیب‌پذیر می‌تواند به پایگاهی برای حمله به سایت‌های مجاور تبدیل شود. سایت‌های امنیتی، به این نوع پدیده «Cross-Site Contamination» می‌گویند.

اگر با فایل‌های PHP روبه‌رو هستید که مجوز 777 دارند — که در بعضی سایت‌های قدیمی دیده‌ام — اول آن‌ها را به 644 برگردانید و اگر مالکیت مشکل داشت، مالکیت را اصلاح کنید. هیچ‌وقت مسئلهٔ Permission را با رها کردن امنیت سایت حل نکنید. اگر شک دارید که سایت شما قبلاً با مجوزهای بد آلوده شده، بررسی فایل‌ها از طریق سئو تکنیکال یا افزونه‌های امنیتی می‌تواند نشانه‌ها را آشکار کند.

سخت‌سازی امن با DISALLOW_FILE_EDIT

یکی از بهترین کارهایی که می‌توانید برای کاهش ریسک خطاهای Permission — و ریسک امنیتی مرتبط با آن — انجام دهید، خاموش کردن ویرایشگر فایل در پیشخوان است. این کار، جلوی ورود مهاجم از طریق پیشخوان به کد را می‌گیرد. در wp-config.php اضافه کنید:

define( 'DISALLOW_FILE_EDIT', true );

با فعال‌سازی این خط، ویرایشگر قالب و افزونه در پیشخوان غیرفعال می‌شود و همهٔ تغییرات باید از طریق FTP یا SSH اعمال شوند. این رویکرد، هم امنیت را بالا می‌برد و هم خطای Permission در این بخش‌ها را به‌کلی حذف می‌کند — چون دیگر هیچ ویرایشی از طریق پیشخوان رخ نمی‌دهد.

یک تغییر مکمل که در پروژه‌های خودم اجرا می‌کنم: خاموش‌کردن نصب افزونه از پیشخوان برای کاربران با نقش‌های پایین‌تر. این کار، هم مدیریت ریسک را ساده‌تر می‌کند، هم خطاهای Permission مربوط به نصب افزونه را کم می‌کند. اگر با ساختار نقش‌های وردپرس آشنا نیستید، وردپرس چیست و چگونه شروع کنیم تفاوت بین نقش‌ها را توضیح می‌دهد.

اشتباهات رایج در رفع خطای Permission

یک اشتباه ظریف دیگر: کاربران، گاهی برای عیب‌یابی سریع، مجوز همه پوشه‌ها را به‌صورت دستی به 755 تغییر می‌دهند، اما پوشهٔ wp-content/uploads و زیرپوشه‌های سال/ماه آن را فراموش می‌کنند. این اتفاق، فقط بعد از آپلود تصویر جدید خودش را نشان می‌دهد و علت پیدا کردنش زمان می‌برد.

پیشگیری بلندمدت

پنج عادت که در پروژه‌های خودم خطاهای Permission را به حداقل رسانده‌اند:

• مجوزهای استاندارد را از همان ابتدا تنظیم کنید. بعد از هر نصب افزونه یا انتقال، مجوزها را بازبینی کنید.
• ویرایشگر فایل پیشخوان را خاموش کنید. با DISALLOW_FILE_EDIT — که هم امن است و هم خطاهای Permission مرتبط با آن را حذف می‌کند.
• از یک کاربر FTP مطابق با کاربر وب‌سرور استفاده کنید. در هاست‌های اشتراکی، از پشتیبانی بپرسید که ساختار مالکیت به چه شکل است.
• پایش مصرف منابع و خطاها را جدی بگیرید. پیش از آنکه خطاهای Permission انباشته شوند، خودتان خبردار شوید.
• بکاپ منظم و تست بازگردانی داشته باشید. در صورت فاجعه، این تنها راه برگشت امن است. راهنمای اصولی در بکاپ‌گیری از وردپرس آمده است.

و یک عادت مهم که در پروژه‌های حساس به‌کار می‌گیرم: مستندسازی ساختار مجوز و مالکیت سایت. یک فایل کوچک یادداشت داشته باشید که در آن، کاربر FTP، کاربر وب‌سرور، و مجوزهای پیش‌فرض ثبت شده باشند. اگر روزی خطای Permission ظاهر شد، داشتن این سند، تشخیص را از چند ساعت به چند دقیقه کاهش می‌دهد.

نگاه عمیق‌تر: مجوز به‌مثابه قرارداد امنیتی

برای مهندسینی که با وردپرس در سطح پلتفرم کار می‌کنند، خطای Permission فراتر از یک رخداد تصادفی است؛ نشانهٔ شکافی در قرارداد امنیتی میان لایه‌های سیستم است. سه تفکیک در این نگاه، تفاوت بین پروژه‌های حرفه‌ای و آماتور را می‌سازد:

یک — مجوز، نه یک تنظیم ثابت، بلکه یک قرارداد زنده. در سیستم‌های مدیریت‌شده، دسترسی فایل‌ها توسط یک فریم‌ورک سیاست (Policy Framework) تعریف می‌شود: هر عملیات باید از یک نقطهٔ چک عبور کند. وردپرس، چون بومی این مفهوم را ندارد، مجوزها به‌صورت دستی مدیریت می‌شوند و همین دستی‌بودن، منبع خطاهای مکرر است. یک الگوی پیشرفته این است که با استفاده از یک سیستم مانند SELinux یا AppArmor، قرارداد دسترسی را به‌صورت سیاست‌محور تعریف کنیم. این رویکرد، در سطح سازمانی جواب می‌دهد و از پروژه‌هایی که به‌طور مکرر با مجوز درگیر هستند، پیشگیری می‌کند.

دو — جداسازی کاربران به‌ازای هر سایت. در هاست اشتراکی، همهٔ سایت‌ها با یک کاربر وب‌سرور اجرا می‌شوند. نتیجه: یک سایت آسیب‌پذیر، می‌تواند به فایل‌های سایت‌های دیگر دسترسی پیدا کند. راه‌حل معماری: استفاده از الگوی per-site user isolation که در هاست‌های مدیریت‌شده و پلتفرم‌هایی مثل GridPane پیاده‌سازی می‌شود. در این مدل، هر سایت یک کاربر و گروه اختصاصی دارد و مجوزها بر مبنای همان تعریف می‌شوند. اگر سایت شما جزو سایت‌های حساس است، این مسئله خودش یک دلیل کافی برای مهاجرت از هاست اشتراکی ساده است.

سه — مجوزها به‌عنوان بخشی از پیکربندی نسخه‌بندی‌شده. در پروژه‌های بالغ، من مجوزها را به‌عنوان بخشی از پیکربندی سایت می‌بینم: یک اسکریپت نصب (deployment script) که مجوزها را در هر استقرار تنظیم می‌کند. این کار، خطای انسانی را حذف می‌کند و اطمینان می‌دهد که در هر بار استقرار، سایت با مجوزهای استاندارد راه می‌افتد. اگر با ابزارهایی مثل Git و CI/CD کار می‌کنید — که در بحث سئو تکنیکال هم به آن اشاره کرده‌ام — این رویکرد، بخشی از خط تولید سایت است نه یک اقدام عیب‌یابی.

یک نکتهٔ انتزاعی‌تر: در تئوری سیستم‌ها، «مجوزها» نمونه‌ای کلاسیک از Access Control هستند. مدل‌های مختلفی وجود دارد: DAC (اختیاری)، MAC (اجباری)، RBAC (نقش‌محور). وردپرس از مدل RBAC برای کاربران داخلی استفاده می‌کند، اما در سطح فایل، به DACِ سیستم‌عامل وابسته است. اگر این دو مدل، هم‌راستا نباشند — مثلاً وب‌سرور با یک کاربر اجرا شود اما فایل‌ها با کاربر دیگری آپلود شده باشند — خطاهای Permission پیدایش می‌شوند. راهکار بلندمدت، هم‌راستاکردن این دو مدل با یک لایهٔ پیکربندی مستقل است: کاربر وب‌سرور و کاربر فایل، یا یکی باشند، یا در یک گروه مشترک قرار بگیرند. این تصمیم، نه در وردپرس، بلکه در لایهٔ زیرین سرور گرفته می‌شود.

حرف آخر

خطای Permission در وردپرس، در ظاهر ساده به نظر می‌رسد اما در واقع یکی از آن دسته خطاهایی است که ریشه‌اش در لایه‌ای پایین‌تر از وردپرس — یعنی سیستم‌عامل و سرور — قرار دارد. این را بارها در پروژه‌های خودم دیده‌ام: کاربر عادی که فقط با پیشخوان وردپرس کار می‌کند، هیچ راهی برای حل این خطا در پیشخوان ندارد. رمز حل، در لایهٔ بالاتر از وردپرس و در فهم مدل مجوز و مالکیت لینوکس است.

سه درس اصلی این مقاله را می‌توانم در یک جمله جمع کنم: پوشه‌ها 755، فایل‌ها 644، هرگز 777. اما فهم این قاعده، بدون فهم مالکیت و ساختار کاربران سرور، نصفه است. اگر سایت شما روی هاست اشتراکی است، حتماً از پشتیبانی بپرسید که PHP با کدام کاربر اجرا می‌شود و فایل‌های شما با کدام کاربر ذخیره می‌شوند. دانستن این دو، کلید اصلی حل خطاهای Permission است.

اگر این خطا را روی سایت خودتان دیده‌اید و علتش را کشف کرده‌اید که در این مقاله نبوده، خوشحال می‌شوم در دیدگاه‌ها بخوانم. به‌ویژه اگر با سناریوهای نادری مثل قوانین SELinux یا محدودیت‌های خاص هاست ایرانی روبه‌رو شده‌اید، تجربه‌تان برای خوانندهٔ بعدی که در همان لحظه گرفتار است، از هر راهنمای عمومی ارزشمندتر است. و اگر به‌نتیجه رسیدید که هاست فعلی‌تان به‌طور ساختاری محدودکننده است، دو مقالهٔ راهنمای انتخاب هاست و تأثیر هاست بر سرعت سایت مسیر بعدی شما هستند. 🔐