wake-up-neo.com

Apache2: 'AH01630: Client von Serverkonfiguration abgelehnt'

Ich erhalte diese Fehlermeldung, wenn ich versuche, über einen Browser auf localhost zuzugreifen.

AH01630: client denied by server configuration

Ich habe die Berechtigungen meines Site-Ordners folgendermaßen überprüft:

Sudo chmod 777 -R *

Hier ist meine Konfigurationsdatei:

<VirtualHost *:80>
ServerAdmin [email protected]

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>
410
Hazem Hagrass

Wenn Sie Apache 2.4 verwenden

Sie müssen Zulassen und Ablehnen von Regeln überprüfen

Check out http://httpd.Apache.org/docs/2.4/upgrading.html#access

In 2.2 wurde die Zugriffssteuerung basierend auf dem Hostnamen des Clients, der IP-Adresse und anderen Merkmalen von Clientanforderungen mithilfe der Direktiven Order, Allow, Deny und Satisfy durchgeführt.

In 2.4 erfolgt eine solche Zugriffskontrolle wie bei anderen Berechtigungsprüfungen mit dem neuen Modul mod_authz_Host.

Die neue Direktive lautet Require :

2.2 Konfiguration:

Order allow,deny
Allow from all

2.4 Konfiguration:

Require all granted

