Ответ 1

Если вы используете Apache 2.4

Вы должны проверить разрешить и запретить правила

Отъезд http://httpd.apache.org/docs/2.4/upgrading.html#access

В 2.2, управление доступом на основе имени хоста клиента, IP-адреса и других характеристики запросов клиентов выполнялись с использованием директив Заказ, Разрешить, Отклонить и Удовлетворить.

В 2.4 такое управление доступом осуществляется так же, как и другое авторизации, используя новый модуль mod_authz_host.

Новая директива Require:

2.2 конфигурация:

Order allow,deny
Allow from all

2.4 конфигурация:

Require all granted

Также не забудьте перезапустить сервер apache после этих изменений (# service httpd restart)

Ответ 2

Для всех каталогов пишите Require all granted вместо Allow from all

Обновление

Если вышеуказанное не работает, также удалите эту ниже указанную строку:

Разрешить заказ, deny

Ответ 3

Дважды проверьте правильность пути DocumentRoot. Это может вызвать эту ошибку.

Ответ 4

Я внес те же изменения, что ravisorg предложил OSX 10.10 Yosemite, который обновляет Apache до версии 2.4. Ниже перечислены изменения, которые были добавлены в http.conf.

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

<Directory /Volumes/Data/Data/USER/Sites/>
    AllowOverride none
    Require all granted
</Directory>

Ответ 5

Это сводило меня с ума в течение полутора дней, но я нашел решение, если все другие решения были испробованы безуспешно.

Это для macOS.

• Перейти к Монитору активности (поиск внимания: активность)
• В мониторе активности ищите httpd, который является сервисом Apache
• Выберите тот, который принадлежит root и нажмите X в левом верхнем углу, чтобы закрыть его.

В этот момент я сразу перестал получать ошибки 403, и все начало работать как ожидалось. Странно то, что мне даже не нужно было перезапускать Apache, он просто работал, я думаю, он перезапустился сам, когда я перешел на мой локальный хост, я, честно говоря, не знаю, но я предполагаю, что проблема в том, что Apache фактически не перезапускается при использовании apachectl restart, или остановить или начать. Надеюсь, это кому-нибудь поможет.

Ответ 6

Проблема в VirtualHost, но, вероятно, нет

Требовать все предоставленное

Подтвердите, что ваш конфиг правильный, вот правильный пример

Ответ 7

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

Возьмите переменные окружения, поэтому ${APACHE_LOG_DIR} будет работать...

source /etc/apache2/envvars

Затем хвост и часы...

tail -f ${APACHE_LOG_DIR}/error.log

Ответ 8

Я покончил с собой, проведя пару часов.

Я установил Apache/2.4.7 (Ubuntu) через coookbook в vagrant vm.

/etc/apache2/apache2.conf по умолчанию не имеет элемента <VirtualHost *:80>.

Я сделал два изменения, чтобы сделать это

• добавлен <VirtualHost *:80>
• добавлен
  Параметры индексов FollowSymLinks
  AllowOverride all
  Разрешить все

тогда, наконец, я только что загрузил vm..

Ответ 9

Кто-нибудь думал о том, что по умолчанию сервер Wamp не включает файл httpd-vhosts.conf. Мой подход заключается в том, чтобы удалить примечание ниже

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

в httpd.conf файле. Это все.

Ответ 10

в моем случае,

Я использую MacOS Mojave (Apache/2.4.34). Возникла проблема с настройками виртуального хоста в файле /etc/apache2/extra/httpd-vhosts.conf. после добавления необходимого тега каталога моя проблема исчезла.

Требовать все предоставленное

Надеюсь, что полная структура установки виртуального хоста спасет вас.

<VirtualHost *:80>
    DocumentRoot "/Users/vagabond/Sites/MainProjectFolderName/public/"
    ServerName project.loc

    <Directory /Users/vagabond/Sites/MainProjectFolderName/public/>
        Require all granted
    </Directory>

    ErrorLog "/Users/vagabond/Sites/logs/MainProjectFolderName.loc-error_log"
    CustomLog "/Users/vagabond/Sites/logs/MainProjectFolderName.loc-access_log" common
</VirtualHost>

все, что вам нужно сделать, заменить MainProjectFolderName на точное ProjectFolderName.

Ответ 11

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

Почему Apache дает неопределенное (и неправильное) сообщение об ошибке? Вместо этого используйте правильное и полезное сообщение об ошибке вроде: Path for ErrorLog "/wrong/path/and/filename.log" недействительно.

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

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

Ответ 12

Если вы используете Apache 2.4 в WampServer на ОС Windows.

Вам нужно открыть файл https-vhosts.conf в блокноте.

C:\wamp64\bin\apache\apache2.4.37\conf\extra\https-vhosts.conf 

Если вы не можете найти вышеуказанный файл. проверьте скриншот ниже

 <VirtualHost *:80>
     ServerName localhost
     DocumentRoot c:/wamp64/www
     <Directory  "c:/wamp64/www/">
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Require local
    </Directory>
</VirtualHost>

В приведенном выше коде заменить

Require local

с

Require all granted

И сохрани это. Перезапустите службу Apache и попробуйте снова.

Ответ 13

Если у вас есть хост https, не забудьте также сделать изменения Require all granted для конфигурации ssl.

Кроме того, иногда полезно проверять разрешения как пользователя apache:

# ps -eFH | grep http # get the username used by httpd
...
apache   18837  2692  0 119996 9328   9 10:33 ?        00:00:00     /usr/sbin/httpd -DFOREGROUND
# su -s/bin/bash apache # switch to that user
bash-4.2$ whoami
apache
bash-4.2$ cd /home
bash-4.2$ ls
bash-4.2$ cd mysite.com
bash-4.2$ ls
bash-4.2$ cat file-which-does-not-work.txt

Ответ 14

Для Wamp 3 (Apache 2.4), помимо отправки сервера в режиме онлайн, как описано в других ответах, в файле виртуальных хостов conf/extra/httpd-vhosts.conf
вам может потребоваться заменить

Require local

с

Require all granted

Это применимо, если в httpd.conf у вас есть

Include conf/extra/httpd-vhosts.conf

Ответ 15

Убедитесь, что все пользовательские конфигурации включены!

Если ни один из других ответов на этой странице для вас не сработает, вот то, с чем я столкнулся после нескольких часов барахтения.

Я использовал пользовательские конфигурации, при этом Sites указывались в качестве моего UserDir в /private/etc/apache2/extra/httpd-userdir.conf. Однако мне был запрещен доступ к конечной точке http://localhost/~jwork/.

В /var/log/apache2/error_log я видел, что доступ к /Users/jwork/Sites/ был заблокирован. Однако мне было разрешено получить доступ к DocumentRoot через http://localhost/. Это ~jwork о том, что у меня не было прав на просмотр ~jwork пользователя. Но насколько я мог судить по ps aux | egrep '(apache|httpd)' ps aux | egrep '(apache|httpd)' и lsof -i :80, Apache работал для пользователя jwork, поэтому что-то явно не было jwork с моей пользовательской конфигурацией.

Учитывая пользователя с именем jwork, вот мой файл конфигурации:

/private/etc/apache2/users/jwork.conf

<Directory "/Users/jwork/Sites/">
    Require all granted
</Directory>

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

/private/etc/apache2/extra/httpd-userdir.conf

## Note how it commented out by default.
## Just remove the comment to enable your user conf.
#Include /private/etc/apache2/users/*.conf

Обратите внимание, что это путь по умолчанию к файлу userdir conf, но, как вы увидите ниже, он настраивается в httpd.conf. Убедитесь, что включены следующие строки:

/private/etc/apache2/httpd.conf

Include /private/etc/apache2/extra/httpd-userdir.conf

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so

Ответ 16

Помимо отсутствующих директив Order и Allow, упомянутых в других ответах, следует помнить, что неправильное регулярное выражение директивы DirectoryMatch также может вызвать эту ошибку.

Если запрошенный путь /home/user-foo1bar/www/myproject/, следующий совпадение не будет соответствовать

<DirectoryMatch "/home/user-[a-z]+/www/myproject/">
...
</DirectoryMatch>

таким образом, даже допустимая конфигурация доступа может вызвать эту ошибку.

Ответ 17

Одной неясной (только что с ней разбирающейся), но все же возможной, причиной этого является внутреннее правило mod_rewrite в основном файле конфигурации (не .htaccess), которое записывает путь, который существует в корне файловой системы сервера. Скажем, у вас есть каталог /media на вашем сайте, и вы переписываете что-то вроде этого:

RewriteRule /some_image.png /media/some_other_location.png

Если у вас есть каталог /media в корне вашего сервера, попытка перезаписи на него будет выполнена (что приведет к ошибке отказа в доступе), а не в каталоге вашего сайта, так как корень файловой системы сначала проверяется mod_rewrite, для существование первого каталога в пути, перед каталогом вашего сайта.

Ответ 18

Проблема может заключаться в том, что директива не находится в <Directory>

https://httpd.apache.org/docs/2.4/mod/mod_authz_host.html#requiredirectives

На директиву можно ссылаться в разделе <Directory>, <Files> или <Location>, а также в файлах .htaccess для управления доступом к определенным частям сервера. Доступ можно контролировать на основе имени хоста клиента или IP-адреса.

Ответ 19

У меня есть еще один, который может быть полезен для кого-то. Получал то же сообщение об ошибке после обновления с PHP 5.6 => 7.0. Мы изменили настройки загрузки PHP и забыли изменить их после копирования. Несмотря на то, что я не загружал изображения в то время, Silverstripe (наша CMS) отказывалась сохранять и выдавала эту ошибку. Увеличен размер загружаемого изображения, и это сработало сразу.

Ответ 20

При использовании Ubuntu проверьте, включен ли модуль CGI. Если не:

sudo a2enmod cgi

Ответ 21

Для тех, кто застрял на этой ошибке, как я, и ничто не помогло сверху: проверьте, действительно ли на вашем сервере существует проблемная папка из error.log. Мой файл был автоматически сгенерирован Django в неправильном месте (был сбит статическим корнем, затем manage.py collectstatic). Понятия не имею, почему нельзя правильно назвать ошибки.

Ответ 22

На случай, если это поможет кому-нибудь, как я, погуглить, у меня появилось это сообщение об ошибке при попытке получить доступ к файлу SVG на моем сервере, например, https://example.com/images/file.svg. Другие типы файлов казались хорошими, только SVG терпели неудачу.

Я искал файлы /etc/httpd conf и проверял каждый require all denied тип конфигурации, который require all denied, и просто не мог найти, какой конфиг имел такой эффект.

Я включил LogLevel для отладки в конфигурации VirtualHost и смог увидеть запись в журнале mod_authz_core, указывающую, что действует "Требовать все отказано":

[Mon Jun 10 13:09:54.321022 2019] [authz_core:debug] [pid 23459:tid 140576341206784] mod_authz_core.c(817): [client 127.0.0.1:54626] AH01626: authorization result of Require all denied: denied
[Mon Jun 10 13:09:54.321038 2019] [authz_core:debug] [pid 23459:tid 140576341206784] mod_authz_core.c(817): [client 127.0.0.1:54626] AH01626: authorization result of <RequireAny>: denied
[Mon Jun 10 13:09:54.321082 2019] [authz_core:error] [pid 23459:tid 140576341206784] [client 127.0.0.1:54626] AH01630: client denied by server configuration: /home/blah/htdocs/images/file.svg

В ходе слепого тестирования я переместил файл в корень корневого веб-каталога и обнаружил, что могу получить к нему доступ по адресу https://example.com/file.svg.., поэтому он не удалось открыть только в папке "images". Это привело меня к файлу .htaccess в папке с изображениями, о котором я даже не подозревал.

Оказывается, Zen Cart 1.5 поставляется с файлом images/.htaccess, который имеет:

# deny *everything*
 <FilesMatch ".*">
   <IfModule mod_authz_core.c>
     Require all denied
   </IfModule>
   <IfModule !mod_authz_core.c>
     Order Allow,Deny
     Deny from all
   </IfModule>
 </FilesMatch>

 # but now allow just *certain* necessary files:
 <FilesMatch "(?i).*\.(jpe?g|gif|webp|png|swf)$" >
   <IfModule mod_authz_core.c>
     Require all granted
   </IfModule>
   <IfModule !mod_authz_core.c>
     Order Allow,Deny
     Allow from all
   </IfModule>
 </FilesMatch>

Это было очень раздражающим, и я надеюсь, что это может напомнить другим, чтобы они проверяли файлы .htaccess на каждом уровне файловой системы, приводя к файлу, к которому у вас возникли проблемы с доступом в случае, если происходит такая глупость.

Ответ 23

На самом деле я решил эту проблему, добавив доступ к каталогу к записи: 80.

 <Directory "c:/whatever-directory-you-use/">
    AllowOverride All
    Require all granted
</Directory>

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

Если вы используете удаленный ресурс, я бы порекомендовал вместо этого убедиться, что ваш запрос CURL проходит через HTTPS/TLS, тогда эта запись каталога идет через порт 443.