Apache2: 'AH01630: client denied by server configuration"

Si vous utilisez Apache 2.4

Vous devez cochez la case autoriser et refuser les règles

Découvrez 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 du client, de la demande a été faite en utilisant les directives
Ordonnance, Autoriser, Refuser, et à Satisfaire.

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

La nouvelle directive est Besoin:

2.2 configuration:

Order allow,deny
Allow from all

2.4 configuration:

Require all granted

Aussi, ne pas oublier de redémarrer le serveur apache après ces changements (# service httpd restart)

Vérifiez que le DocumentRoot chemin d'accès est correct. Qui peut provoquer cette erreur.

Ce qui m'a poussé absolument fou pour un jour et demi, mais j'ai trouvé une solution, si toutes les autres solutions ont été essayées sans succès.

C'est pour macOS.

• Aller au Moniteur d'activité (recherche spotlight pour: activité)
• Dans le moniteur d'activité de recherche pour httpd qui est le service Apache
• Sélectionnez l'une qui appartient à root et cliquez sur X dans le coin supérieur gauche de la fermer.

À ce point, j'ai immédiatement arrêté l'obtention d'erreurs 403, et tout a commencé à travailler comme prévu. Bizarre, c'est que je n'ai même pas de redémarrer apache juste que cela fonctionne, je suppose que c'redémarré lui-même, quand je suis allé à mon localhost, honnêtement, je ne sais pas, mais je crois que le problème est Apache effectivement pas de redémarrage lors de l'utilisation de apachectl restart, ou d'arrêter ou de démarrer. Espérons que cela aide quelqu'un.

Si vous queue le journal des erreurs et de recharger la page, vous devriez voir quelques plus d'informations sur le problème exact.

Saisir les variables d'environnement et donc ${APACHE_LOG_DIR} sera effectivement le travail...

source /etc/apache2/envvars

Alors la queue et de regarder...

tail -f ${APACHE_LOG_DIR}/error.log

Quelqu'un a pensé que wamp server par défaut incluent pas les httpd-vhosts.conf fichier.
Mon approche est de supprimer la note ci-dessous

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

dans httpd.conf fichier.
C'est tout.

Cela a été me rend fou. Enfin compris quel était le problème:
J'ai été en utilisant des chemins d'accès direct pour le journal des erreurs et qu'ils ont eu tort.

Pourquoi Apache donner une vague (et faux) message d'erreur? Au lieu d'utiliser un juste et utile de message d'erreur du type: Chemin d'accès à la directive ErrorLog "/mauvais/chemin/et/filename.journal" n'est pas valide.

De toute façon, pour fixer assurez-vous que votre journal d'erreur directives ressembler à quelque chose comme ceci:

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

Si vous avez https hôte, alors n'oubliez pas de faire Require all granted changements de configuration ssl trop.

Aussi, il est parfois utile de vérifier les autorisations que l'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

S'assurer que tout utilisateur spécifique configs sont inclus!

Si aucune des autres réponses sur cette page pour vous le travail, voici ce que j'ai couru dans la après des heures de la patte autour de.

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

J'ai pu voir dans /var/log/apache2/error_log que l'accès à /Users/jwork/Sites/ a été bloqué. Cependant, j'ai été autorisé à accéder à la racine de votre serveur, via http://localhost/. Cela suggère que je n'ai pas les droits pour afficher l' ~jwork de l'utilisateur. Mais autant que je pourrais dire par ps aux | egrep '(apache|httpd)' et lsof -i :80, Apache a été en cours d'exécution pour la jwork utilisateur, de sorte que quelque chose est clairement pas écrire avec ma configuration de l'utilisateur.

Donné un utilisateur nommé jwork, voici mon fichier de config:

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

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

Cette config est parfaitement valide. Cependant, j'ai trouvé que ma configuration de l'utilisateur n'a pas été inclus:

/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

Noter que c'est le chemin d'accès par défaut pour le répertoire utilisateur fichier conf, mais comme vous le verrez ci-dessous, il est configurable dans httpd.conf. S'assurer 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

Une obscure (juste après avoir traité avec lui), encore possible, à cause de ce qui est interne mod_rewrite règle, dans le fichier de configuration principal (pas d' .htaccess) qui écrit dans un chemin qui existe à la racine du système de fichiers du serveur. Disons que vous avez un /media répertoire de votre site, et vous réécrire quelque chose comme ceci:

RewriteRule /some_image.png /media/some_other_location.png

Si vous avez un /media répertoire à la racine de votre serveur, la réécriture sera tenté de qui (résultant dans l'erreur accès refusé) plutôt que celui de votre répertoire site, depuis le système de fichiers racine est d'abord vérifié par mod_rewrite, l'existence du premier répertoire dans le chemin, avant que votre site d'annuaire.

J'ai eu un autre qui peut être utile à quelqu'un.
De recevoir le même message d'erreur après la mise à niveau à partir de PHP 5.6 => 7.0. Nous avons changé la PHP paramètres de téléchargement, et j'ai oublié de changer une fois copiées.
Même si je n'étais pas le téléchargement d'images à l'époque, Silverstripe (CMS) a refusé de l'enregistrer et de le jeter en erreur. Augmentation de l'image taille de téléchargement et cela a fonctionné tout de suite.

Pour ceux qui ont adhéré à cette erreur que moi, et rien n'a aidé à partir de ci-dessus: vérifiez si le dossier de problème d'erreur.journal existe réellement sur votre serveur. Le mien a été généré automatiquement par Django au mauvais endroit (a été sali avec de la racine statique, puis manage.py collectstatic). N'ai aucune idée de pourquoi on peut pas les erreurs de nom correctement.