Apache2: 'AH01630: cliente negado pela configuração do servidor'

429

Eu recebo esse erro ao tentar acessar o host local por meio de um navegador.

AH01630: client denied by server configuration

Eu verifiquei as permissões da pasta do meu site usando:

sudo chmod 777 -R *

Aqui está o meu arquivo de configuração:

<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
fonte
1
Você está usando o novo Apache 2.4? Qual caminho dá esse erro?
aadel
12
Parece que você precisa atualizar suas configurações. Dê uma olhada aqui: httpd.apache.org/docs/2.4/upgrading.html#run-time
aadel
5
Por favor, dê uma olhada nisto: dabase.com/blog/AH01630:_client_denied_by_server_configuration #
Christian Müller
7
chmod 777é um péssimo hábito, mesmo que (supostamente) esteja sendo usado apenas em exemplos.
Antonis Christofides
3
chmod 777 nunca é a resposta.
Aaron McMillin

Respostas:

770

Se você estiver usando o Apache 2.4

Você deve verificar as regras de permissão e negação

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

Na 2.2, o controle de acesso com base no nome do host do cliente, endereço IP e outras características das solicitações do cliente foi realizado usando as diretivas Ordem, Permitir, Negar e Satisfazer.

Na 2.4, esse controle de acesso é feito da mesma maneira que outras verificações de autorização, usando o novo módulo mod_authz_host.

A nova diretiva é Exigir :

2.2 configuração:

Order allow,deny
Allow from all

2.4 configuração:

Require all granted

Também não se esqueça de reiniciar o servidor apache após essas alterações ( # service httpd restart)

Jayakumar Bellie
fonte
2
Obras de OSX 10.10 Yosemite usando Apache 2.4
Matthew Herbst
2
Configuração do que (ou seja, para onde vai "Exigir tudo concedido"? Em algum arquivo .conf?) #
Alexis
1
Diretório @Alexis (ou local). Veja a captura de tela na próxima resposta.
strangeman
2
No meu caso, tenho erros DocumentRoote <Directory>caminhos.
Roman Grinyov 3/17/17
4
Uma coisa a nota: se você está se referindo a configuração on-line, as chances são eles usei tanto Order allow,deny ...e Require all granted. Isso não vai funcionar. Ele precisa ser apenas um deles, dependendo da sua versão. Foi isso que me impediu de resolver meu problema no início.
Vishnu Narang
299

Para todos os diretórios, escreva em Require all grantedvez deAllow from all Algo como

Atualizar

Se o acima não funcionar, remova-o abaixo da linha mencionada:

Ordem permitir, negar

valera5505
fonte
14
Trabalhou para mim depois de remover a Order allow,denylinha também.
kasperd
Atenção: enquanto usando HTTPS , configurando um VirtualHost para a porta 443 , eu tinha para replicar as mesmas configurações <Location /media> Require all granted </Location>em default-ssl.confpara o meu CSS para ser carregado. (Meu problema era que a página de login era acessível, mas há arquivos CSS nem outros meios de comunicação foram carregados ...)
yuric
1
Obras de OSX 10.10 Yosemite usando Apache 2.4
Matthew Herbst
7
Eu sou o único que odeia quando alguém quebra as configurações do Apache sem nenhuma saída no log. (Hey meninos, Allow from Allfoi aposentado porque .... razões ...)
Warren P
Obrigado - removendo "Order allow, deny" ajudou
srvy
34

Verifique novamente se o caminho DocumentRoot está correto. Isso pode causar esse erro.

Tim
fonte
3
Mais especificamente, achei que esse era o meu problema porque não tinha barra na minha declaração do DocumentRoot, mas usei uma no <Directory>bloco. Eu também tive algumas diferenças de casos. Depois que eu fiz esses dois valores, cópias carbono um do outro (sem a barra), funcionou perfeitamente.
Adam Tuttle
Se for esse o caso (sim, também aconteceu aqui ....), você pode encontrar a seguinte linha em apache/logs/error.log:AH00112: Warning: DocumentRoot [E:/xampp/htdocs/website/frontend/web] does not exist
Piemol
Não posso acreditar que também posso encontrar respostas para meus erros de digitação :-) Obrigado por mencioná-lo, meu problema foi o caminho inválido no meu arquivo conf.
Taher
21

