Не удается установить новые плагины из-за ошибки "Could not create directory"

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

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

Если у вас есть полный и тотальный контроль над машиной, это нормально. С другой стороны, если это shared-хостинг, то вы создали брешь в безопасности.

Обычно веб-серверы работают от какого-то пользователя (например, www-data), который затем выполняет код других пользователей (например, "otto", мой пользовательский аккаунт). В такой ситуации веб-сервер не сможет создавать файлы от имени "otto" и, следовательно, не сможет корректно создавать файлы как мой аккаунт. Таким образом, проверка WordPress на возможность создания правильно принадлежащих файлов и, следовательно, установки плагинов или обновления файлов будет проваливаться, и это правильно, потому что если бы мои файлы принадлежали общему пользователю веб-сервера, это было бы риском для безопасности.

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

Сейчас вы пытаетесь решить эту проблему, изменяя владельца всех файлов WordPress на тот же аккаунт, от которого веб-сервер записывает файлы. Более нормальный подход для этого - изменить способ, которым веб-сервер записывает файлы, чтобы позволить PHP-процессу "принадлежать" пользовательскому аккаунту, от которого он выполняет файлы.

Общее решение для этого - "suphp". Эта версия PHP устанавливает пользователя, от которого работает PHP-процесс, таким же, как владелец PHP-файлов, которые он выполняет. Это безопаснее в настройках shared-хостинга, потому что гарантирует, что PHP-процесс, запущенный общим веб-сервером, работает от владельца PHP-файлов и, следовательно, не может читать аккаунты других пользователей и тому подобное.

В Ubuntu, я считаю, это общий способ сделать это:

Установить suphp:

$ sudo apt-get install libapache2-mod-suphp

Отключить старый mod_php

$ sudo a2dismod php5 

Перезапустить Apache

$ sudo /etc/init.d/apache2 restart

И вуаля. Теперь ваши файлы WordPress PHP должны принадлежать их обычному владельцу. Никаких специальных трюков, изменения прав или владения и тому подобного. Поскольку PHP-процесс будет работать от владельца этих файлов, он сможет записывать в них как этот владелец. Директории должны иметь права 755, файлы - 644 (заметьте, suphp не любит, когда файлы доступны для записи группой, поэтому 755/644 - правильный набор прав).

Для меня (на Ubuntu) пришлось добавить umask 002 в файл /etc/apache2/envvars, чтобы WordPress загружал плагины/изображения с правами 775 вместо 755 (т.е. разрешить всем, кроме Apache и root, изменять загруженные файлы)

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

Вы можете исправить это с помощью следующих команд из командной строки (предполагается, что вы находитесь в корневой папке WordPress):

# cd wp-content
# chmod -R a+w plugins
# chmod -R a+w themes
# chmod -R a+w upgrade

Самое безопасное решение — добавить Apache в ту же группу, что и владелец установки WordPress, и изменить все групповые разрешения на доступные для записи.

Иногда на сайтах бывает, что исправление прав доступа к директориям и файлам не решает проблему. В таких случаях я обнаруживал, что на одной или нескольких директориях установлен неизменяемый флаг (immutable flag). Это легко исправить, выполнив команду chattr -R /var/www/sub.domain.tld от имени root.

Очень простое решение: измените разрешения для папки opt, выполнив команду sudo chmod -R 777 /opt.