Кручу разные варианты по переносу веб сервера в гипервизор и вот решил попробовать сделать вариант друпала на CentOS.
Сделал как до это го делал на FreeBSD с учётом изменённых путей расположения сайтов. Пермишены все выданы (и согласно документации https://www.drupal.org/node/244924 и не согласно документации - полные 777)
Но почему-то друпал говорит
"../www-files закрыт для записи"
"../www-files/tmp закрыт для записи"
И владельцов всяко разно делал и все права перепроверял а результат тот же.
Дошло до чего.
Создал ещё один vhost - test.conf
Закачал в него дистриб Drupal 8.... иду на установку - и получаю
The translations directory is not writable.
The installer requires write permissions to sites/default/files/translations during the installation process.
Хорошо смотрим туда:
[root@www files]# ls -la
итого 0
drwxrwxrwx. 2 root root 6 сен 9 12:58 translations
Я так понимаю что какие-то иные ограничения срабатывают, но какие?
Комментарии
Может стоит директива open_base_dir в настройках апача?
а вот тут надо смотреть, но смогу только завтра, я уже дома...
А что с этой настройкой (я её не делал, - апач развернулся стандартно).
Можно в друпале по адресу /admin/reports/status/php найти open_basedir. Если там есть какое-то значение, то в настройках апача надо выставить его в none
Нет, дело не в этом, эта настройка не установлена. Ни в статусе не показывает ни в php.ini не определена.
Владельца + группу , проверять от кого запускается сервер + проверять права на папку ...
права в том числе выдаю 777 - ВСЕ имеют полные права (это для теста делал. А владельца даже с учётом 777 делал по разному. - Сервер запускается от имени apache, поэтому делал и его владельцем и не его. У меня стойкое впечатление сложилось, что накладываются какие то другие ограничения... может в *.conf тут что-то надо дописать, или в конфиге php...
Не пойму, на ровном месте какой то затык.
Последний раз ls снимал когда владельцы были root, но всё точно так же если ставлю apache...
А если попробовать поставить https://vestacp.com и через неё?
Лучше не надо.
Такое может быть если для родительских папок "недоступной" папки для вэбсервера нет прав на "запуск"(x - execute).
В случае с папками, это право разрешает просмотр содержимого папок.
надо проверить, "высоко" не поднимался...
ну в общем нет, было там полный порядок, на всякий случай уже для проверки сделал (это не рабочая, тестовая виртуальная среда, потому можно для проверки):
пермишены от самого корня /var но всё без разницы...
Под каким именем апач работает? обычно это www_data, а не root
работает под apache, как я писал уже.
Но это ничего не даёт - я пробовал по разному, в том числе:
А результат тот же самый.
Я понимаю что причина есть какая-то. Но владельцы и пермишены в ОС настроены...
Апач под каким пользователем работает? Ещё раз спрашиваю
ps auxwwww | grep apache
зы сорян, увидел
Да тут да, странные установочные параметры по умолчанию в CentOS7, не трудно запутаться, к тому же сам Апач они не Апачем зовут а hhtpd...
И вот видимо где-то с этой осью и особенности. Порою в особенностях установки Друпала на CentOS7, может чего найду...
Попробуйте на всё дерево папок.
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 640 {} \;
В темп может писать?
В общем дело не в этом, - как я писал -R 777 ставил от корневой веб папки...
А ларчик открывался просто, это издержки малого знакомства с CentOS и не вникания в процедуру его установки...
SeLinux был включен.
Всем спасибо
Сам запутался и людей буду путать... Изменяю свой пост.
Я не отключил Selinux, а перевёл его в режим логирования, для проверки, командой "setenforce 0", но как понял это строго не рекомендуется, такой режим работы (т.к. он фактически отключен), а потому полезу рыть мануалы на Selinux, т.к. пока его вообще не касался, посмотрю как настроить для апача/друпала.
PS в конфиге стоит enforcing потому и блокировало.