Fiz as mesmas alterações que o ravisorg sugeriu para o OSX 10.10 Yosemite que atualiza o Apache para a versão 2.4. Abaixo estão as alterações que foram adicionadas ao http.conf.

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

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

Isso me deixou absolutamente doida por um dia e meio, mas eu encontrei uma solução se todas as outras soluções foram tentadas sem êxito.

Isso é para o macOS.

  • Vá para o Monitor de atividades (pesquisa em destaque: atividade)
  • No monitor de atividades, procure httpd, que é o serviço Apache
  • Selecione o que pertence à raiz e clique em X no canto superior esquerdo para fechá-lo.

Nesse ponto, eu imediatamente parei de receber 403 erros e tudo começou a funcionar como esperado. O estranho é que eu nem precisei reiniciar o apache, apenas funcionou, acho que ele se reiniciou quando fui ao meu host local, sinceramente não sei, mas acho que o problema é que o Apache não está realmente reiniciando ao usar o apachectl restart, ou pare ou comece. Espero que isso ajude alguém.

RAC
fonte
1
Depois de horas perdidas, foi isso que resolveu meus problemas também.
ever.wakeful
10

O problema está no VirtualHost, mas provavelmente não é

Exigir todos os concedidos

Confirme se sua configuração está correta, aqui está uma amostra correta insira a descrição da imagem aqui

Albert.Qing
fonte
Incluir as <Directory ...> ... </Directory>linhas funcionou para mim desde que eu estava usando um caminho de diretório que não era definido anteriormente nas configurações do Apache antes.
Don Wilson
4

Se você seguir o log de erros e recarregar a página, verá mais algumas informações sobre o problema exato.

Pegue as variáveis ​​de ambiente para que $ {APACHE_LOG_DIR} funcione ...

source /etc/apache2/envvars

Então siga e assista ...

tail -f ${APACHE_LOG_DIR}/error.log
Shylo Hana
fonte
5
Este é o erro dos logs: 'AH01630: cliente negado pela configuração do servidor'
Hazem Hagrass
6
Se você adicionar LogLevel debugao VirtualHost, este é um bom conselho, pois você verá linhas como "Exigir tudo negado: negado" e "<RequireAny>: negado" (ou seja, muito mais útil do que apenas "cliente negado pela configuração do servidor", como ela realmente diz-lhe que configuração)!
Darren Cozinhe
4

Eu me resolvi depois de passar algumas horas.

Eu instalei o Apache / 2.4.7 (Ubuntu) através do coookbook no vagrant vm.

O arquivo /etc/apache2/apache2.conf não possui <VirtualHost *:80>elemento por padrão.

Eu fiz duas alterações para fazê-lo

  1. adicionado <VirtualHost *:80>
  2. adicionado
    Opções Índices FollowSymLinks
    AllowOverride all
    Allow from all

então finalmente acabei de inicializar vm ..

Giri Babu
fonte
4

Alguém já pensou sobre esse padrão de servidor wamp não incluir o httpd-vhosts.confarquivo. Minha abordagem é remover a nota abaixo

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

no httpd.confarquivo. Isso é tudo.

Heier
fonte
+1 Isso funcionou para mim também, mas talvez a melhor solução é manter o conf/extra/httpd-vhosts.confarquivo e substitua nele Require localcomRequire all granted
Alex Pandrea
4

No meu caso,

Estou usando o macOS Mojave (Apache / 2.4.34). Ocorreu um problema nas configurações do host virtual no arquivo /etc/apache2/extra/httpd-vhosts.conf. depois de adicionar a tag de diretório necessária, meu problema desapareceu.

Exigir todos os concedidos

Espero que a estrutura completa de configuração do host virtual o 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>

tudo o que você deve fazer substitui o MainProjectFolderName pelo seu ProjectFolderName exato.

sh6210
fonte
2

Isso estava me deixando louco. Finalmente descobri qual era o problema: eu estava usando caminhos diretos para o log de erros e eles estavam errados.

