Apache не будет следовать символическим ссылкам (403 Запрещено)

Ответ 1

Убедитесь, что у Apache есть права выполнения для /root, /root/site и /root/site/about.

Run:

chmod o+x /root /root/site /root/site/about

Ответ 2

Ошибка 403 также может быть вызвана зашифрованной файловой системой, например. символическую ссылку на зашифрованную домашнюю папку.

Если ваша символическая ссылка указывает на зашифрованную папку, пользователь apache (например, www-data) не может получить доступ к содержимому, даже если права доступа apache и файла/папки установлены правильно. Доступ пользователя www-data может быть протестирован с помощью такого вызова:

sudo -u www-data ls -l /var/www/html/<your symlink>/

Существуют обходные пути/решения для этого, например. добавление пользователя www-data в вашу личную группу (предоставляет зашифрованные данные веб-пользователю) или путем настройки незашифрованной rsynced-папки (возможно, довольно безопасной). Я для себя, вероятно, поеду на rsync-решение во время разработки.

https://askubuntu.com/questions/633625/public-folder-in-an-encrypted-home-directory

Удобный инструмент для моих целей - lsyncd. Это позволяет мне работать непосредственно в моей зашифрованной домашней папке и мгновенно видеть изменения на веб-странице apache. Синхронизация инициируется изменениями в файловой системе, вызывая rsync. Поскольку я работаю только на довольно небольших веб-страницах и сценариях, синхронизация выполняется очень быстро. Я решил использовать короткую задержку за 1 секунду до запуска rsync, хотя можно установить задержку в 0 секунд.

Установка lsyncd (в Ubuntu):

sudo apt-get install lsyncd

Запуск службы фона:

lsyncd -delay 1 -rsync /home/<me>/<work folder>/ /var/www/html/<web folder>/

Ответ 3

У меня была похожая проблема, которую я долго не мог решить на моем новом сервере. В дополнение к ответу palacsint, хороший вопрос: вы используете Apache 2.4? В Apache 2.4 есть другой механизм для установки разрешений, которые не работают, когда сделано с помощью вышеупомянутой конфигурации, поэтому я использовал решение , описанное в этом сообщении в блоге.

По сути, мне нужно было конвертировать мой конфигурационный файл из:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    allow from all

</Directory>

в:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Обратите внимание на то, как строки Order и allow были заменены на Требовать все предоставленные

Ответ 4

В связи с этим вопросом я просто понял, почему мой призрак дал мне это 403.

Я испытал ВСЕ возможности по этому вопросу, а другим - без везения. Это почти сводит меня с ума.

Я устанавливаю сервер с развертыванием выпусков, похожим на путь Capistrano через символические ссылки, и когда я пытался получить доступ к папке DocRoot (которая теперь является символической ссылкой на текущую папку выпуска), она дала мне 403.

Мой призрак:

DocumentRoot /var/www/site.com/html
<Directory /var/www/site.com/html>
        AllowOverride All
        Options +FollowSymLinks
        Require all granted
</Directory>

и мой основной файл httpd.conf был (установка Apache 2.4 по умолчанию):

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes -FollowSymLinks -Includes
(...)

Оказывается, основное определение опций имело приоритет над моим vhosts fiel (для меня это счетчик интуитивно понятен). Поэтому я изменил его на:

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes +FollowSymLinks -Includes
(...)

и Эврика! (обратите внимание на знак "плюс" перед "FollowSymLinks" в главном файле httpd.conf. Надейтесь, что это поможет другой потерянной душе.

Ответ 5

Для тех, у кого возникли проблемы после обновления до 14.04 https://askubuntu.com/questions/452042/why-is-my-apache-not-working-after-upgrading-to-ubuntu-14-04 в виде корень изменен перед обновлением =/var/www после обновления =/var/www/html

Ответ 6

Есть другой способ, по которому символические ссылки могут вас подвести, как я обнаружил в своей ситуации. Если у вас есть система SELinux в качестве сервера, а символические ссылки указывают на папку, прикрепленную к NFS (другие файловые системы могут давать похожие симптомы), httpd может видеть неправильные контексты и отказываться от обслуживания содержимого целевых папок.

В моем случае контекст SELinux /var/www/html (который вы можете получить с помощью ls -Z): unconfined_u:object_r:httpd_sys_content_t:s0. Символьные ссылки в /var/www/html будут иметь один и тот же контекст, но их целевой контекст, являющийся папкой, установленной в NFS, system_u:object_r:nfs_t:s0.

Решение состоит в том, чтобы добавить fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 в параметры mount (например, # mount -t nfs -o v3,fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 <IP address>:/<server path> /<mount point>). rootcontext не имеет значения, а defcontext отклоняется NFS. Я сам не пробовал context.

Ответ 7

Сначала отключите selinux (vim/etc/selinux/config)

vim/etc/httpd/conf/httpd.conf редактировать следующие строки для символических ссылок и индексации каталогов:

documentroot /var/www/html
<directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride None
</directory>

Если файл .htaccess, то AllowOverride all