Apache выдает 403 запрещенных ошибки

Хорошо, я ранее настроил два виртуальных хоста, и они отлично работают. они оба содержат простые веб-проекты и отлично работают с http://project1 и http://project2 в браузере.

Во всяком случае, я пришел добавить еще один vhost. Я отредактировал файл / etc / hosts с 127.0.0.1 project3, а также обновил файл httpd-vhosts.conf, скопировав и вставив предыдущие записи для project2 и отредактировав путь к файлу.

Я проверил все права доступа к файлам и папкам (на самом деле я скопировал и вставил их из project2) и просто поместил сообщение «hello world» в файл index.php.

Я получаю сообщение об отказе в разрешении 403 при доступе к http://project3

Почему это так, я просто могу понять, какой шаг я пропустил, поскольку все, кажется, настроено правильно.


person Community    schedule 26.08.2013    source источник
comment
Вы перезапускали Apache?   -  person EmCo    schedule 26.08.2013


Ответы (8)


Проверь это :

  • Apache может физически получить доступ к файлу (пользователь, запустивший apache, возможно, www-data или apache, может получить доступ к файлу в файловой системе)
  • Apache может отображать содержимое папки (разрешение на чтение)
  • В Apache есть директива «Разрешить» для этой папки. Должен быть один для / var / www /, вы можете, например, проверить vhost по умолчанию.

Кроме того, вы можете посмотреть файл error.log (обычно расположенный по адресу /var/log/apache2/error.log), который точно описывает, почему вы получаете ошибку 403.

Наконец, вы можете перезапустить apache, чтобы убедиться, что все настройки применены. Обычно это можно сделать с помощью /etc/init.d/apache2 restart. В некоторых системах сценарий будет называться httpd. Просто выясни.

person blue112    schedule 26.08.2013
comment
хммм, я получаю отказ клиента из-за конфигурации сервера ... какие-нибудь подсказки? спасибо - person ; 26.08.2013
comment
Нет, подождите! Думаю, я понял. Я перезапустил apachectl и, похоже, работает. Не могу поверить, что это было так просто. Спасибо - person ; 26.08.2013
comment
дополнительная часть решила мою проблему, получите фактическую ошибку из журнала ошибок. - person Newbie; 28.05.2020
comment
Мне не хватало разрешающей директивы. Спасибо - person Michael; 16.03.2021
comment
Я не вижу проблем с тем, что указано выше, но все равно получаю сообщение об ошибке. Интересно, что в файле /var/log/apache2/error.log всего две строки. Сначала: ‹дата и время› [mpm_prefork: notice] [pid 2302] и так далее. Второе: ‹дата и время› [ядро: уведомление] [pid 2302] AH00094: Командная строка: и так далее. Где еще мне посмотреть? - person Dennis; 17.07.2021

Я только что исправил эту проблему после нескольких дней борьбы. Вот что у меня сработало:

Сначала проверьте свой error_log файл Apache и просмотрите последнее сообщение об ошибке.

  • Если там написано что-то вроде:

    access to /mySite denied (filesystem path
    '/Users/myusername/Sites/mySite') because search permissions
    are missing on a component of the path
    

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

    $ cd /Users/myusername/Sites/mySite
    $ find . -type f -exec chmod 644 {} \;
    $ find . -type d -exec chmod 755 {} \;
    

    Затем обновите URL-адрес вашего веб-сайта (например, http://localhost/mySite). Если вы по-прежнему получаете ошибку 403, и если ваш Apache error_log по-прежнему говорит то же самое, постепенно перемещайтесь вверх по дереву каталогов, изменяя разрешения каталогов по мере продвижения. Вы можете сделать это из терминала:

    $ cd ..
    $ chmod 755 mySite
    

    При необходимости продолжайте:

    $ cd ..
    $ chmod Sites 
    

    и при необходимости

    $ cd ..
    $ chmod myusername
    

    НЕ поднимайтесь дальше этого. Вы можете серьезно испортить свою систему. Если вы по-прежнему получаете сообщение об ошибке search permissions are missing on a component of the path, я не знаю, что вам делать. Однако я столкнулся с другой ошибкой (приведенной ниже), которую я исправил следующим образом:

  • Если ваш error_log говорит что-то вроде:

    client denied by server configuration:
    /Users/myusername/Sites/mySite
    

    тогда ваша проблема не в правах доступа к файлам, а в конфигурации Apache.

    Обратите внимание, что в вашем httpd.conf файле вы увидите такую ​​конфигурацию по умолчанию (Apache 2.4+):

    <Directory />
        AllowOverride none
        Require all denied
    </Directory>
    

    или так (Apache 2.2):

    <Directory />
      Order deny,allow
      Deny from all
    </Directory>
    

    НЕ меняйте это! Мы не будем отменять эти разрешения глобально, а вместо этого будем использовать ваш httpd-vhosts.conf файл. Однако сначала убедитесь, что ваша строка vhost Include в httpd.conf раскомментирована. Должно получиться вот так. (Ваш точный путь может быть другим.)

    # Virtual hosts
    Include etc/extra/httpd-vhosts.conf
    

    Теперь откройте httpd-vhosts.conf файл, который вы только что Included. Добавьте запись для своей веб-страницы, если у вас ее еще нет. Это должно выглядеть примерно так. Пути DocumentRoot и Directory должны быть идентичными и указывать на то, где находится ваш index.html или index.php файл. Для меня это в подкаталоге public.

    Для Apache 2.2:

    <VirtualHost *:80>
    #     ServerAdmin [email protected]
        DocumentRoot "/Users/myusername/Sites/mySite/public"
        ServerName mysite
    #     ErrorLog "logs/dummy-host2.example.com-error_log"
    #     CustomLog "logs/dummy-host2.example.com-access_log" common
        <Directory "/Users/myusername/Sites/mySite/public">
            Options Indexes FollowSymLinks Includes ExecCGI
            AllowOverride All
            Order allow,deny
            Allow from all
            Require all granted
        </Directory>
    </VirtualHost>
    

    Строки, говорящие

    AllowOverride All
    Require all granted
    

    критичны для Apache 2.4+. Без них вы не сможете изменить настройки Apache по умолчанию, указанные в httpd.conf. Обратите внимание: если вы используете Apache 2.2, в этих строках вместо этого должно быть написано

    Order allow,deny
    Allow from all
    

    Это изменение было основным источником путаницы для гуглеров с этой проблемой, таких как я, потому что копирование этих строк Apache 2.2 не будет работать в Apache 2.4+, а строки Apache 2.2 по-прежнему часто встречаются в старых потоках справки.

    После сохранения изменений перезапустите Apache. Команда для этого будет зависеть от вашей ОС и установки, поэтому погуглите ее отдельно, если вам понадобится помощь.

Надеюсь, это поможет кому-то другому!


PS: Если у вас возникли проблемы с поиском этих .conf файлов, попробуйте выполнить команду find, например:

$ find / -name httpd.conf
person Cameron Hudson    schedule 07.07.2018
comment
Отличный ответ, у меня был конфликт между версиями (я 2.4+), из-за которого клиент отказался из-за ошибки конфигурации сервера. - person Namanyay Goel; 25.07.2018

Команда restorecon работает следующим образом:

restorecon -v -R /var/www/html/
person sangeetha    schedule 23.03.2015
comment
что это должно делать? - person Alexander Mills; 23.05.2019
comment
apt install policycoreutils затем man restorecon, восстановить для файлов контексты безопасности SELinux по умолчанию (-v: показать изменения, -R рекурсивно). - person xinthose; 24.06.2020

однако это не решает проблему, потому что, например, откройте SUSE Tumbleweed, сборка пользовательского исходного кода вызывает ту же ошибку 401 на веб-странице по умолчанию, которая настроена соответствующим образом с помощью индексов и

Require all granted
person Povilas Brilius    schedule 02.11.2020

Серверу может потребоваться разрешение на чтение для вашего домашнего каталога и .htaccess в нем.

person mikemay    schedule 15.12.2013
comment
Как только я создал домашний каталог пользователя /home/username, в нем была папка public_html, исполняемая группой и другими пользователями, используя: chmod 711 /home/username Мне удалось избавиться от ошибки 403. Только подумал, что мне нужны права на выполнение для public_html, поскольку папка внутри него была Webroot, как я понял, прочитав petefreitag .com / item / 793.cfm. Но я был неправ. - person rhand; 20.06.2014

Вы можете попробовать отключить selinux и попробовать еще раз, используя следующую команду

setenforce 0
person S V Aditya    schedule 25.06.2018

В моем случае это не удалось, поскольку IP-адрес моего исходного сервера не был включен в белый список на целевом сервере.

Например, Я пытался получить доступ к https://prodcat.ref.test.co.uk из приложения работает на моем исходном сервере. На исходном сервере найдите IP-адрес с помощью ifconfig

Этот IP-адрес должен быть внесен в белый список в конфигурационном файле apache целевого сервера. Если его нет, то занесите его в белый список.

Шаги по добавлению IP-адреса для внесения в белый список (если вы также управляете целевым сервером) ssh на сервер apache sudo su - cd / usr / local / apache / conf / extra (фактические каталоги могут отличаться в зависимости от вашей конфигурации)

Найдите файл конфигурации для целевого приложения, например, prodcat-443.conf

RewriteCond %{REMOTE_ADDR} <YOUR Server's IP> 
for e.g.
RewriteCond %{REMOTE_ADDR} !^192\.68\.2\.98

Надеюсь, это кому-то поможет

person Sanjay Bharwani    schedule 11.09.2019

Обратите внимание, что другая проблема, которая может быть причиной этого, заключается в том, что параметр FollowSymLinks родительского каталога мог быть ошибочно перезаписан параметрами каталога вашего проекта. Так было со мной, и я тянул за волосы, пока не выяснил причину!

Вот пример такой ошибки:

<Directory />
        Options FollowSymLinks
        AllowOverride all
        Require all denied
</Directory>

<Directory /var/www/>
        Options Indexes # <--- NOT OK! It's overwriting the above option of the "/" directory.
        AllowOverride all
        Require all granted
</Directory>

Итак, теперь, если вы проверите сообщение журнала Apache (tail -n 50 -f /var/www/html/{the_error_log_file_of_your_site}), вы увидите такую ​​ошибку:

Options FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule directive
is also forbidden due to its similar ability to circumvent directory restrictions

Это потому, что Indexes в приведенных выше правилах для каталога /var/www перезаписывает FolowSymLinks каталога /. Итак, теперь, когда вы знаете причину, чтобы исправить ее, вы можете сделать много вещей в зависимости от ваших потребностей. Например:

<Directory />
        Options FollowSymLinks
        AllowOverride all
        Require all denied
</Directory>

<Directory /var/www/>
        Options FollowSymLinks Indexes # <--- OK.
        AllowOverride all
        Require all granted
</Directory>

Или даже это:

<Directory />
        Options FollowSymLinks
        AllowOverride all
        Require all denied
</Directory>

<Directory /var/www/>
        Options -Indexes # <--- OK as well! It will NOT cause an overwrite.
        AllowOverride all
        Require all granted
</Directory>

Приведенный выше пример не вызовет проблемы перезаписи, потому что в Apache, если параметр равен +, он перезапишет только + s, а если это -, он перезапишет -s ... ( Не просите у меня справки по этому поводу, это просто моя интерпретация сообщения об ошибке Apache (проверено через journalctl -xe), в котором говорится: Either all Options must start with + or -, or no Option may., когда у опции есть знак, а у другого нет (например, FollowSymLinks -Indexes) . Итак, это мой личный вывод - поэтому следует воспринимать его с некоторой долей скептицизма - что, если я использовал -Indexes в качестве параметра, он будет рассматриваться Apache как целый отдельный набор параметров по сравнению с другим параметром в /, который не имеет никаких признаков, и поэтому в конце не произойдет никаких раздражающих перезаписей, что я мог бы успешно подтвердить с помощью приведенных выше правил в моем собственном каталоге проекта).

Надеюсь, это поможет вам меньше выдергивать волосы! :)

person aderchox    schedule 21.10.2020