Apache2: 'AH01630: cliente denegado por la configuración del servidor'

429

Recibo este error cuando intento acceder a localhost a través de un navegador.

AH01630: client denied by server configuration

Verifiqué los permisos de la carpeta de mi sitio usando:

sudo chmod 777 -R *

Aquí está mi archivo de configuración:

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

Hazem Hagrass
fuente
1
¿Estás utilizando el nuevo Apache 2.4? ¿Qué camino da ese error?
aadel
12
Parece que necesita actualizar sus configuraciones. Eche un vistazo aquí: httpd.apache.org/docs/2.4/upgrading.html#run-time
aadel
55
Eche un vistazo a esto: dabase.com/blog/AH01630:_client_denied_by_server_configuration
Christian Müller el
77
chmod 777es un hábito muy malo, incluso (supuestamente) solo se usa en ejemplos.
Antonis Christofides
3
chmod 777 nunca es la respuesta.
Aaron McMillin

Respuestas:

770

Si está usando Apache 2.4

Tienes que marcar permitir y denegar reglas

Consulte http://httpd.apache.org/docs/2.4/upgrading.html#access

En 2.2, el control de acceso basado en el nombre de host del cliente, la dirección IP y otras características de las solicitudes del cliente se realizó utilizando las directivas Order, Allow, Deny y Satisfy.

En 2.4, dicho control de acceso se realiza de la misma manera que otras comprobaciones de autorización, utilizando el nuevo módulo mod_authz_host.

La nueva directiva es Requerir :

2.2 configuración:

Order allow,deny
Allow from all

2.4 configuración:

Require all granted

Además, no olvide reiniciar el servidor apache después de estos cambios ( # service httpd restart)

Jayakumar Bellie
fuente
2
Obras de OSX 10.10 Yosemite usando Apache 2.4
Matthew Herbst
2
Configuración de qué (es decir, ¿a dónde va "Requerir todo otorgado"? ¿En algún archivo .conf?)
Alexis
1
@Alexis directorio (o ubicación). Ver captura de pantalla en la siguiente respuesta.
extraño hombre
2
En mi caso tengo error en DocumentRooty <Directory>caminos.
Roman Grinyov
44
Una cosa a tener en cuenta: si está refiriendo una configuración en línea, es probable que hayan utilizado ambos Order allow,deny ...y Require all granted. No va a funcionar Debe ser solo uno de estos dependiendo de su versión. Eso es lo que me impedía resolver mi problema al principio.
Vishnu Narang
299

Para todos los directorios, escriba en Require all grantedlugar deAllow from all Algo como

Actualizar

Si lo anterior no funciona, también elimine esta línea mencionada a continuación:

Orden permitir, negar

valera5505
fuente
14
Funcionó para mí una vez que también había eliminado la Order allow,denylínea.
kasperd
Atención: durante el uso de HTTPS , la configuración de un host virtual para el puerto 443 , que tenía que repetir las mismas configuraciones <Location /media> Require all granted </Location>en default-ssl.confmi CSS para ser cargado. (Mi problema era que la página de inicio de sesión era accesible, pero no se cargaron CSS ni otros archivos multimedia ...)
yuric
1
Obras de OSX 10.10 Yosemite usando Apache 2.4
Matthew Herbst
77
¿Soy el único que lo ODIA cuando alguien rompe las configuraciones de Apache sin ningún resultado en el registro? (Hola chicos, Allow from Allha sido retirado porque ... razones ...)
Warren P
Gracias, la eliminación de "Permitir pedido, denegar" ayudó
srvy
34

Verifique que la ruta de DocumentRoot sea correcta. Eso puede causar este error.

Tim
fuente
3
Más específicamente, descubrí que este era mi problema porque no tenía una barra inclinada final en mi declaración de DocumentRoot, pero usé una en el <Directory>bloque. También tuve algunas diferencias de casos. Una vez que hice copias de estos dos valores al carbón (sin la barra inclinada), funcionó perfectamente.
Adam Tuttle
Si ese es el caso (sí, también sucedió aquí ...) puede encontrar la siguiente línea en apache/logs/error.log:AH00112: Warning: DocumentRoot [E:/xampp/htdocs/website/frontend/web] does not exist
Piemol
No puedo creer que pueda encontrar respuestas para mis errores tipográficos también :-) Gracias por mencionarlo, mi problema fue la ruta no válida en mi archivo de configuración.
Taher
21