Por que o Apache transmite uma mensagem de erro vaga (e errada)? Em vez disso, use uma mensagem de erro correta e útil como: Caminho para a diretiva ErrorLog "/wrong/path/and/filename.log" é inválido.

De qualquer forma, para corrigir, verifique se as diretivas do log de erros são parecidas com esta:

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

Se você estiver usando o Apache 2.4 no WampServer no sistema operacional Windows.

Você precisa abrir o arquivo https-vhosts.conf no bloco de notas.

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

Se você não conseguir encontrar o arquivo acima. verifique a captura de tela abaixo 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>

No código acima, substitua

Require local

com

Require all granted

E salve. Reinicie o serviço Apache e tente novamente.

Dev Semicolon
fonte
1

Se você possui o host https, não se esqueça de fazer Require all grantedalterações na configuração do SSL também.

Além disso, às vezes é útil verificar permissões como o usuário 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
fonte
1

Para o Wamp 3 (Apache 2.4), além de colocar o servidor on-line como descrito nas outras respostas, no arquivo Hosts Virtuais, conf/extra/httpd-vhosts.conf
você pode precisar substituir

Require local

com

Require all granted



Isso é aplicável se httpd.confvocê tiver

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

Ao usar o Ubuntu, verifique se o módulo CGI está ativado. Se não:

sudo a2enmod cgi
hfmanson
fonte
O módulo CGI precisava estar ativado. Programa finalmente funcionou.
Steve R.
1

Verifique se todas as configurações específicas do usuário estão incluídas!

Se nenhuma das outras respostas desta página para você funcionar, eis o que encontrei após horas de discussões.

Eu costumava configurações específicas do usuário, com Sitesespecificado como o meu UserDirno /private/etc/apache2/extra/httpd-userdir.conf. No entanto, fui proibido o acesso ao terminal http://localhost/~jwork/.

Pude ver /var/log/apache2/error_logque o acesso ao /Users/jwork/Sites/estava sendo bloqueado. No entanto, eu tinha permissão para acessar o DocumentRoot, via http://localhost/. Isso sugeriu que eu não tinha direitos para visualizar o ~jworkusuário. Mas, tanto quanto eu poderia dizer por ps aux | egrep '(apache|httpd)'e lsof -i :80, Apache estava correndo para o jworkusuário, assim que algo não foi claramente escrever com a configuração do usuário.

Dado um usuário chamado jwork, aqui estava o meu arquivo de configuração:

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

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

Esta configuração é perfeitamente válida. No entanto, descobri que minha configuração de usuário não estava sendo incluída:

/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

Observe que este é o caminho padrão para o arquivo conf userdir, mas como você verá abaixo, é configurável em httpd.conf. Verifique se as seguintes linhas estão ativadas:

/private/etc/apache2/httpd.conf

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

# ...

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

Para quem ficou com esse erro como eu e nada ajudou de cima: verifique se a pasta do problema de error.log realmente existe no seu servidor. O meu foi gerado automaticamente pelo Django no lugar errado (foi danificado com raiz estática, então manage.py collectstatic). Não tenho idéia por que não se pode nomear erros corretamente.

Dmitry
fonte
Obrigado por me lembrar de usar meu cérebro, corrigido meu problema. +1 haha
orangecaterpillar
0

Além das diretivas ausentes Ordere ausentes Allowmencionadas em outras respostas, saiba que uma expressão regular não correspondente de uma DirectoryMatchdiretiva também pode causar esse erro.

Se o caminho solicitado for /home/user-foo1bar/www/myproject/o seguinte, o correspondente não corresponderá

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

portanto, mesmo uma configuração de acesso válida pode causar esse erro.

finalmente tente
fonte
0

Uma causa obscura (tendo acabado de lidar com isso), ainda que possível, é uma regra interna mod_rewrite, no arquivo de configuração principal (não .htaccess), que grava em um caminho existente na raiz do sistema de arquivos do servidor. Digamos que você tenha um /mediadiretório em seu site e reescreva algo como isto:

RewriteRule /some_image.png /media/some_other_location.png

Se você tiver um /mediadiretório na raiz do servidor, a reescrita será tentada para isso (resultando no erro de acesso negado) em vez daquele no diretório do site, pois a raiz do sistema de arquivos é verificada primeiro por mod_rewrite, quanto à existência do primeiro diretório no caminho, antes do diretório do site.

