سایت بالا نمیآید، مرورگر 403 Forbidden نشان میدهد، یا وردپرس موقع آپلود قالب میگوید Could not create directory. وارد File Manager میشوید، روی پوشه راستکلیک میکنید، 777 میگذارید و مشکل حل میشود. تا هفته بعد که هاستینگ ایمیلی میفرستد و میگوید یک فایل PHP ناشناس داخل wp-content/uploads اجرا شده است. این مقاله درباره همان فاصله بین «کار میکند» و «درست است» نوشته شده.
سطح دسترسی فایل یعنی چه و چرا عدد مینویسند
لینوکس برای هر فایل سه گروه تعریف میکند: مالک (user)، گروه (group) و بقیه (others). هر گروه سه بیت دارد: خواندن (r=4)، نوشتن (w=2) و اجرا (x=1). عددی که در chmod مینویسید جمع همین بیتهاست. پس 644 یعنی مالک بخواند و بنویسد، گروه فقط بخواند، بقیه فقط بخواند. 755 یعنی مالک همهکار بتواند بکند، بقیه فقط بخوانند و وارد پوشه شوند.
نکتهای که خیلیها نمیدانند: معنی x روی فایل و روی پوشه فرق دارد. روی فایل یعنی «اجرا شود». روی پوشه یعنی «بتوانی داخلش بروی و اسم فایلهایش را ببینی». اگر پوشهای 644 باشد، حتی اگر فایل داخلش 644 و کاملاً خوانا باشد، وبسرور نمیتواند به آن فایل برسد. خطای حاصل هم گمراهکننده است: 403 Forbidden روی فایلی که خودش هیچ مشکلی ندارد.
مقدار درست سطح دسترسی فایل و پوشه
برای اکثریت قاطع سایتهای PHP روی هاست اشتراکی، این دو عدد کافی است:
- فایلها:
644 - پوشهها:
755
همین. اگر مالکیت فایلها درست باشد، این دو عدد همهچیز را راه میاندازد. دستور اجرای یکجا از طریق SSH:
find /home/USER/public_html -type d -exec chmod 755 {} \;
find /home/USER/public_html -type f -exec chmod 644 {} \;ترتیب مهم است: اول پوشهها، بعد فایلها. اگر برعکس بزنید و بعداً پوشهای ساخته شود، نتیجه یکسان است، ولی اجرای دستور روی درخت بزرگ چند ثانیه طول میکشد و بهتر است یکبار و درست انجام شود.
استثناهایی که واقعاً وجود دارند
سه جا معمولاً باید از قاعده بالا خارج شوید. اول، فایل wp-config.php در وردپرس که میتوانید 600 یا 640 بگذارید؛ هیچکس جز مالک نباید آن را بخواند. دوم، پوشههایی که اسکریپت باید داخلشان فایل بسازد، مثل wp-content/uploads یا پوشه cache افزونهها؛ اینها اغلب 755 کار میکنند، ولی اگر PHP با مالکیت متفاوتی اجرا شود، 775 لازم میشود. سوم، فایلهای اجرایی مثل wp-cron.php که بعضی محیطها با 755 صدا میزنند.
و یک هشدار: 775 فقط وقتی معنی دارد که مالک و گروه درست تنظیم شده باشند. اگر مالکیت فایلها nobody:nobody باشد و شما 775 بگذارید، عملاً به همه کاربران سرور اجازه نوشتن دادهاید. اینجا اشتباه میکنند: عدد را عوض میکنند، مالکیت را نه.
چرا 777 راهحل نیست، حتی وقتی جواب میدهد
777 یعنی هر کاربری روی آن سرور، از هر سایت دیگری که روی همان ماشین میزبانی میشود، اجازه نوشتن و اجرا روی فایلهای شما را دارد. روی هاست اشتراکی این یعنی یک سایت همسایه که خودش هک شده، میتواند داخل wp-content/uploads شما یک فایل PHP بگذارد و از آن اجرا بگیرد. شما هیچ نشانهای نمیبینید؛ سایتتان سالم کار میکند. تا وقتی اسکنر هاستینگ یا یک گزارش ترافیک خروجی مشکوک، ماجرا را لو بدهد.
مشکل دوم فنیتر است. بعضی هاستها بهدلیل تنظیمات suPHP یا PHP-FPM، فایل با سطح دسترسی 777 را بهکل رد میکنند و بهجای رفع خطا، 500 Internal Server Error میگیرید. یعنی 777 هم امن نیست و هم همیشه کار نمیکند. اگر بعد از تغییر مجوزها صفحه سفید دیدید، مسیر خطا جای دیگری است؛ راهنمای رفع صفحه سفید در وردپرس و PHP ترتیب درست بررسی لاگها را توضیح میدهد.
علامت واقعی مشکل مالکیت
اگر با 755 و 644 هم خطای نوشتن میگیرید، مشکل تقریباً همیشه مالکیت است، نه عدد. با SSH بررسی کنید:
ls -ln /home/USER/public_html/wp-content/uploads
id
ps aux | grep -E 'php-fpm|apache' | head -3اگر مالک فایلها با کاربری که PHP زیر آن اجرا میشود یکی نیست، هیچ عددی مشکل را حل نمیکند. راه درست، اصلاح مالکیت است:
chown -R USER:USER /home/USER/public_htmlروی هاست اشتراکی معمولاً دسترسی chown ندارید و باید از پنل یا تیکت پشتیبانی بخواهید. روی سرور اختصاصی خودتان این محدودیت را ندارید و همین یک دلیل کافی است که بعضی تیمها بعد از مدتی از هاست اشتراکی مهاجرت کنند.
خطاهای رایج و آنچه در لاگ میبینید
| علامت | علت محتمل | اقدام |
|---|---|---|
403 Forbidden روی یک فایل | پوشه والد مجوز اجرا (x) ندارد | پوشه را 755 کنید |
Permission denied در لاگ PHP | مالکیت نادرست یا پوشه فقطخواندنی | بررسی ls -ln و اصلاح مالکیت |
| آپلود ناموفق در وردپرس | uploads قابل نوشتن نیست | 755 یا در صورت نیاز 775 |
500 Internal Server Error بعد از chmod | 777 رد شده توسط PHP handler | بازگشت به 644/755 |
| افزونه نمیتواند فایل بسازد | پوشه cache با مالکیت اشتباه | حذف پوشه و ساخت مجدد توسط PHP |
یک نکته عملی: قبل از هر تغییر گروهی، خروجی مجوزها را ذخیره کنید تا اگر چیزی خراب شد بتوانید برگردانید.
find /home/USER/public_html -printf '%m %p\n' > ~/perms-backup.txtوقتی باید از قاعده 644/755 خارج شوید
اگر سایت شما روی هاست اشتراکی است و مالکیت درست تنظیم شده، 644 و 755 را نگه دارید و به هیچ بهانهای 777 نگذارید. اگر روی VPS یا سرور اختصاصی هستید و PHP-FPM را با کاربر اختصاصی سایت اجرا میکنید، همان 644/755 کافی است و امنتر از هر چیز دیگری. تنها حالتی که 775 منطقی است، جایی است که یک گروه مشترک بین وبسرور و کاربر استقرار (deploy) وجود دارد و هر دو باید در پوشه بنویسند. حتی آنوقت هم 777 انتخاب غلطی است.
برای محیط تست یا پنل مدیریت، بهجای باز کردن مجوزها از احراز هویت وبسرور استفاده کنید؛ رمزگذاری پوشه در هاست دقیقاً برای همین سناریو نوشته شده و امنتر از هر تغییری در chmod است.
اگر تعداد فایلهای سایت زیاد است و مدیریت دستی مجوزها وقتگیر شده، راهنمای ساخت و مدیریت اکانت FTP نشان میدهد چطور دسترسیها را از سمت اکانت محدود کنید، نه از سمت فایل. و اگر میخواهید بدانید چه محدودیتهای دیگری روی هاست شما اعمال است، مرجع محدودیتهای منابع هاست هر عدد را جداگانه توضیح داده.
پرسشهای پرتکرار
سطح دسترسی درست برای فایلهای وردپرس چند است؟
فایلها 644 و پوشهها 755. این دو عدد برای اکثر نصبهای وردپرس روی هاست اشتراکی کافی است و نیازی به تغییر ندارید. تنها استثناها wp-config.php با 600 یا 640 و پوشههای آپلود و کش هستند که در صورت نیاز به 775 میرسند.
چرا بعد از 777 سایت کار میکند ولی هاستینگ هشدار میدهد؟
چون 777 به هر کاربر روی سرور اجازه نوشتن و اجرا میدهد. سایت شما کار میکند، ولی اگر سایت دیگری روی همان سرور آلوده شود، مهاجم میتواند فایل مخرب داخل پوشههای شما بگذارد و اجرا بگیرد. هشدار هاستینگ معمولاً بعد از اسکن خودکار همین فایلها فرستاده میشود.
تفاوت chmod و chown چیست و کدام را باید بزنم؟
chmod سطح دسترسی را عوض میکند و chown مالکیت را. اگر خطای نوشتن میگیرید و مجوزها 644/755 هستند، مشکل مالکیت است و باید chown بزنید. روی هاست اشتراکی معمولاً این دسترسی را ندارید و باید از پشتیبانی بخواهید.
آیا 755 برای پوشه امن است؟
بله، به شرطی که مالکیت درست باشد. 755 یعنی فقط مالک میتواند بنویسد و بقیه فقط میتوانند بخوانند و وارد پوشه شوند. خطر وقتی شروع میشود که مالکیت به کاربر اشتباهی مثل nobody داده شده باشد؛ آنوقت 755 هم عملاً باز است.
قبل از هر تغییر گروهی، یکبار خروجی مجوزها را ذخیره کنید و بعد دستور find را اجرا کنید. اگر بعد از آن سایت بالا نیامد، احتمالاً مالکیت است، نه عدد. برای شروع، هاست لینوکس با مالکیت درست تنظیمشده، همان چیزی است که این دسته از خطاها را از ریشه کم میکند.