Hice los mismos cambios que ravisorg sugirió a OSX 10.10 Yosemite que actualiza Apache a la versión 2.4. A continuación se muestran los cambios que se agregaron a http.conf.

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

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

Esto me volvió completamente loco por un día y medio, pero encontré una solución si todas las demás soluciones se han probado sin éxito.

Esto es para macOS.

  • Vaya a Monitor de actividad (búsqueda destacada de: actividad)
  • En el monitor de actividad, busque httpd, que es el servicio Apache
  • Seleccione el que pertenece a la raíz y haga clic en X en la esquina superior izquierda para cerrarlo.

En ese momento, dejé de recibir inmediatamente 403 errores y todo comenzó a funcionar como se esperaba. Lo extraño es que ni siquiera tuve que reiniciar Apache, simplemente funcionó, supongo que se reinició solo cuando fui a mi servidor local, honestamente no lo sé, pero supongo que el problema es que Apache no se reinicia realmente cuando se usa Apachectl restart, o detenerse o comenzar. Espero que esto ayude a alguien.

RAC
fuente
1
Después de horas de tiempo perdido, esto es lo que también resolvió mis problemas.
ever.wakeful
10

El problema está en VirtualHost pero probablemente no

Requerir todo otorgado

Confirme que su configuración es correcta, aquí está la muestra correcta ingrese la descripción de la imagen aquí

Albert.Qing
fuente
Incluir las <Directory ...> ... </Directory>líneas funcionó para mí ya que estaba usando una ruta de directorio que no estaba definida previamente en las configuraciones de Apache antes.
Don Wilson
4

Si sigue el registro de errores y vuelve a cargar la página, debería ver más información sobre el problema exacto.

Tome las variables de entorno para que $ {APACHE_LOG_DIR} realmente funcione ...

source /etc/apache2/envvars

Luego cola y mira ...

tail -f ${APACHE_LOG_DIR}/error.log
Shylo Hana
fuente
66
Este es el error de los registros: 'AH01630: cliente denegado por la configuración del servidor'
Hazem Hagrass
Probablemente querrá verificar esto: httpd.apache.org/docs/2.4/upgrading.html#access y esto: stackoverflow.com/questions/12759854/…
Shylo Hana
66
Si agrega LogLevel debuga VirtualHost, este es un buen consejo, ya que verá líneas como "Requerir todo denegado: denegado" y "<RequireAny>: denegado" (es decir, mucho más útil que simplemente "cliente denegado por la configuración del servidor", ya que realmente te dice qué configuración!)
Darren Cook
4

Me resolví después de pasar un par de horas.

Instalé Apache / 2.4.7 (Ubuntu) a través de coookbook en vagrant vm.

El archivo /etc/apache2/apache2.conf no tiene <VirtualHost *:80>elemento por defecto.

Hice dos cambios para hacerlo

  1. adicional <VirtualHost *:80>

  2. Opciones añadidas Índices FollowSymLinks
    AllowOverride all
    Allow from all

entonces finalmente acabo de arrancar vm ..

Giri Babu
fuente
4

¿Alguien ha pensado en que el servidor predeterminado de wamp no incluya el httpd-vhosts.confarchivo? Mi enfoque es eliminar la nota a continuación

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

en el httpd.confarchivo Eso es todo.

Heier
fuente
+1 Esto también funcionó para mí, pero tal vez una mejor solución es mantener el conf/extra/httpd-vhosts.confarchivo y reemplazarlo Require localconRequire all granted
Alex Pandrea
4

en mi caso,

Estoy usando macOS Mojave (Apache / 2.4.34). Hubo un problema en la configuración del host virtual en el archivo /etc/apache2/extra/httpd-vhosts.conf. después de agregar la etiqueta de directorio requerida, mi problema desapareció.

Requerir todo otorgado

Espero que la estructura completa de configuración del host virtual lo salve.

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

todo lo que tiene que hacer reemplaza MainProjectFolderName con su ProjectFolderName exacto.

sh6210
fuente
2

Esto me estaba volviendo loco. Finalmente descubrí cuál era el problema: estaba usando rutas directas para el registro de errores y estaban equivocados.

¿Por qué Apache muestra un mensaje de error vago (e incorrecto)? En su lugar, use un mensaje de error correcto y útil como: La ruta para la directiva ErrorLog "/wrong/path/and/filename.log" no es válida.

