web-dev-qa-db-fra.com

Apache2: 'AH01630: client refusé par la configuration du serveur'

Je reçois cette erreur en essayant d'accéder à localhost via un navigateur.

AH01630: client denied by server configuration

J'ai vérifié les autorisations de mon dossier de site à l'aide de:

Sudo chmod 777 -R *

Voici mon fichier de configuration:

<VirtualHost *:80>
ServerAdmin webmaster@localhost

DocumentRoot /home/user-name/www/myproject
<Directory />
    Options FollowSymLinks
    AllowOverride all
    Allow from all
</Directory>

<Location />
  Allow from all
  Order Deny,Allow
</Location>

<Directory  /home/user-name/www/myproject/>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride all
    Order allow,deny
    Allow from all
</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
    AllowOverride all
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all
</Directory>

ErrorLog ${Apache_LOG_DIR}/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog ${Apache_LOG_DIR}/access.log combined

Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
    Options Indexes MultiViews FollowSymLinks
    AllowOverride all
    Order deny,allow
    Deny from all
    Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
serverapache2apache2.4
410
Hazem Hagrass

Si vous utilisez Apache 2.4

Vous devez vérifier autoriser et refuser les règles

Départ http://httpd.Apache.org/docs/2.4/upgrading.html#access

En 2.2, le contrôle d'accès basé sur le nom d'hôte du client, l'adresse IP et d'autres caractéristiques des demandes du client a été effectué à l'aide des directives Order, Allow, Deny et Satisfy.

En 2.4, ce contrôle d'accès est effectué de la même manière que les autres contrôles d'autorisation, à l'aide du nouveau module mod_authz_Host.

La nouvelle directive est Require :

2.2 configuration:

Order allow,deny
Allow from all

2.4 configuration:

Require all granted

N'oubliez pas non plus de redémarrer le serveur Apache après ces modifications (# service httpd restart)

742
Jayakumar Bellie

Pour tous les répertoires, écrivez Require all granted au lieu de Allow from all Something like

Mise à jour

Si ce qui précède ne fonctionne pas, supprimez également la ligne mentionnée ci-dessous:

Ordre permettre, refuser

297
valera5505

Vérifiez à nouveau que le chemin d'accès à DocumentRoot est correct. Cela peut causer cette erreur.

32
Tim

J'ai apporté les mêmes modifications que ravisorg a suggéré à OSX 10.10 Yosemite de mettre à niveau Apache vers la version 2.4. Vous trouverez ci-dessous les modifications apportées à http.conf.

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

<Directory /Volumes/Data/Data/USER/Sites/>
    AllowOverride none
    Require all granted
</Directory>
21
K.M.

Cela me rendit absolument fou pendant un jour et demi, mais je trouvai une solution si toutes les autres solutions avaient été essayées sans succès.

Ceci est pour macOS.

  • Aller au moniteur d'activité (recherche spotlight pour: activité)
  • Dans Activity Monitor, recherchez httpd, qui est le service Apache.
  • Sélectionnez celui qui appartient à root et cliquez sur X en haut à gauche pour le fermer.

À ce stade, j'ai immédiatement cessé de recevoir 403 erreurs et tout a commencé à fonctionner comme prévu. Ce qui est bizarre, c’est que je n’avais même pas besoin de redémarrer Apache cela fonctionnait, j’imagine qu’il a redémarré lorsque j’ai été chez mon hôte local, honnêtement, je ne sais pas, mais je suppose que le problème est qu’Apache ne redémarre pas réellement avec Apachectl restart, ou arrêter ou commencer. J'espère que ça aide quelqu'un.

11
RAC

Le problème est dans VirtualHost mais n'est probablement pas

Exiger tout accordé

Confirmez votre config est correct, voici un exemple correct enter image description here

7
Albert.Qing

Je me suis résolu après avoir passé quelques heures.

J'ai installé Apache/2.4.7 (Ubuntu) via coookbook dans vagrant vm.

Le fichier /etc/Apache2/Apache2.conf n'a pas d'élément <VirtualHost *:80> par défaut.

J'ai fait deux changements pour y arriver

  1. ajouté <VirtualHost *:80>
  2. ajoutée
    Options Index FollowSymLinks
    AllowOverride all
    Permettre à tous

puis finalement je viens de démarrer vm ..

4
Giri Babu

Si vous réduisez le journal des erreurs et rechargez la page, vous devriez voir plus d’informations sur le problème exact.

