Права chmod на папки PHP-скрипта

Права решают простую вещь: может ли PHP-процесс создать файл в каталоге. Карточка сохраняется, а фото нет — почти всегда permission denied на upload. Кэш не пишется — админка тормозит или сыпется предупреждениями. Это не «баг загрузчика картинок», пока не проверили chmod и владельца.

На Windows в MicroServer права POSIX почти не мешают. Боль больнее на Linux shared и VDS.

Базовая схема

• Каталоги — 755 (drwxr-xr-x).
• Файлы — 644 (-rw-r--r--).
• Конфиг с паролем БД — не шире, чем нужно; 600 или 640, если владельцы правильные.

777 на весь сайт «чтобы заработало» — плохая привычка. На shared иногда прокатывает годами, пока вирус не допишет shell в upload. Лучше выровнять владельца.

Что должно быть writable

Зависит от комплекта, но обычно:

• каталоги загрузок: upload/, uploads/, files/, images/;
• кэш и временные: cache/, tmp/, temp/;
• иногда — каталог сессий или runtime, если скрипт пишет их внутрь проекта.

PHP-файлы движка writable быть не обязаны. Веб-серверу достаточно читать.

Владелец важнее цифры

На VDS с PHP-FPM пул крутится от www-data, nginx или отдельного пользователя сайта. Архив залили под root — цифры 755 не помогут, если каталог принадлежит root и group не пишет.

chown -R www-data:www-data /var/www/site
find /var/www/site -type d -exec chmod 755 {} \;
find /var/www/site -type f -exec chmod 644 {} \;

Имя пользователя подставьте своё (смотрите пул в /etc/php/*/fpm/pool.d/). На ISPmanager часто пользователь совпадает с системным юзером сайта.

На shared файловый менеджер создаёт файлы от вашего логина, PHP иногда от того же — тогда 755 хватает. Если PHP от другого uid — панель даёт «изменить владельца» или советует 775 на upload.

Типичные ошибки в логах

failed to open stream: Permission denied — нет права на запись в каталог или на сам файл.

Unable to create directory — родительский каталог не writable, или open_basedir режет путь.

Move uploaded file failed — временный upload PHP прошёл, а в целевой каталог перенос нет.

Смотрите точный путь в сообщении. Чините его, а не «весь www».

SELinux и open_basedir

На некоторых VDS кроме chmod есть SELinux. Симптомы похожи на permission denied при «правильных» 755. Это уже chcon/контекст httpd_sys_rw_content_t — отдельная история. На shared чаще режет open_basedir: скрипт не имеет права писать вне разрешённых путей. Тогда перенос upload «на уровень выше» ломается не из-за chmod.

Безопасность upload

Каталог загрузок должен принимать файлы, но не обязан исполнять PHP. Идеально — запрет выполнения скриптов в upload через конфиг Nginx/Apache или .htaccess. Иначе один загруженный .php вместо картинки станет бэкдором.

Не храните конфиг с паролями внутри writable-каталога без нужды.

Windows и локалка

В MicroServer NTFS-права обычно не мешают записи в папку проекта. Если «не пишет» локально — смотрите путь в конфиге, антивирус и то, что диск не read-only. См. локальный сервер.

Связка с установкой

Права выставляют после распаковки и до/после установщика — как скажет readme. Общий порядок: установка. Если 500 из-за невозможности писать сессии/кэш — ошибка 500. Перенос с сохранением загрузок: перенос скрипта.

На Nginx не забудьте client_max_body_size, иначе большая картинка умрёт до проверки прав: Nginx + PHP-FPM.

Как понять владельца PHP

На VDS создайте phpinfo или выполните:

ps aux | grep php-fpm

В пуле смотрите user/group. На shared в панели часто написано «сайт работает от пользователя X». Архив, залитый панельным файловым менеджером, обычно уже под тем же X. Архив через root-SSH — нет.

775 vs 755

Если веб-пользователь состоит в группе владельца каталога, иногда хватает 775 на upload и group write. Если пользователи разные и группы не дружат — либо общий пользователь, либо ACL, либо (хуже) 777. На нормальном VDS стремитесь к одному uid пула и файлов.

Файлы внутри upload после загрузки часто создаются с 644 — это нормально. Каталог должен позволять создавать новые файлы.

Диагностика одной командой

От пользователя PHP (su/sudo -u www-data) попробуйте:

touch /var/www/site/upload/test_write.txt

Получилось — права ок, ищите ошибку в коде/пути. Не получилось — читайте сообщение permission denied и чините владельца. Не начинайте с chmod -R 777 /.

Кэш и сессии

Кроме upload смотрите каталоги cache и session. Симптомы: медленная админка, постоянные разлогины, Warning в логе. Путь session.save_path вне проекта тоже должен быть writable — иногда это /var/lib/php/sessions с кривыми правами после апдейта пакета.

После восстановления из бэкапа

tar от root развернёт root:root. Сайт «как будто восстановили», но загрузки мертвы. Сразу chown под пул. Чеклист бэкапа: бэкап, перенос: перенос.

На shared после restore из панели хостера права обычно выставляются сами — но не всегда на кастомные пути вне www.

Чеклист

1. Кто пользователь PHP-FPM/Apache.
2. Кто владелец каталога upload.
3. 755/644 база, writable только там, где нужно.
4. Нет исполнения PHP в upload.
5. Конфиг не 777.
6. Тест touch и загрузка картинки из админки.

Если после правки прав всё ещё 500 — смотрите лог: там может быть уже не permission denied, а база/синтаксис: ошибка 500, MySQL. Требования окружения: требования.

Ещё один частый кейс на shared: файловый менеджер показывает «права 755», а PHP работает в режиме, где владелец файла — другой uid из пула облака. Тогда помогает кнопка «исправить владельца» в панели Beget/Timeweb/ISPmanager или обращение в поддержку хостера с просьбой выровнять UID сайта. Самим chmod 777 вы маскируете симптом и оставляете upload исполняемым для всех — плохой обмен. После выравнивания владельца вернитесь к 755/644 и повторите загрузку одного файла из админки. Установка с нуля, если каталоги upload в комплекте надо создать вручную: установка.