Подтвердить что ты не робот

Перезапуск Apache приводит к тому, что DocumentRoot должен быть каталогом, даже если он является каталогом и, похоже, нет никаких проблем

У меня есть то, что почти наверняка вопрос новичка. Я ожидал найти проблему при написании этого вопроса, но я все еще застрял.

Я хочу изменить DocumentRoot для apache, но я продолжаю получать сообщение об ошибке "DocumentRoot должен быть каталогом".

Ситуация:

  • Код работает в виртуальной машине VMWare 4.0.4 build-744019
  • Версия Linux - это выпуск Scientific Linux 6.4 (Carbon)
  • Версия apache - Apache/2.2.15 (Unix) (это установка yum без ничего специальный)

В httpd.conf

DocumentRoot "/home/stave/www"

Когда я перезагружаюсь, я получаю сообщение

Starting httpd: Syntax error on line 292 of /etc/httpd/conf/httpd.conf:
DocumentRoot must be a directory

Шаги, предпринятые до сих пор:

Я гарантировал, что каталог существует:

ls -asl /home/stave
4 drwxrwxrwx.  2 stave stave    4096 Feb  9 09:08 www
It even has a file in it "index.html", so I am very sure that the directory exists

Я считал, что это может быть проблема привилегий, поэтому (это виртуальная машина для разработки, изолированная от Интернета, и я занимаюсь устранением неполадок, поэтому я не слишком беспокоюсь о безопасности), поскольку вы можете видеть, что я устанавливаю привилегии 777.

Я даже изменил пользователя, что apache работает как (и подтвердил, что изменение сработало с ps), чтобы сохранить его, чтобы гарантировать, что привилегии просто не должны быть проблемой.

Stackoverflow

Есть несколько ответов на переполнение стека, но большинство из них говорят "прочитайте сообщение об ошибке. Это говорит о том, что каталог фактически не существует". Другие подразумевали, что в конце может произойти косая черта, которая будет плохой.

Другие веб-сайты

Наиболее полезным я нашел этот, который советовал

Вероятно, вы получили ошибку "DocumentRoot должно быть каталогом", даже если это действительно каталог из-за расширений SELinux. Запустите system-config-securitylevel (или redhat-config-securitylevel), чтобы отключить SELinux для httpd или предоставить разрешения SELinux для этого каталог:   chcon -R -h -t httpd_sys_content_t/path/to/directory *

Моя версия Linux не является Security Enhanced Linux, поэтому без понимания я все равно пробовал: никакого эффекта.

Текущая ситуация

У меня не хватало идей, чтобы попробовать, поэтому были бы очень благодарны любые диагностические вопросы или советы

4b9b3361

Ответ 1

Ссылка, размещенная в разделе "Другие сайты", подчеркивает основную причину вашей проблемы, которая является Selinux.

Если сервер не является частью супербезопасной среды, я бы просто отключил Selinux.

В RedHat/CentOS/Scientific Linux это можно легко сделать, отредактировав /etc/sysconfig/selinux - найдите параметр "selinux" и измените параметр "принудительное исполнение" на "отключено" согласно приведенному ниже фрагменту:

# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=disabled

Возможно, разумно перезагрузить сервер после внесения этого изменения.

Ответ 2

Вы не должны просто отключать SELinux.

Вам нужно установить httpd_enable_homedirs.

yum -y install policycoreutils-python
setsebool -P httpd_enable_homedirs on

Ответ 3

Я столкнулся с этой проблемой и сегодня, потому что я переместил свой DocumentRoot из /var/www/html в/srv/www/html. В рамках наших политик безопасности у нас нет возможности просто отключить SELinux.

SO my fix, как я выяснил, это изменить контекст файла SELinux для /srv для соответствия /var. Компромисс да, но все же лучше, чем полностью отключить его. Кроме этого... Я убедился /srv/www, и все подпапки имели httpd_sys_content_t для соответствия папкам под /var/www, и теперь все хорошо.

Ответ 4

Это в основном тот же ответ, что и у Дэвида, но только немного более ясный, каталог http-обслуживания имеет неправильный набор контекстов безопасности SELinux.

Полное объяснение, чтобы исправить это, здесь http://mybroadband.co.za/vb/showthread.php/588183-Fix-403-Forbidden-on-newly-configured-CentOS-6-5-httpd-server-(or-13-10-Ubuntu-LAMP)

Моя проблема заключалась в том, что я размещал свои веб-сайты в другом каталоге, чем путь documentroot/var/www/, поэтому мне нужно было выполнить третий вариант в приведенной выше ссылке, чтобы исправить. Я установил тот же контекст файла моего/website/каталога, который соответствует файлу /var/www/. Было странно, что более ранние версии CentOS 5.5 не должны были устанавливать/активировать SELinux, потому что у моих других серверов не было проблем с этим, и при запуске ls -Z в командной строке эти папки были "немаркированы".

Я запускаю CentOS 6.5 на AWS с минимальной установки на официальном рынке. Поэтому, когда я запускал команду ls -Z в своих папках, я видел, что ссылка выше показывает как возможную проблему.

Запуск команды chcon исправил мою проблему!

Просто замените html/каталогом, который вы хотите использовать!

chcon -Rv --type = httpd_sys_content_t html/

chcon -Rv --user = system_u html/

На стороне примечания мне также пришлось отключить iptables, чтобы заставить работать маршрутизацию, по умолчанию были показаны пустые страницы.

служба iptables stop

Надеюсь, что это поможет любому, у кого есть такая же проблема.

Ответ 5

Envirnoment: Linux - корневая файловая система на SSD       DocumentRoot на жестком диске и установлен через fstab Перезапуск apache2 после загрузки - без проблем Кажется, это проблема синхронизации, которую apache запускается до завершения монтирования fstab.

Обход проблемы: Определите каталог DocumentRoot в корневой файловой системе с правильным владельцем, группой и разрешениями. Каталог может быть пустым.

Ответ 6

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

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

Таким образом, для символического документа DocumentRoot (давайте укажем фактический полный путь к каталогу как "/media/myDoc" для этого примера), выполните следующие две команды:

semanage fcontext -a -t httpd_sys_content_t "/media/myDoc(/.*)?"

restorecon -R /media/myDoc

Обратите внимание, что полный путь необходим при использовании семантики таким образом. Вы не только устраните проблему, но и не будете снова ломаться, когда вы запустите restorecon (или автоматически-relabel) в будущем.