Saisissez les variables d'environnement pour que $ {Apache_LOG_DIR} fonctionne réellement ...

source /etc/Apache2/envvars

Alors queue et regarde ...

tail -f ${Apache_LOG_DIR}/error.log
4
Shylo Hana

Est-ce que quelqu'un a pensé à ce serveur wamp par défaut d'inclure le fichier httpd-vhosts.conf? Mon approche est de supprimer la note ci-dessous

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

dans le fichier httpd.conf. C'est tout.

4
Heier

dans mon cas,

j'utilise macOS Mojave (Apache/2.4.34). Un problème est survenu dans les paramètres de l'hôte virtuel dans le fichier /etc/Apache2/extra/httpd-vhosts.conf. après avoir ajouté la balise de répertoire requise, mon problème avait disparu.

Exiger tout accordé

J'espère que la structure de configuration complète de l'hôte virtuel vous sauvera.

<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>

tout ce que vous avez à faire est de remplacer le MainProjectFolderName par votre exact ProjectFolderName.

4
sh6210

Si vous utilisez Apache 2.4 dans WampServer sous Windows OS.

Vous devez ouvrir le fichier https-vhosts.conf dans le bloc-notes.

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

Si vous ne parvenez pas à trouver le fichier ci-dessus. vérifier la capture d'écran ci-dessous Wampserver apacche 2.4 httpd-vhosts

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

Dans le code ci-dessus, remplacez

Require local

avec

Require all granted

Et enregistrez-le. Redémarrez le service Apache et réessayez.

2
Dev Semicolon

Cela me rendait fou. Finalement, j'ai compris quel était le problème: j’utilisais des chemins directs pour le journal des erreurs et ils avaient tort.

Pourquoi Apache envoie-t-il un message d'erreur vague (et erroné)? À la place, utilisez un message d'erreur correct et utile, tel que: Le chemin d'accès à la directive ErrorLog "/wrong/path/and/filename.log" n'est pas valide.

Quoi qu'il en soit, pour résoudre ce problème, assurez-vous que vos directives de journal des erreurs ressemblent à ceci:

ErrorLog ${Apache_LOG_DIR}/error.log
CustomLog ${Apache_LOG_DIR}/access.log combined
2
RyanNerd

Si vous avez un hôte https, n'oubliez pas de modifier également Require all granted pour la configuration ssl.

De plus, il est parfois utile de vérifier les autorisations en tant qu'utilisateur 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
1
Putnik

Assurez-vous que toutes les configurations spécifiques à l'utilisateur sont incluses!

Si aucune des autres réponses sur cette page ne vous convient, voici ce que j'ai rencontré après des heures passées à patauger.

J'ai utilisé des configurations spécifiques à l'utilisateur, avec Sites spécifié comme étant mon UserDir dans /private/etc/Apache2/extra/httpd-userdir.conf. Cependant, l'accès au système d'extrémité http://localhost/~jwork/ m'a été interdit.

Je pouvais voir dans /var/log/Apache2/error_log que l'accès à /Users/jwork/Sites/ était bloqué. Cependant, j'ai été autorisé à accéder à DocumentRoot, via http://localhost/. Cela suggérait que je n'avais pas le droit de voir l'utilisateur ~jwork. Mais pour autant que je puisse en juger par ps aux | egrep '(Apache|httpd)' et lsof -i :80, Apache s'exécutait pour l'utilisateur jwork, donc quelque chose n'était clairement pas en écriture avec ma configuration utilisateur.

Avec un utilisateur nommé jwork, voici mon fichier de configuration:

/private/etc/Apache2/users/jwork.conf

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

Cette config est parfaitement valide. Cependant, j'ai constaté que ma configuration utilisateur n'était pas incluse:

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

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

Notez qu'il s'agit du chemin d'accès par défaut au fichier de configuration userdir, mais comme vous le verrez ci-dessous, il est configurable dans httpd.conf. Assurez-vous que les lignes suivantes sont activées:

/private/etc/Apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/Apache2/mod_userdir.so
1
Jamie Birch

Pour Wamp 3 (Apache 2.4), en plus de mettre le serveur en ligne comme décrit dans les autres réponses, dans le fichier Virtual Hosts conf/extra/httpd-vhosts.conf
vous devrez peut-être remplacer

Require local

avec

Require all granted



Ceci est applicable si dans httpd.conf vous avez

Include conf/extra/httpd-vhosts.conf
1
Alex Pandrea

