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

Ошибка 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>/

У меня была аналогичная проблема, которую я долго не мог решить на своем новом сервере. В дополнение к ответу на 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>

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

В связи с этим вопросом я просто понял, почему мой призрак дал мне это 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. Надейтесь, что это поможет другой потерянной душе.

Сначала отключите 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

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

Есть другой способ, по которому символические ссылки могут вас подвести, как я обнаружил в своей ситуации. Если у вас есть система 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.