Перенесли сайт на хостинг, и плагины перестали ставиться. Или медиафайлы не загружаются через админку. Или обновление ядра валится с ошибкой «Could not create directory». Знакомо?

Причина почти всегда одна, неправильные права доступа на файлы и папки. Локальный сервер (OpenServer, MAMP) работает от имени текущего пользователя Windows/macOS и прощает всё. Боевой хостинг на Linux, нет. У каждого файла и каталога есть владелец и три уровня разрешений, и если веб-сервер не может писать в нужную папку, сайт ломается молча или с непонятной ошибкой.

Ниже, что такое 755 и 644 на самом деле, как выставить их один раз через FileZilla для всего сайта, и какие файлы требуют особого подхода.

💡 Быстрый обзор:

• Что означают цифры 755 и 644 и почему 777 это дыра в безопасности
• Как массово выставить права через FileZilla за 2 захода: сперва папки, потом файлы
• Какие разрешения нужны wp-config.php,.htaccess и папке wp-content
• Как сделать то же самое через SSH одной командой за 5 секунд

Что означают права доступа и почему 777, это катастрофа

Каждый файл и папка на Linux-сервере хранят три набора разрешений: для владельца, для группы и для всех остальных. Цифра, это сумма битов: 4 (чтение) + 2 (запись) + 1 (выполнение для папок = вход внутрь).

755 для папок расшифровывается так: владелец может всё (7), группа и остальные, читать и входить (5). Папка доступна веб-серверу для сканирования, создания внутри файлов и подпапок, но никто посторонний не может её удалить или переименовать.

644 для файлов: владелец читает и пишет (6), остальные, только читают (4). PHP-файлы исполняются интерпретатором, а не системой, бит выполнения им не нужен.

777 (владелец+группа+остальные = всё), это открытая дверь. Любой процесс на сервере, включая скрипты соседних сайтов на shared-хостинге, может читать, менять и удалять ваши файлы. По данным WPScan за 2025, некорректные разрешения входят в пятёрку самых частых векторов взлома WordPress на shared-хостингах. Никогда не ставьте 777, если плагин или тема требуют таких прав, это красный флаг.

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

Официальная документация WordPress определяет рекомендованные разрешения так:

На большинстве хостингов владелец файловой системы совпадает с пользователем, от которого работает PHP (настройка suPHP/FastCGI + suEXEC). В такой конфигурации прав 755/644 достаточно: WordPress может писать в wp-content/uploads, обновлять ядро и плагины, устанавливать темы, без эскалации до 777.

Проверьте, подходит ли это вашему хостеру: зайдите в админку → попробуйте установить любой бесплатный плагин. Установился без запроса FTP-доступа, значит, схема 755/644 работает и права уже правильные.

Как выставить права через FileZilla: пошагово

FileZilla, бесплатный FTP-клиент, который умеет массово рекурсивно менять права. Скачайте с официального сайта если ещё нет.

Шаг 1: подключаемся и заходим в корень WordPress

Подключитесь к хостингу по FTP (логин/пароль, те же что от хостинг-аккаунта, порт 21). В правой панели перейдите в корневую папку сайта. Туда, где лежат wp-config.php, wp-content, wp-admin и wp-includes.

Шаг 2: выставляем 755 на все папки

Выделите все файлы и папки в корне (Ctrl+A). Правый клик → «Права доступа к файлу».

В открывшемся окне в поле «Числовое значение» введите 755. Отметьте чекбокс «Перенаправить во вложенные каталоги». Переключатель поставьте в положение «Применить только к каталогам». Нажмите OK.

FileZilla пройдёт по каждой папке и подпапке сайта и выставит 755. Процесс занимает от нескольких секунд до пары минут в зависимости от размера сайта.

Шаг 3: выставляем 644 на все файлы

Снова выделите всё в корне (Ctrl+A), снова правый клик → «Права доступа к файлу».

Теперь введите 644. Отметьте «Перенаправить во вложенные каталоги». Переключатель, «Применить только к файлам». OK.

Готово. Два захода, папки и файлы, и весь сайт приведён к стандарту.

Быстрый способ через SSH: команда find

Если у вас есть SSH-доступ к серверу, та же операция делается двумя командами за пять секунд:

1
find /path/to/wordpress -type d -exec chmod 755 {} \;
2
find /path/to/wordpress -type f -exec chmod 644 {} \;

