خطای 403 Forbidden بعد از آپلود یک پلاگین، یا 500 Internal Server Error بعد از تغییر دستی مجوزها؛ هر دو معمولاً یک ریشه دارند: عددی که در chmod نوشتهاید با نوع فایل یا کاربر اجراکننده نمیخواند. اگر دنبال مقدار دقیق برای یک فایل مشخص هستید، این مرجع را تا انتها بخوانید؛ اگر دنبال آموزش گامبهگام ساخت اکانت FTP هستید، راهنمای ساخت و مدیریت اکانت FTP مسیر درستتری است.
هر رقم chmod دقیقاً چه چیزی را کنترل میکند
مقدار chmod یک عدد سهرقمی هشتهشتی است که هر رقمش به یک گروه کاربری تعلق دارد: مالک فایل، گروه فایل، و بقیه. هر رقم خودش جمع سه بیت است:
- 4 = خواندن (read)
- 2 = نوشتن (write)
- 1 = اجرا (execute)
پس 6 یعنی خواندن و نوشتن، 5 یعنی خواندن و اجرا، 7 یعنی هر سه. عدد 644 را باز کنید: مالک 6 (خواندن+نوشتن)، گروه 4 (فقط خواندن)، بقیه 4 (فقط خواندن). همین.
رقم چهارم که اکثراً فراموش میشود
گاهی چهار رقم میبینید، مثل 2755 یا 1777. رقم اول بیتهای ویژه است:
| رقم | نام | اثر واقعی |
|---|---|---|
| 4 | setuid | برنامه با هویت مالک فایل اجرا میشود، نه کاربر اجراکننده |
| 2 | setgid | روی پوشه: فایلهای جدید گروه پوشه را میگیرند، نه گروه سازنده |
| 1 | sticky bit | فقط مالک فایل میتواند آن را حذف کند؛ کاربردش /tmp است |
روی هاست اشتراکی، setuid روی فایلهای PHP تقریباً همیشه غیرفعال است و اگر روی آن حساب کنید، اسکریپت با کاربر اشتباه اجرا میشود و فایلهای آپلودی مالکیت ناهمگون پیدا میکنند.
مقدار درست chmod برای هر نوع فایل
این جدول را روی بیشتر هاستهای لینوکسی میتوان مبنا گرفت:
| نوع | مقدار | توضیح |
|---|---|---|
| فایل معمولی (HTML، CSS، تصویر) | 644 | مالک مینویسد، بقیه فقط میخوانند |
| پوشه | 755 | بدون بیت اجرا، وبسرور نمیتواند داخل پوشه را باز کند |
فایل تنظیمات حاوی رمز (wp-config.php) | 600 یا 640 | هیچ دلیلی ندارد گروه یا بقیه آن را بخوانند |
| اسکریپت CGI یا فایل اجرایی | 755 | اجرا لازم است، نوشتن برای بقیه نه |
| پوشه آپلود وردپرس | 755 | اگر 777 بدهید، هر اسکریپت تزریقی میتواند بنویسد |
| پوشه موقت مشترک | 1777 | sticky bit جلوی حذف فایل دیگران را میگیرد |
روی فایلهای PHP هیچوقت بیت اجرا نگذارید. وبسرور آنها را از طریق interpreter میخواند، نه با اجرای مستقیم؛ 755 روی یک فایل PHP فقط یک سطح حمله اضافه است.
چرا 777 پاسخ اشتباه است، حتی وقتی کار میکند
وقتی خطای دسترسی میگیرید، سریعترین راه chmod -R 777 است و معمولاً هم جواب میدهد. مشکل اینجاست که هر پروسهای روی همان سرور، با هر کاربری، اجازه نوشتن و اجرا روی آن فایلها را پیدا میکند. روی هاست اشتراکی این یعنی یک اکانت همسایه با یک آسیبپذیری ساده میتواند فایلهای شما را بازنویسی کند. اگر مجبور شدید موقتاً 777 بدهید، بعد از تست فوراً به 755 برگردانید و علت اصلی را پیدا کنید.
دستورهای واقعی و پرچمهایی که به کار میآیند
سه دستور که در عمل بیشترین استفاده را دارند:
chmod 644 index.php
chmod -R 755 wp-content/uploads
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;دو دستور آخر تفاوت فایل و پوشه را رعایت میکنند و همین چیزی است که chmod -R 755 روی همهچیز خراب میکند: فایلها بیت اجرا میگیرند و پوشهها درست میمانند، ولی فایلهای تنظیمات هم 755 میشوند.
برای دیدن مقدار فعلی، ls -l خروجی نمادین میدهد (-rw-r--r--) و stat -c "%a %n" wp-config.php عدد خالص را. اگر مالکیت اشتباه است، chmod کمکی نمیکند؛ باید chown user:group file بزنید و روی هاست اشتراکی معمولاً فقط با پشتیبانی امکانپذیر است.
umask: چرا فایل جدید با 644 ساخته میشود
مقدار پیشفرض فایلهای تازه از umask میآید. اگر umask برابر 022 باشد، فایل جدید 666 - 022 = 644 و پوشه جدید 777 - 022 = 755 میشود. با umask مقدار 027، فایلها 640 و پوشهها 750 ساخته میشوند. اگر بعد از هر آپلود مجبورید دستی chmod بزنید، احتمالاً مشکل umask یا مالکیت پروسه PHP است، نه مجوز فایل.
اینجا اشتباه میکنند
رایجترین اشتباهی که میبینم این است که کسی chmod -R 777 را روی کل پوشه سایت میزند تا خطای 500 رفع شود. خطا رفع میشود، سایت بالا میآید، و دو هفته بعد سایت با یک ریدایرکت ناشناس به دامنه دیگر یا با فایلهای ناشناس در wp-content ظاهر میشود. علامت تشخیص: فایلهایی با تاریخ تغییر یکسان در پوشهای که خودتان دست نزدهاید، یا wp-config.php با مقدار 777 در خروجی ls -l. اگر این را دیدید، اول مجوزها را برگردانید، بعد فایلها را با نسخه سالم مقایسه کنید.
اشتباه دوم ظریفتر است: بعضیها فکر میکنند chmod روی مالکیت اثر دارد. ندارد. فایل با مالک root و مجوز 777 هنوز هم برای کاربر www-data قابل نوشتن است، ولی برای اسکریپتی که با کاربر دیگری اجرا میشود ممکن است در حذف یا تغییر نام مشکل داشته باشد. اگر خطای Permission denied روی عملیات حذف میگیرید، مشکل مالکیت پوشه والد است، نه مجوز خود فایل.
وقتی مجوز درست است ولی سایت هنوز خطا میدهد
اگر مجوزها روی 644 و 755 تنظیماند و همچنان صفحه سفید میبینید، مشکل جای دیگری است. راهنمای رفع صفحه سفید در وردپرس و PHP مسیر خطایابی را قدمبهقدم پوشش میدهد. اگر سایت کند است و به سقف منابع میخورید، مرجع محدودیتهای منابع هاست توضیح میدهد هر عدد چه چیزی را میشمارد.
برای محیط تست یا پنل مدیریتی که نمیخواهید عمومی باشد، احراز هویت وبسرور جای chmod را میگیرد؛ روشش در رمزگذاری پوشه در هاست آمده. و اگر روی سرور اختصاصی کار میکنید، setfacl و ACL گزینههای دقیقتری از مدل سهرقمی میدهند که روی سرور اختصاصی قابل استفادهاند.
یک نکته عملی: قبل از هر تغییر گروهی، خروجی find . -printf "%m %p\n" | sort را ذخیره کنید. برگرداندن مجوزها بدون نسخه پشتیبان از حالت اولیه، دردناکتر از خود خطاست.
پرسشهای پرتکرار
مقدار chmod 755 برای فایل درست است یا 644؟
برای فایل معمولی 644 درست است و 755 فقط برای اسکریپتهای اجرایی یا پوشهها. اگر فایل PHP را 755 بگذارید، سایت کار میکند ولی بیت اجرا برای همه باز میشود که سطح حمله را بالا میبرد.
تفاوت 755 و 775 در چیست؟
در 755 گروه فقط میخواند و اجرا میکند؛ در 775 گروه اجازه نوشتن هم دارد. روی هاست اشتراکی که گروه فایل با کاربران دیگر مشترک است، 775 یعنی آنها میتوانند فایل شما را تغییر دهند. 755 انتخاب امنتر است.
چرا بعد از chmod 777 هنوز خطای دسترسی میگیرم؟
چون مشکل مالکیت است، نه مجوز. اگر فایل مال کاربر دیگری باشد یا پوشه والد بیت اجرا نداشته باشد، 777 هم کمکی نمیکند. خروجی ls -l و namei -l /path/to/file را بررسی کنید.
مقدار chmod برای wp-config.php چقدر باشد؟
600 یا 640 کافی است. این فایل رمز دیتابیس را نگه میدارد و هیچ کاربر دیگری نباید آن را بخواند. اگر وردپرس با 600 خطا داد، یعنی مالکیت فایل با کاربر اجراکننده PHP یکی نیست و باید مالکیت را اصلاح کنید، نه مجوز را باز کنید.