Проверка и настройка прав доступа к файлам сайта в 2026

Права доступа к файлам сайта — это одна из тех вещей, которые редко вспоминают в нормальной работе, но очень быстро замечают, когда что-то ломается. На моей практике чаще всего проблемы всплывают после миграции, обновления CMS или ручной заливки файлов по FTP.

Зачем проверять права доступа к файлам в 2026

В 2026 году у сайтов по-прежнему те же базовые проблемы: PHP 8.2 или 8.3, Nginx, Apache, Docker, разные панели хостинга и десятки способов испортить владельца файла или группу. И да, эта тема не устаревает. Если сайт работает на WordPress, Bitrix или Laravel, права всё равно надо держать под контролем.

Я обычно начинаю проверку прав не с самого сайта, а с симптомов. Не сохраняются настройки, не загружаются изображения, не пишутся логи, не работает кэш, а иногда и обновление модулей падает без понятной причины. На деле это часто не баг CMS, а банальная проблема с chmod/chown.

• ошибки записи в uploads, cache, tmp, upload, bitrix/cache;
• сломанные обновления и миграции;
• неработающие cron-задачи;
• риски, когда веб-сервер может читать и менять лишние файлы;
• случайное открытие конфигов, бэкапов и логов наружу.

Какие права считать нормальными

Универсальной магической схемы нет. Но есть рабочая база, от которой я обычно отталкиваюсь. Для файлов чаще всего используют 644, для папок — 755. Этого достаточно для большинства классических сайтов на shared-хостинге или VPS.

Но если проект работает под отдельным пользователем, через PHP-FPM, suEXEC или похожую схему, картина может отличаться. Поэтому я никогда не советую слепо ставить «777 на всё». Это плохая идея. Однозначно.

Базовая логика

• 644 — файл читается всеми, записывается только владельцем;
• 755 — каталог читается и открывается всеми, запись у владельца;
• 600 или 640 — для конфигов и секретов, если окружение это позволяет;
• 664/775 — иногда нужны в корпоративных схемах, но только если вы понимаете, зачем.

Для WordPress я часто вижу нормальную схему с 644 для файлов и 755 для директорий. Для Bitrix — то же самое, но дополнительно надо следить за папками cache, managed_cache, upload и локальными логами. В Laravel особое внимание идёт на storage и bootstrap/cache.

Как проверить права на сервере

Я обычно проверяю права через SSH. Это быстрее и надёжнее, чем тыкать по FTP-клиенту и гадать, где именно всё сломалось. Для начала смотрю дерево проекта и ищу выбивающиеся файлы с 777, 666, а также каталоги, у которых странный владелец.

find /var/www/site -type f -perm 0777 -o -type d -perm 0777
find /var/www/site -type f ! -perm 0644 -o -type d ! -perm 0755

Это не финальная проверка, но хороший старт. Дальше я обычно смотрю владельца и группу:

ls -la /var/www/site
stat /var/www/site/index.php

Если сайт на Nginx + PHP-FPM, важно понимать, под каким пользователем работает пул PHP. На Debian и Ubuntu это часто один сценарий, на CentOS и на хостингах — другой. Поэтому права надо подгонять под реальную схему запуска, а не под абстрактный «как у всех».

Что искать в первую очередь

• файлы с правами 777, 766, 666;
• папки, которые должны писать логи, но не могут этого делать;
• конфиги, доступные на запись веб-серверу без необходимости;
• архивы, бэкапы и дампы базы в корне сайта;
• файлы .env, settings.php, wp-config.php с слишком открытыми правами.

Как настроить права для WordPress, Bitrix и Laravel

На разных CMS правила похожи, но нюансы есть. И именно они чаще всего создают проблемы после переноса или обновления. У меня был клиент на WordPress, где медиатека не загружалась только потому, что owner у upload был root, а PHP работал от www-data. На вид всё «почти правильно», а по факту сайт упирался в права.

WordPress

