Як безпечно виправити права на 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