Первая проходит по всем папкам (-type d) и ставит 755. Вторая, по всем файлам (-type f) и ставит 644. Замените /path/to/wordpress на реальный путь к корню сайта (обычно /home/username/public_html).

После этого отдельно ужесточите wp-config.php:

1
chmod 600 /path/to/wordpress/wp-config.php

И .htaccess, если он у вас есть (Apache-сервер):

1
chmod 644 /path/to/wordpress/.htaccess

Если сайт на Nginx, файла .htaccess нет, этот шаг пропустите.

Что делать, если права сбиваются снова

Ситуация: вы выставили 755/644, всё работало, а через неделю, та же ошибка. Причина чаще всего в процессе, который работает от другого пользователя.

Типичные виновники:

• Cron-задачи хостинга. Некоторые хостеры запускают обслуживающие скрипты от root, и они создают файлы с правами, которые веб-сервер потом не может перезаписать. Решение: попросите техподдержку настроить cron от имени вашего пользователя.
• Сторонний плагин резервного копирования. Пишет дампы и архивы в wp-content от имени того пользователя, под которым запущен. Проверьте логи плагина, если он создаёт файлы не от имени владельца сайта, замените на альтернативу.
• Кеширующий плагин. Создаёт папки кеша с неверными правами. Зайдите в настройки плагина и найдите кнопку «Очистить кеш» или «Reset permissions».

Универсальный быстрый фикс, повторить процедуру из раздела выше (FileZilla за 2 захода или две find-команды). Это не решит первопричину, но вернёт сайт в рабочее состояние.

⁉️🤔 Частые вопросы

Что делать, если после смены прав сайт упал в «белый экран смерти»?

Белый экран (WSOD) после массовой смены прав, крайне редкая ситуация, но возможная. Первое: включите WP_DEBUG в wp-config.php, так вы увидите текст ошибки вместо белого экрана. Второе: проверьте, не выставили ли вы 644 на папки (папкам нужен бит выполнения, то есть 5 в конце). Исправьте одной find-командой: find /path -type d -exec chmod 755 {} \;, этого достаточно в большинстве случаев. Если сайт не заработал, восстановите бекап и меняйте права постепенно: сначала на wp-content, затем на корень, наблюдая за реакцией.

Можно ли выставить права через встроенный файловый менеджер хостинга?

Да, но только для отдельных файлов и папок. cPanel-хостинги дают File Manager с пунктом «Change Permissions» в контекстном меню. Однако рекурсивно выставить права на сотни и тысячи файлов через веб-интерфейс практически невозможно, для массовой операции берите FileZilla или SSH.

Какие права должны быть у папки wp-content/uploads?

Стандартные 755, как и у всех остальных папок. Если плагин или тема создают подпапки внутри uploads и испытывают проблемы, проверьте владельца процесса (должен совпадать с владельцем папки), а не поднимайте права до 777. Иногда проблема решается добавлением define('FS_METHOD', 'direct'); в wp-config.php.

Нужно ли выставлять права на файлы внутри wp-admin и wp-includes?

Да, стандартные 644 для файлов, 755 для папок, как и для всего остального сайта. Процедура с FileZilla (выделить всё в корне) обрабатывает их автоматически.

Хостер требует 777 на какие-то папки, это нормально?

Нет. Требование 777, признак того, что PHP на сервере работает от пользователя, отличного от владельца файлов (например, mod_php без suEXEC). При такой конфигурации WordPress не может писать в папки без «всеобщего» доступа. Варианты: сменить хостера на того, кто использует suPHP/FastCGI (большинство современных), или добавить define('FS_METHOD', 'direct'); в wp-config.php, в части случаев этого достаточно.

Правильные права, фундамент, а не опция

Выставили 755 на папки и 644 на файлы, закрыли самый частый канал «непонятных» ошибок при переносе сайта. Две минуты в FileZilla или две команды в SSH экономят часы гадания над логами.

Если сайт на хорошем хостинге с suPHP/FastCGI, этих прав достаточно на всё: установка плагинов, загрузка медиа, автообновления ядра. Не поднимайте права до 777, даже если об этом просит инструкция к старому плагину. И добавьте wp-config.php в отдельную строку: chmod 600, в нём пароль базы данных, доступ посторонним туда не нужен.