Для WordPress я обычно проверяю wp-content, uploads, cache-папки плагинов и сам wp-config.php. Если включены автообновления, веб-серверу не нужно иметь полный доступ ко всему дереву. Иначе вы сами себе создаёте лишнюю дыру.

• файлы: 644;
• папки: 755;
• wp-config.php: по возможности 600 или 640;
• запись — только там, где реально нужна.

Bitrix

В Bitrix я всегда отдельно смотрю upload, bitrix/cache, bitrix/managed_cache, bitrix/tmp и локальные логи. Если права там задраны или, наоборот, слишком зажаты, сайт начинает чудить: то кеш не очищается, то админка выдаёт ошибку, то обновление не проходит.

• не раздавайте 777 папкам проекта целиком;
• проверьте, кто владелец файлов после выгрузки из архива;
• после правок тестируйте очистку кеша и сохранение настроек.

Если у вас Битрикс, я бы ещё посмотрел материалы по обслуживанию и правкам под систему через поддержку Bitrix. Там часто проблема не в одном chmod, а в общей конфигурации окружения.

Laravel

В Laravel чаще всего проблемы крутятся вокруг storage и bootstrap/cache. Если эти директории не пишутся, приложение начинает сыпать ошибками логирования, кеширования и сессий. На PHP 8.2 и 8.3 это особенно заметно в продакшене, потому что приложение быстрее доходит до критичного места и не всегда оставляет понятный след.

• storage — с правами на запись для PHP;
• bootstrap/cache — тоже должен быть доступен на запись;
• .env — не выкладывать с широкими правами;
• логи — писать в отдельную директорию, а не в корень.

Типичные ошибки при настройке

Самая частая ошибка — исправлять права точечно и без системы. Сегодня поставили 777 на папку загрузки, завтра — на весь проект, послезавтра забыли, где именно это сделали. И потом начинаются чудеса: сайт работает, но безопасность уже просела.

• выставили 777 «временно» и не вернули назад;
• изменили права, но не владельца файлов;
• забыли про скрытые файлы .env, .htaccess, .user.ini;
• не проверили права после распаковки архива;
• не учли, что cron запускается от другого пользователя;
• не посмотрели права на бэкапы и старые копии сайта.

Если права уже «разъехались», я обычно не советую чинить это вручную наугад. Сначала снимаю список проблемных файлов, потом привожу к единой схеме, потом тестирую загрузку, сохранение форм, обновления и очистку кэша. Это быстрее, чем лечить по одному симптому.

Как сделать проверку регулярной

Проверка прав не должна быть разовой акцией после взлома или переезда. Я бы включал её в обычный техконтроль сайта: после обновления CMS, после переноса на новый хостинг, после массовой загрузки файлов и после правок через панель управления.

Если нужен соседний процесс, который часто идёт рядом с правами, посмотрите бэкапы сайта: как делать правильно и не терять данные. На практике эти две вещи почти всегда связаны: сначала настраивают доступ к файлам, потом нормальные резервные копии, а потом уже обновления и деплой.

Ещё один полезный материал — миграция сайта на новый хостинг без потери данных. После переноса права и владельцы ломаются чаще, чем кажется. Особенно если переезд делался через архив и распаковку из-под root.

Когда лучше привлечь специалиста

Если вы видите, что права надо править на живом проекте с продажами, интеграциями и cron-задачами, я бы не делал это вслепую. Одно неверное изменение может остановить обновления, сломать отправку писем или открыть лишний доступ к конфигам. А потом уже начинается разбор полётов в самый неудобный момент.

Честно говоря, в таких задачах дешевле один раз заказать нормальную доработку сайта, чем потом ловить последствия по мелочи: от битых загрузок до странных ошибок доступа. Особенно если сайт работает на Bitrix, WordPress или Laravel и уже оброс своими особенностями.

Если же сомневаетесь, с чего начать, логично сначала сделать проверку сайта. Тогда видно, где проблема именно в правах, а где уже накладываются кэш, серверные настройки или баги в коде.