Nigel B. Peck
fonte
0

O problema pode ser que a diretiva não esteja em <Diretório>

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

A diretiva pode ser referenciada nas seções <Diretório>, <Arquivos> ou <Localização>, bem como nos arquivos .htaccess para controlar o acesso a partes específicas do servidor. O acesso pode ser controlado com base no nome do host ou no endereço IP do cliente.

Sérgio
fonte
0

Eu tenho outro que pode ser útil para alguém. Estava recebendo a mesma mensagem de erro após a atualização do PHP 5.6 => 7.0. Alteramos as configurações de upload do PHP e esquecemos de mudar uma vez copiadas. Embora eu não estivesse carregando imagens na época, o Silverstripe (nosso CMS) estava se recusando a salvar e lançar esse erro. Aumentou o tamanho do upload da imagem e funcionou imediatamente.

Andrew MacNaughton
fonte
0

Caso isso ajude alguém a pesquisar no Google como eu, recebi esta mensagem de erro ao tentar acessar um arquivo SVG no meu servidor, por exemplo, https://example.com/images/file.svg . Outros tipos de arquivos pareciam bons, apenas o SVG estava falhando.

Eu procurei /etc/httpdarquivos conf e verifiquei todos osrequire all denied tipos de configuração, e simplesmente não consegui encontrar qual configuração estava causando esse efeito.

Virei o LogLevel para depurar na configuração do VirtualHost e pude ver o log mod_authz_core especificando que havia um 'Exigir tudo negado' em efeito:

[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

Por meio do teste cego, movi o arquivo para a raiz da raiz da web e descobri que podia acessá-lo em https://example.com/file.svg .. para que ele falhasse apenas na pasta 'images'. Isso me levou a um arquivo .htaccess na pasta de imagens que eu não fazia ideia de que estava lá.

Acontece que o Zen Cart 1.5 vem com um arquivo images / .htaccess que possui:

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

Isso foi muito chato e espero que isso possa lembrar outras pessoas para verificar arquivos .htaccess em todos os níveis do sistema de arquivos que levam ao arquivo que você está tendo problemas para acessar, caso ocorra esse tipo de brincadeira.

Neek
fonte
0

Na verdade, eu resolvi esse problema adicionando o acesso ao diretório na entrada: 80.

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

Antes que todos tenham toda a 'segurança' em mim, sob minhas circunstâncias específicas, isso não é um problema de segurança.

Se você estiver usando um recurso remoto, recomendo que a sua solicitação CURL seja via HTTPS / TLS, então essa entrada de diretório vai para a porta 443.

AdheneManx
fonte
0

Esse "bug" é realmente o novo comportamento normal do Apache 2.4. No meu caso, eu tinha uma regra muito específica para negar acesso a qualquer pasta ou arquivo com o nome começando com ".", Então tive que definir uma exceção para uma pasta pública específica que requer um nome estranho.

Para o registro, minha regra de reescrita específica é:

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

Esta regra [F] obedece a tudo começando com "." mas .trusted, graças à magia do regex "?!" negação.

develCuy
fonte
0

Como esse encadeamento é a primeira coisa que aparece ao procurar o erro mencionado, gostaria de adicionar outra causa possível para esse erro: você pode estar mod_evasiveativo e o cliente que vê esse erro simplesmente ultrapassou os limites configurados no seumod_evasive.conf

Isso é especialmente uma causa que vale a pena investigar se você estiver recebendo esse erro repentinamente para um cliente que não apresentava problemas antes e nada mais mudou.

(se mod_evasivefor a causa, o erro desaparecerá se o cliente parar temporariamente de tentar acessar o site; no entanto, pode ser um sinal de que você configurou limites muito rígidos)

Arthur
fonte
0

Para mim, todas as soluções propostas não funcionarão. Isso pode ajudar, se você usar cgi, fastcig ou fpm como proxy, precisará adicionar um local no seu vhost para evitar esse problema. Isso permite que 404 seja proxy de passagem.

<Location />
require all granted
</Location>
Jean
fonte