Pour ceux qui sont bloqués par cette erreur comme moi et que rien n’a aidé d’en haut: vérifiez si le dossier problématique de error.log existe réellement sur votre serveur. Le mien a été généré automatiquement par Django au mauvais endroit (il a été manipulé avec une racine statique, puis manage.py collectstatic). Je ne sais pas pourquoi on ne peut pas nommer les erreurs correctement.

0
Dmitry

J'ai en fait résolu celui-ci en ajoutant le répertoire d'accès à l'entrée: 80.

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

Avant que tout le monde ne reçoive toute la "sécurité" sur moi, dans certaines circonstances, il ne s'agit pas d'un problème de sécurité.

Si vous utilisez une ressource distante, je vous conseillerais plutôt de vous assurer que votre demande CURL passe par HTTPS/TLS, puis cette entrée de répertoire se trouve sur le port 443.

0
AdheneManx

Lorsque vous utilisez Ubuntu, vérifiez si le module CGI est activé. Si non:

Sudo a2enmod cgi
0
hfmanson

Outre les directives manquantes Order et Allow mentionnées dans d'autres réponses, sachez qu'une expression régulière non concordante d'une directive DirectoryMatch peut également être à l'origine de cette erreur.

Si le chemin demandé est /home/user-foo1bar/www/myproject/, le matcher suivant ne correspondra pas

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

ainsi, même une configuration d'accès valide peut provoquer cette erreur.

0
try-catch-finally

Une cause obscure (qui vient juste d’être traitée), et pourtant possible, est une règle interne de mod_rewrite, dans le fichier de configuration principal (pas .htaccess) qui écrit dans un chemin qui existe à la racine du système de fichiers du serveur. Supposons que vous ayez un répertoire /media sur votre site et que vous réécriviez quelque chose comme ceci:

RewriteRule /some_image.png /media/some_other_location.png

Si vous avez un répertoire /media à la racine de votre serveur, la réécriture sera tentée de la sorte (ce qui entraînera une erreur d'accès refusé) plutôt que celle du répertoire de votre site, car la racine du système de fichiers est d'abord vérifiée par mod_rewrite, pour l'existence du premier répertoire du chemin, avant le répertoire de votre site.

0
Nigel B. Peck

J'en ai un autre qui peut être utile à quelqu'un. A reçu le même message d'erreur après la mise à niveau de PHP 5.6 => 7.0. Nous avions modifié les paramètres de téléchargement PHP et nous avions oublié de les modifier une fois copiés. Même si je ne téléchargeais pas d’images à l’époque, Silverstripe (notre CMS) refusait de sauvegarder et jetait cette erreur. Augmentation de la taille de téléchargement de l'image et cela a fonctionné immédiatement.

0
Andrew MacNaughton

Le problème peut être que la directive ne se trouve pas sous <Directory>

https://httpd.Apache.org/docs/2.4/mod/mod_authz_Host.html#requiredirectives

La directive peut être référencée dans une section <Directory>, <Files> ou <Location> ainsi que dans des fichiers .htaccess pour contrôler l'accès à des parties particulières du serveur. L'accès peut être contrôlé en fonction du nom d'hôte ou de l'adresse IP du client.

0
Sérgio

Au cas où cela aiderait quelqu'un à googler comme moi, ce message d'erreur tentait d'accéder à un fichier SVG sur mon serveur, par exemple. https://example.com/images/file.svg . Les autres types de fichiers semblaient bien, juste SVG échouaient.

J'ai cherché tous les fichiers /etc/httpd conf et vérifié tous les types de configuration require all denied, mais je ne trouvais pas quelle configuration avait cet effet.

J'ai tourné LogLevel pour déboguer dans la configuration VirtualHost et j'ai pu voir la journalisation mod_authz_core spécifiant qu'il y avait un "Exiger tout refusé":

[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

Grâce à des tests à l'aveugle, j'ai déplacé le fichier à la racine de la racine Web et découvert que je pouvais y accéder à partir de https://example.com/file.svg .., de sorte qu'il n'a échoué que dans ' dossier des images. Cela m'a conduit à un fichier .htaccess dans le dossier des images dont je n'avais aucune idée.

Il s'avère que Zen Cart 1.5 est livré avec un fichier images/.htaccess qui contient:

# 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>

Cela était très agaçant et j'espère que cela pourrait rappeler aux autres de vérifier les fichiers .htaccess à tous les niveaux du système de fichiers, ce qui entraîne des problèmes. accéder au cas où il y aurait ce genre de sottise.

0
Neek