De todos modos, para solucionarlo, asegúrese de que sus directivas de registro de errores se vean así:

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

Si está utilizando Apache 2.4 en WampServer en el sistema operativo Windows.

Es necesario abrir https-vhosts.conf archivo en el bloc de notas.

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

Si no puede encontrar el archivo anterior. ver captura de pantalla a continuación 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>

En el código anterior Reemplazar

Require local

con

Require all granted

Y guárdalo. Reinicie el servicio Apache e intente nuevamente.

Dev Semicolon
fuente
2

Para mí, en realidad había actualizado las reglas Permitir y Denegar basadas en el estándar 2.4.

Require all granted

Sin embargo, esto todavía me causaba recibir el mismo error AH01630. Encontré otro hilo y sugirió reinstalar apache2. De alguna manera esto funcionó! Si a alguien le importa explicar por qué, eso sería útil.

Crédito a: AH01630: el cliente denegado por la configuración del servidor pero requiere que todo lo que se haya otorgado esté configurado (Apache 2.4, CentOs)

NewNewGreg
fuente
1

Si tiene un host https, no olvide hacer Require all grantedcambios para la configuración SSL también.

Además, a veces es útil verificar los permisos como usuario de 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
Putnik
fuente
1

Para Wamp 3 (Apache 2.4), además de poner el servidor en línea como se describe en las otras respuestas, en el archivo Hosts virtuales conf/extra/httpd-vhosts.conf
es posible que deba reemplazar

Require local

con

Require all granted



Esto es aplicable si en httpd.confusted tiene

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

Cuando use Ubuntu verifique si el módulo CGI está habilitado. Si no:

sudo a2enmod cgi
hfmanson
fuente
El módulo CGI necesitaba estar habilitado. El programa finalmente funcionó.
Steve R.
1

¡Asegúrese de que se incluyan las configuraciones específicas del usuario!

Si ninguna de las otras respuestas en esta página para usted funciona, esto es lo que me encontré después de horas de vacilar.

Solía configuraciones específicas del usuario, con Sitesespecificada como mi UserDiren /private/etc/apache2/extra/httpd-userdir.conf. Sin embargo, se me prohibió el acceso al punto final.http://localhost/~jwork/ .

Pude ver /var/log/apache2/error_logque ese acceso a /Users/jwork/Sites/estaba siendo bloqueado. Sin embargo, se me permitió acceder a DocumentRoot a través de http://localhost/. Esto sugirió que no tenía derechos para ver al ~jworkusuario. Pero por lo que me di cuenta por ps aux | egrep '(apache|httpd)'y lsof -i :80, Apache se ejecuta para el jworkusuario, por lo que algo estaba claramente no escribir con la configuración de usuario.

Dado un usuario llamado jwork, aquí estaba mi archivo de configuración:

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

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

Esta configuración es perfectamente válida. Sin embargo, descubrí que mi configuración de usuario no estaba incluida:

/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

Tenga en cuenta que esta es la ruta predeterminada al archivo conf de userdir, pero como verá a continuación, es configurable en httpd.conf. Asegúrese de que las siguientes líneas estén habilitadas:

/private/etc/apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so
Jamie Birch
fuente
1

Para aquellos que se quedaron con este error como yo y nada ayudó desde arriba: verifique si la carpeta del problema de error.log realmente existe en su servidor. La mía fue generada automáticamente por Django en el lugar equivocado (estaba desordenado con la raíz estática, entonces manage.py collectstatic). No tengo idea de por qué uno no puede nombrar los errores correctamente.

Dmitry
fuente
Gracias por recordarme que use mi cerebro, solucioné mi problema. +1 jaja
orangecaterpillar
0

Además de las directivas faltantes Ordery Allowmencionadas en otras respuestas, tenga en cuenta que una expresión regular no coincidente de una DirectoryMatchdirectiva también puede causar este error.

Si la ruta solicitada es /home/user-foo1bar/www/myproject/la coincidencia siguiente no coincidirá

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

por lo tanto, incluso una configuración de acceso válida puede causar este error.

tratar de atrapar finalmente
fuente
0

Una causa oscura (que acaba de resolver), pero posible, es una regla interna mod_rewrite, en el archivo de configuración principal (no .htaccess) que escribe en una ruta que existe en la raíz del sistema de archivos del servidor. Digamos que tiene un /mediadirectorio en su sitio y reescribe algo como esto:

RewriteRule /some_image.png /media/some_other_location.png