Vergessen Sie auch nicht, den Apache-Server nach diesen Änderungen neu zu starten (# service httpd restart)

742

Schreiben Sie für alle Verzeichnisse Require all granted anstelle von Allow from all Something like

pdate

Wenn dies nicht funktioniert, entfernen Sie auch diese Zeile:

Ordnung erlauben, ablehnen

297
valera5505

Stellen Sie sicher, dass der DocumentRoot-Pfad korrekt ist. Das kann diesen Fehler verursachen.

32
Tim

Ich habe die gleichen Änderungen vorgenommen, die Ravisorg für OSX 10.10 Yosemite vorgeschlagen hat, das Apache auf Version 2.4 aktualisiert. Nachfolgend sind die Änderungen aufgeführt, die zu http.conf hinzugefügt wurden.

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

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

Das hat mich für eineinhalb Tage total verrückt gemacht, aber ich habe eine Lösung gefunden, wenn alle anderen Lösungen erfolglos ausprobiert wurden.

Dies ist für MacOS.

  • Gehe zum Aktivitätsmonitor (Spotlight-Suche nach: Aktivität)
  • Suchen Sie im Aktivitätsmonitor nach httpd, dem Apache-Dienst
  • Wählen Sie diejenige aus, die zu root gehört, und klicken Sie oben links auf X, um sie zu schließen.

An diesem Punkt hörte ich sofort auf, 403 Fehler zu bekommen und alles begann wie erwartet zu funktionieren. Merkwürdige Sache ist, dass ich Apache nicht neu starten musste, es hat gerade funktioniert, ich glaube, es hat sich von selbst neu gestartet, als ich zu meinem lokalen Host ging stoppen oder starten. Hoffe das hilft jemandem.

11
RAC

Das Problem ist in VirtualHost, aber ist wahrscheinlich nicht

Benötigen Sie alle gewährt

Bestätige , dass deine Konfiguration korrekt ist, hier ist das richtige Beispiel enter image description here

7
Albert.Qing

Ich habe mich nach ein paar Stunden aufgelöst.

Ich habe Apache/2.4.7 (Ubuntu) über coookbook in vagrant vm installiert.

Die Datei /etc/Apache2/Apache2.conf enthält standardmäßig kein <VirtualHost *:80> -Element.

Ich habe zwei Änderungen vorgenommen, um es zu erledigen

  1. <VirtualHost *:80> hinzugefügt
  2. hinzugefügt
    Optionen Indizes FollowSymLinks
    AllowOverride all
    Von allen erlauben

dann habe ich endlich gerade vm gebootet ..

4
Giri Babu

Wenn Sie das Fehlerprotokoll abschließen und die Seite neu laden, sollten Sie weitere Informationen zum genauen Problem erhalten.

Holen Sie sich die Umgebungsvariablen, damit $ {Apache_LOG_DIR} tatsächlich funktioniert ...

source /etc/Apache2/envvars

Dann Schwanz und zuschauen ...

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

Hat jemand darüber nachgedacht, dass der Wamp-Server standardmäßig die httpd-vhosts.conf -Datei nicht enthält. Mein Ansatz ist es, den folgenden Hinweis zu entfernen

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

in httpd.conf Datei. Das ist alles.

4
Heier

in meinem Fall,

ich benutze MacOS Mojave (Apache/2.4.34). In den Einstellungen des virtuellen Hosts in der Datei /etc/Apache2/extra/httpd-vhosts.conf ist ein Problem aufgetreten. Nach dem Hinzufügen des erforderlichen Verzeichnis-Tags war mein Problem behoben.

Benötigen Sie alle gewährt

Hoffe, die vollständige Setup-Struktur des virtuellen Hosts wird Sie retten.

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

alles, was Sie tun müssen, ist, den MainProjectFolderName durch Ihren genauen ProjectFolderName zu ersetzen.

4
sh6210

Wenn Sie Apache 2.4 in WampServer unter Windows verwenden.

Sie müssen die Datei https-vhosts.conf im Editor öffnen.

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

Wenn Sie die obige Datei nicht finden können. Screenshot unten prüfen 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>

Im obigen Code Ersetzen

Require local

mit

Require all granted

Und rette es. Starten Sie den Apache-Dienst neu und versuchen Sie es erneut.

2
Dev Semicolon

Das hat mich verrückt gemacht. Endlich herausgefunden, was das Problem war: Ich habe direkte Pfade für das Fehlerprotokoll verwendet und sie waren falsch.

Warum gibt Apache eine vage (und falsche) Fehlermeldung aus? Verwenden Sie stattdessen eine korrekte und nützliche Fehlermeldung wie: Der Pfad für die ErrorLog-Direktive "/wrong/path/and/filename.log" ist ungültig.

Um das Problem zu beheben, stellen Sie sicher, dass Ihre Fehlerprotokollanweisungen ungefähr so ​​aussehen:

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

Wenn Sie einen https-Host haben, vergessen Sie nicht, Require all granted Änderungen auch für die SSL-Konfiguration vorzunehmen.

Manchmal ist es auch nützlich, Berechtigungen als Apache-Benutzer zu überprüfen:

# 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

Stellen Sie sicher, dass alle benutzerspezifischen Konfigurationen enthalten sind!

Wenn keine der anderen Antworten auf dieser Seite für Sie funktioniert, ist dies das, was mir nach stundenlangem Hin und Her begegnet ist.

Ich habe benutzerspezifische Konfigurationen verwendet, wobei Sites in /private/etc/Apache2/extra/httpd-userdir.conf als mein UserDir angegeben wurde. Der Zugriff auf den Endpunkt http://localhost/~jwork/ war mir jedoch untersagt.

Ich konnte in /var/log/Apache2/error_log sehen, dass der Zugriff auf /Users/jwork/Sites/ blockiert wurde. Ich durfte jedoch über http://localhost/ auf den DocumentRoot zugreifen. Dies deutete darauf hin, dass ich keine Rechte zum Anzeigen des Benutzers ~jwork hatte. Aber soweit ich durch ps aux | egrep '(Apache|httpd)' und lsof -i :80 feststellen konnte, lief Apache für den Benutzer jwork, sodass mit meiner Benutzerkonfiguration eindeutig etwas nicht zu schreiben war.

Bei einem Benutzer namens jwork war hier meine Konfigurationsdatei:

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

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

Diese Konfiguration ist vollkommen gültig. Ich stellte jedoch fest, dass meine Benutzerkonfiguration nicht enthalten war:

/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

Beachten Sie, dass dies der Standardpfad zur Datei "userdir conf" ist. Wie Sie unten sehen werden, kann dieser in httpd.conf konfiguriert werden. Stellen Sie sicher, dass die folgenden Zeilen aktiviert sind:

/private/etc/Apache2/httpd.conf

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

# ...

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

Für Wamp 3 (Apache 2.4), außer den Server wie in den anderen Antworten beschrieben online zu stellen, in der Virtual Hosts-Datei conf/extra/httpd-vhosts.conf
müssen Sie möglicherweise ersetzen

Require local

mit

Require all granted



Dies gilt, wenn Sie in httpd.conf haben

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

Für diejenigen, die an diesem Fehler als ich festhielten und nichts von oben geholfen haben: Überprüfen Sie, ob der Problemordner aus error.log tatsächlich auf Ihrem Server vorhanden ist. Meins wurde automatisch von Django an der falschen Stelle generiert (wurde mit statischem Root und dann manage.py collectstatic durcheinander gebracht). Habe keine Ahnung warum man Fehler nicht richtig benennen kann.

0
Dmitry

Ich habe dieses Problem gelöst, indem ich den Verzeichniszugriff auf den Eintrag: 80 hinzugefügt habe.

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

Bevor alle "Sicherheit" für mich haben, handelt es sich unter bestimmten Umständen nicht um ein Sicherheitsproblem.

Wenn Sie eine Remote-Ressource verwenden, würde ich empfehlen, stattdessen sicherzustellen, dass Ihre CURL-Anforderung über HTTPS/TLS erfolgt. Dann wird dieser Verzeichniseintrag auf den 443-Port übertragen.

0
AdheneManx

Überprüfen Sie bei Verwendung von Ubuntu, ob das CGI-Modul aktiviert ist. Wenn nicht:

Sudo a2enmod cgi
0
hfmanson

Neben den fehlenden Anweisungen Order und Allow, die in anderen Antworten erwähnt wurden, muss beachtet werden, dass ein nicht übereinstimmender regulärer Ausdruck einer Anweisung DirectoryMatch ebenfalls diesen Fehler verursachen kann.

Wenn der angeforderte Pfad /home/user-foo1bar/www/myproject/ ist, stimmt der folgende Matcher nicht überein

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

daher kann auch eine gültige Zugriffskonfiguration diesen Fehler verursachen.

0

Eine obskure (gerade behandelte), aber mögliche Ursache dafür ist eine interne mod_rewrite-Regel in der Hauptkonfigurationsdatei (nicht .htaccess), die in einen Pfad schreibt, der im Stammverzeichnis des Server-Dateisystems vorhanden ist. Angenommen, Sie haben ein /media -Verzeichnis in Ihrer Site und Sie schreiben so etwas um:

RewriteRule /some_image.png /media/some_other_location.png

Wenn Sie ein /media -Verzeichnis im Stammverzeichnis Ihres Servers haben, wird versucht, dieses neu zu schreiben (was zu dem Fehler führt, dass der Zugriff verweigert wird), und nicht das Verzeichnis in Ihrem Site-Verzeichnis, da das Dateisystem-Stammverzeichnis zuerst von überprüft wird mod_rewrite für das Vorhandensein des ersten Verzeichnisses im Pfad vor Ihrem Site-Verzeichnis.

0
Nigel B. Peck

Ich habe eine andere, die für jemanden nützlich sein kann. Wurde die gleiche Fehlermeldung nach dem Upgrade von PHP 5.6 => 7.0 angezeigt. Wir hatten die Einstellungen für das Hochladen von PHP geändert und vergessen, diese nach dem Kopieren zu ändern. Obwohl ich zu der Zeit keine Bilder hochgeladen habe, hat Silverstripe (unser CMS) sich geweigert, diesen Fehler zu speichern und zu werfen. Erhöht die Größe des Bild-Uploads und es hat sofort funktioniert.

0

Das Problem kann sein, dass sich die Direktive nicht unter <Directory> befindet

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

Auf die Direktive kann in einem Abschnitt <Directory>, <Files> oder <Location> sowie in .htaccess-Dateien verwiesen werden, um den Zugriff auf bestimmte Teile des Servers zu steuern. Der Zugriff kann basierend auf dem Hostnamen oder der IP-Adresse des Clients gesteuert werden.

0
Sérgio

Für den Fall, dass dies jemandem hilft, der wie ich herum googelt, hatte ich diese Fehlermeldung beim Versuch, auf eine SVG-Datei auf meinem Server zuzugreifen, z. https://example.com/images/file.svg . Andere Dateitypen schienen in Ordnung zu sein, nur SVG schlug fehl.

Ich suchte in /etc/httpd conf-Dateien herum und überprüfte alle require all denied Konfigurationstypen. Ich konnte einfach nicht finden, welche Konfiguration diesen Effekt hatte.

Ich habe LogLevel zum Debuggen in der VirtualHost-Konfiguration aktiviert und konnte die Protokollierung von mod_authz_core sehen, in der angegeben wurde, dass "Alle verweigern" in Kraft ist:

[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

Durch Blindtests habe ich die Datei in das Stammverzeichnis des Webstamms verschoben und festgestellt, dass ich unter https://example.com/file.svg darauf zugreifen kann. Ordner der Bilder. Dies führte mich zu einer .htaccess-Datei im Bilderordner, von der ich keine Ahnung hatte, dass sie dort war.

Es stellt sich heraus, dass Zen Cart 1.5 eine Bilder/.htaccess-Datei enthält, die Folgendes enthält:

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

Dies war sehr ärgerlich und ich hoffe, dass dies andere daran erinnert, die .htaccess-Dateien auf jeder Ebene des Dateisystems zu überprüfen, die zu der Datei führen, bei der Sie Probleme haben Zugriff, falls es solche Dummheiten gibt.

0
Neek