WordPress не может записать файл: решаем проблему с правами доступа к wp-content и uploads

Краткий ответ: Ошибка «WordPress не может записать файл» возникает из-за неверных прав доступа к папкам wp-content и uploads. Решение — установить права 755 на все папки и 644 на файлы внутри wp-content/uploads через команду find ... -type d -exec chmod 755 {} +, а затем проверить владельца файлов (должен совпадать с пользователем веб-сервера).

Почему WordPress пишет «Не удалось создать каталог uploads» или «Не удалось записать файл»

WordPress — файловая CMS. Она создаёт миниатюры изображений, кэширует стили и скрипты, сохраняет плагины, обновляет ядро. Всё это требует права на запись в определённые каталоги. Если прав нет — CMS честно сообщает «Не удалось записать файл» или «Не удалось создать каталог uploads».

Типичные сценарии, когда появляется эта ошибка:

• Загрузка изображений в медиатеку — WordPress пытается создать вложенные подпапки /uploads/2026/06/
• Установка или обновление плагина/темы — нужно писать в /wp-content/plugins/ или /wp-content/themes/
• Автоматическое обновление ядра — требуется запись в корневые файлы
• Работа кэш-плагинов (W3 Total Cache, WP Super Cache) — создание файлов кэша в /wp-content/cache/
• Редактор тем в админке (устаревший, но всё ещё включён на некоторых сайтах)

Какие права должны быть: 755 и 644 — золотой стандарт

Важное уточнение: никогда не ставьте 777. Это «открыть все двери» — любой процесс на сервере (включая потенциально вредоносный) сможет писать в папки сайта. Реальные уязвимости часто начинаются с того, что админ выставил 777 в попытке починить ошибку.

Пошаговая инструкция

Шаг 1. Определите пользователя веб-сервера

Ошибка часто не в правах как таковых, а в несовпадении владельца. Файлы могут принадлежать вашему SSH-пользователю, а веб-сервер (Apache/Nginx) работает от другого пользователя.

# Для Apache
ps aux | grep -E 'apache|httpd' | head -5

# Для Nginx
ps aux | grep nginx | head -5

Типичные имена: www-data (Ubuntu/Debian), apache (CentOS/RHEL), nobody (некоторые сборки).

Шаг 2. Исправьте владельца

# Перейти в корень сайта
cd /var/www/example.com

# Сменить владельца на www-data (или apache)
sudo chown -R www-data:www-data wp-content

Если у вас несколько пользователей, которым нужен доступ (вы по SSH + веб-сервер), используйте группу:

sudo chown -R youruser:www-data wp-content
sudo chmod -R g+rwx wp-content

Более безопасный вариант — setgid бит, чтобы новые файлы наследовали группу:

sudo find wp-content -type d -exec chmod g+s {} +

Шаг 3. Установите корректные права

# Папки: 755
find wp-content -type d -exec chmod 755 {} +

# Файлы: 644
find wp-content -type f -exec chmod 644 {} +

Если нужна запись только в конкретные подпапки (без открытия всего wp-content), дайте 755 только нужным:

chmod 755 wp-content/uploads
chmod 755 wp-content/plugins
chmod 755 wp-content/cache   # если используется

Шаг 4. Проверьте результат

Создайте в админке WordPress новый пост и попробуйте загрузить изображение. Если ошибка исчезла — всё сделано верно.

Дополнительная проверка через WP CLI (если установлен):

wp media import /tmp/test-image.jpg

Дополнительные проверки: что ещё может блокировать запись

SELinux (особенно на CentOS/RHEL/AlmaLinux)

Если права 755/644 стоят, владелец правильный, но запись всё равно не работает — дело в SELinux:

# Проверить статус
getenforce

# Временно отключить для диагностики
sudo setenforce 0

# Если запись заработала — включить обратно и настроить контексты
sudo setenforce 1
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/example.com/wp-content(/.*)?"
sudo restorecon -Rv /var/www/example.com/wp-content

PHP open_basedir

Иногда хостинг (или собственный PHP-FPM) ограничивает, в какие каталоги PHP может писать:

; php.ini или конфиг пула
open_basedir = /var/www/example.com:/tmp

Убедитесь, что wp-content входит в open_basedir.

Диск переполнен или inodes закончились

Редкая, но показательная причина: на диске есть место, но закончились inodes (структуры файловой системы для хранения метаданных):

df -h          # проверка места
df -i          # проверка inodes

Если inodes на 100% — удалите ненужные файлы (обычно это кэш, сессии, старые бэкапы).

Профилактика

1. Настройте автоматическую смену прав через cron, если на сервере несколько пользователей:
   bash
# /etc/cron.daily/wp-permissions
#!/bin/bash
chown -R www-data:www-data /var/www/*/wp-content
find /var/www/*/wp-content -type d -exec chmod 755 {} +
find /var/www/*/wp-content -type f -exec chmod 644 {} +

2. Используйте константы WP для альтернативных каталогов (если у вас особый случай):
   php
// wp-config.php
define('UPLOADS', 'media/' . date('Y/m'));

3. Ведите журнал ошибок WordPress. Включите WP_DEBUG в wp-config.php на staging-окружении:
   php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
   Лог пишется в /wp-content/debug.log.

Когда права не помогли

Если после всех шагов ошибка остаётся — проверьте:

• Модуль PHP exec() отключён — WordPress использует его для распаковки обновлений
• Сервер на NGINX + PHP-FPM — проверьте listen.mode и listen.owner в пуле PHP-FPM
• Дочерние сайты WordPress Multisite — у каждого свои папки /wp-content/blogs.dir/ или /wp-content/uploads/sites/
• Символические ссылки — если wp-content — это симлинк на другую ФС, права могут не совпадать

Автор: Александр, технический специалист веб-студии «Гуру Практика»
Последнее обновление: июнь 2026
Источники: официальная документация WordPress (wordpress.org/support/article/changing-file-permissions/), практический опыт поддержки 50+ сайтов на WordPress