Si tiene un /mediadirectorio en la raíz de su servidor, se intentará reescribirlo (lo que dará como resultado el error de acceso denegado) en lugar del que está en el directorio de su sitio, ya que mod_rewrite comprueba primero la raíz del sistema de archivos. del primer directorio en la ruta, antes del directorio de su sitio.

Nigel B. Peck
fuente
0

El problema puede ser que la directiva no está en <Directorio>

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

Se puede hacer referencia a la directiva en una sección <Directorio>, <Archivos> o <Ubicación>, así como en archivos .htaccess para controlar el acceso a partes particulares del servidor. El acceso se puede controlar en función del nombre de host del cliente o la dirección IP.

Sergio
fuente
0

Tengo otro que puede ser útil para alguien. Recibía el mismo mensaje de error después de actualizar desde PHP 5.6 => 7.0. Habíamos cambiado la configuración de carga de PHP, y olvidamos cambiar una vez copiada. Aunque no estaba subiendo imágenes en ese momento, Silverstripe (nuestro CMS) se negaba a guardar y arrojó ese error. Aumentó el tamaño de carga de la imagen y funcionó de inmediato.

Andrew MacNaughton
fuente
0

En caso de que esto ayude a alguien a buscar en Google como yo, recibí este mensaje de error al intentar acceder a un archivo SVG en mi servidor, por ejemplo, https://example.com/images/file.svg . Otros tipos de archivos parecían estar bien, solo SVG fallaba.

Busqué alrededor de /etc/httpdarchivos conf y comprueba cada require all deniedtipo de configuración, y no podía encontrar lo config estaba teniendo este efecto.

Convertí LogLevel para depurar en la configuración de VirtualHost y pude ver el registro mod_authz_core especificando que había un 'Requerir todo denegado' en efecto:

[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

A través de pruebas ciegas, moví el archivo a la raíz de la raíz web, y descubrí que podía acceder a él en https://example.com/file.svg ... por lo que solo falló en la carpeta 'imágenes'. Esto me llevó a un archivo .htaccess en la carpeta de imágenes que no tenía idea de que estaba allí.

Resulta que Zen Cart 1.5 viene con un archivo de imágenes / .htaccess que tiene:

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

Esto fue muy molesto y espero que esto les recuerde a los demás que comprueben los archivos .htaccess en todos los niveles del sistema de archivos que conducen al archivo al que tienen problemas para acceder en caso de que ocurra este tipo de tonterías.

Neek
fuente
0

De hecho, resolví esto agregando el acceso al directorio a la entrada: 80.

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

Antes de que todos tengan toda la "seguridad" sobre mí, bajo mis circunstancias específicas, esto no es un problema de seguridad.

Si está utilizando un recurso remoto, le recomiendo que se asegure de que su solicitud CURL se envíe a través de HTTPS / TLS, luego esta entrada del directorio va al puerto 443.

AdheneManx
fuente
0

Este "error" es en realidad el nuevo comportamiento normal de Apache 2.4. En mi caso, tenía una regla muy específica para denegar el acceso a cualquier carpeta o archivo cuyo nombre comenzara con ".", Así que tuve que establecer una excepción para una carpeta pública en particular que requiere un nombre tan extraño.

Para el registro, mi regla particular de reescritura es:

RewriteRule "(?!\.trusted)(^|/)\." - [F]

Esta regla [F] obedece todo a partir de ". pero.trusted , gracias a la magia de la expresión regular "?!" negación.

develCuy
fuente
0

Debido a que este hilo es lo primero que aparece al buscar el error mencionado, me gustaría agregar otra posible causa de este error: es posible que esté mod_evasiveactivo y que el cliente que lo ve simplemente haya cruzado los límites configurados en sumod_evasive.conf

Esto es especialmente una causa que vale la pena investigar si de repente recibe este error para un cliente que no tuvo problemas antes y nada más ha cambiado.

(si mod_evasivees la causa, el error desaparecerá por sí solo si el cliente deja de intentar acceder temporalmente al sitio; sin embargo, puede ser una señal de que ha configurado límites demasiado estrictos)

Arturo
fuente
0

Para mí, todas las soluciones propuestas no funcionarán. Esto puede ayudar, si usa cgi, fastcig o fpm como proxy, debe agregar una ubicación en su vhost para evitar este problema. Esto permite que 404 sea proxy de paso a través.

<Location />
require all granted
</Location>
Vaquero
fuente