Как безопасно исправить права на wp-content/uploads в WordPress

Почему WordPress не может загрузить файл

При загрузке изображения WordPress работает не от имени вашего SSH-пользователя, а от имени пользователя веб-процесса. Для PHP-FPM это обычно www-data, nginx или отдельный пользователь сайта. Если каталог uploads принадлежит другому пользователю и не имеет групповых или общих прав на запись, PHP не сможет создать в нем файл.

Проблема часто возникает после миграции, когда файлы копировались от имени root, администратора резервных копий или пользователя старого сервера. При этом сам WordPress может открываться нормально, поскольку для чтения файлов достаточно других прав.

• ошибка возникает только при загрузке медиафайла;
• новые миниатюры не создаются после загрузки изображения;
• в журнале PHP или Nginx есть сообщение Permission denied;
• каталог wp-content/uploads принадлежит root или другому пользователю.

Перед изменением прав определите путь и пользователя PHP

Команды нужно выполнять из корня конкретного сайта или указывать абсолютный путь к каталогу. Сначала проверьте, где именно расположен WordPress, а затем посмотрите владельца и текущие права uploads.

Для определения процессов PHP-FPM используйте команду:

ps aux | grep '[p]hp-fpm'

ls -ld /var/www/example.com/wp-content/uploads
find /var/www/example.com/wp-content/uploads -maxdepth 2 -printf '%M %u:%g %p\n' | head

Как правильно прочитать результат

В выводе ps могут быть процессы master, запущенные от root, и worker-процессы, запущенные от www-data или другого пользователя. Для доступа к файлам важен именно пользователь worker-процесса или пользователь, указанный в конфигурации пула PHP-FPM.

Если на сервере работает несколько сайтов, у каждого пула может быть собственный системный пользователь. В такой конфигурации не следует автоматически назначать www-data: сначала убедитесь, какой пул обслуживает нужный домен.

• не ориентируйтесь только на пользователя Nginx или Apache: PHP может работать от другого учетного имени;
• не меняйте владельца всего /var/www, если проблема касается только uploads;
• перед chown проверьте путь, чтобы случайно не изменить права другого сайта.

Назначьте uploads правильного владельца

После определения пользователя PHP назначьте его владельцем каталога uploads и его содержимого. В примере используется www-data. Если PHP-FPM работает от имени другого пользователя, замените это значение на фактическое.

Команда chown рекурсивно изменяет владельца и группу, поэтому она исправит настройки самого каталога, уже существующих подкаталогов и файлов.

cd /var/www/example.com
sudo chown -R www-data:www-data wp-content/uploads

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

На сервере, где разработчики загружают файлы через SFTP, а PHP работает от отдельного пользователя, простая смена владельца может усложнить дальнейшее редактирование. В такой схеме настраивают общую группу, добавляют в нее нужных пользователей и используют групповые права. Это более сложный вариант, но он лучше подходит для командной работы и изолированных сайтов.

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

Установите безопасные права для каталогов и файлов

Для типичного WordPress достаточно прав 755 для каталогов и 644 для файлов. Каталоги с правами 755 можно читать и просматривать, а их владелец также может записывать в них данные. Файлы с правами 644 доступны для чтения, но записывать в них может только владелец.

Применяйте права отдельно к каталогам и файлам. Это важно, поскольку chmod 755 для всего дерева сделает исполняемыми даже обычные изображения и другие файлы, хотя это им не требуется.

cd /var/www/example.com
sudo find wp-content/uploads -type d -exec chmod 755 {} \;
sudo find wp-content/uploads -type f -exec chmod 644 {} \;

Почему не нужно использовать 777

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

Даже если 777 временно устранил ошибку, это не является корректной настройкой. Нужно определить пользователя PHP и предоставить право на запись именно ему.

Проверьте родительские каталоги и дополнительные ограничения

Чтобы PHP смог обратиться к uploads, у него должно быть право прохода через все родительские каталоги: /var, /var/www, каталог сайта и wp-content. Для прохода обычно достаточно права x для нужного пользователя или группы. Открывать эти каталоги на запись не требуется.

Если после chown и chmod ошибка сохраняется, причина может быть не в классических правах Unix. В системах с SELinux или аналогичными механизмами контроля доступа блокировка возможна даже при правильном владельце. Также проверьте ACL, если они используются на сервере.

• проверьте права каждого родительского каталога командой namei -l /полный/путь/wp-content/uploads;
• убедитесь, что диск не заполнен: df -h;
• проверьте inode, если на сервере много мелких файлов: df -i;
• посмотрите, не смонтирован ли каталог или файловая система в режиме read-only.

namei -l /var/www/example.com/wp-content/uploads
df -h
df -i

Защитите uploads от выполнения PHP-файлов

Каталог uploads предназначен для изображений, документов и других загружаемых файлов, а не для выполнения PHP-кода. Дополнительной мерой защиты будет запрет выполнения PHP-файлов в этом каталоге на уровне конфигурации веб-сервера.

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

Также проверьте, не появились ли в uploads файлы с расширениями .php, .phtml или похожими. Наличие таких файлов не всегда доказывает взлом, но требует проверки источника и журналов.

• обновляйте WordPress, темы и плагины;
• не разрешайте загрузку произвольных типов файлов без необходимости;
• проверяйте подозрительные файлы и изменения в журналах доступа;
• не делайте весь wp-content доступным для записи веб-процессу.

Проверьте результат и найдите ошибку в логах

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

Если ошибка повторяется, сразу просмотрите журналы PHP-FPM, Nginx или Apache в момент тестовой загрузки. Сообщение Permission denied указывает на проблему с доступом к файлам, тогда как ошибки о нехватке места, лимитах PHP или неправильном MIME-типе требуют другого решения.

• проверьте владельца: ls -ld wp-content/uploads;
• проверьте права конкретного файла: stat wp-content/uploads/год/месяц/файл.jpg;
• убедитесь, что PHP-FPM после изменений использует ожидаемый пул;
• после завершения теста не оставляйте временные права 777.

ls -ld /var/www/example.com/wp-content/uploads
stat /var/www/example.com/wp-content/uploads/2025/01/example.jpg