Apache2: „AH01630: klient odmówiony przez konfigurację serwera”

429

Występuje ten błąd podczas próby uzyskania dostępu do hosta lokalnego za pośrednictwem przeglądarki.

AH01630: client denied by server configuration

Sprawdziłem uprawnienia do folderu witryny, używając:

sudo chmod 777 -R *

Oto mój plik konfiguracyjny:

<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
źródło
1
Czy korzystasz z nowego Apache 2.4? Która ścieżka powoduje ten błąd?
aadel
12
Wygląda na to, że musisz zaktualizować swoje konfiguracje. Spójrz tutaj: httpd.apache.org/docs/2.4/upgrading.html#run-time
aadel
5
Proszę spojrzeć na to: dabase.com/blog/AH01630:_client_denied_by_server_configuration
Christian Müller
7
chmod 777jest bardzo złym nawykiem, nawet jeśli (podobno) jest używany tylko w przykładach.
Antonis Christofides,
3
chmod 777 nigdy nie jest odpowiedzią.
Aaron McMillin

Odpowiedzi:

770

Jeśli używasz Apache 2.4

Musisz zaznaczyć opcję „zezwalaj i odmawiaj”

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

W 2.2 kontrola dostępu oparta na nazwie hosta klienta, adresie IP i innych cechach żądań klienta została przeprowadzona przy użyciu dyrektyw Order, Allow, Deny i Satisfy.

W 2.4 taka kontrola dostępu odbywa się w taki sam sposób, jak inne kontrole autoryzacji, przy użyciu nowego modułu mod_authz_host.

Nowa dyrektywa wymaga :

Konfiguracja 2.2:

Order allow,deny
Allow from all

Konfiguracja 2.4:

Require all granted

Nie zapomnij również zrestartować serwera Apache po tych zmianach ( # service httpd restart)

Jayakumar Bellie
źródło
2
Działa z OSX 10.10 Yosemite przy użyciu Apache 2.4
Matthew Herbst
2
Konfiguracja tego, co (tj. Gdzie idzie „Wymagaj wszystkich przyznanych”? W niektórych plikach .conf?)
Alexis
1
@Alexis katalog (lub lokalizacja). Zobacz zrzut ekranu w następnej odpowiedzi.
strangeman
2
W moim przypadku mam błąd DocumentRooti <Directory>ścieżki.
Roman Grinyov
4
Jedną rzeczą do zapamiętania: jeśli odwołujesz się do konfiguracji online, są szanse, że użyli obu Order allow,deny ...i Require all granted. To nie zadziała Musi to być tylko jeden z nich w zależności od wersji. Na początku powstrzymywało mnie to od rozwiązania problemu.
Wisznu Narang
299

Dla wszystkich katalogów pisz Require all grantedzamiastAllow from all Coś jak

Aktualizacja

Jeśli powyższe nie działa, usuń również poniższy wiersz:

Zamów dozwolone, odmawiaj

valera5505
źródło
14
Pracowałem dla mnie, gdy już usunąłem Order allow,denylinię.
kasperd
Uwaga: podczas korzystania z HTTPS , konfigurowania VirtualHost dla portu 443 , musiałem powtórzyć te same pliki konfiguracyjne <Location /media> Require all granted </Location>na default-ssl.confna mój CSS być załadowany. (Mój problem polegał na tym, że strona logowania była dostępna, ale nie załadowano CSS ani innych plików multimedialnych ...)
yuric
1
Działa z OSX 10.10 Yosemite przy użyciu Apache 2.4
Matthew Herbst
7
Czy jestem jedynym, który NIENAWIDZI, gdy ktoś psuje konfiguracje Apache bez żadnych danych wyjściowych w dzienniku. (Cześć chłopcy, Allow from Allprzeszli na emeryturę, ponieważ ... powody ...)
Warren P
Dzięki - usunięcie pomocy „Zezwól na zamówienie, odmowa” pomogło
srvy
34

Sprawdź dokładnie, czy ścieżka DocumentRoot jest poprawna. Może to spowodować ten błąd.

Tim
źródło
3
Mówiąc dokładniej, stwierdziłem, że to był mój problem, ponieważ nie miałem końcowego ukośnika w deklaracji DocumentRoot, ale użyłem jednego w <Directory>bloku. Miałem też pewne różnice w sprawach. Kiedy stworzyłem te dwie wartości, kopie siebie (bez ukośnika), działało to doskonale.
Adam Tuttle
Jeśli tak jest (tak, zdarzyło się również tutaj ....) można znaleźć następującą linię w apache/logs/error.log:AH00112: Warning: DocumentRoot [E:/xampp/htdocs/website/frontend/web] does not exist
Piemol
Nie mogę uwierzyć, że mogę również znaleźć odpowiedzi na błędy w literówce :-) Dzięki, że o tym wspomniałem, mój problem był nieprawidłową ścieżką w moim pliku conf.
Taher
21

Wprowadziłem te same zmiany, które ravisorg zasugerował dla OSX 10.10 Yosemite, który aktualizuje Apache do wersji 2.4. Poniżej znajdują się zmiany, które zostały dodane do http.conf.

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

<Directory /Volumes/Data/Data/USER/Sites/>
    AllowOverride none
    Require all granted
</Directory>
KM
źródło
11

Doprowadziło mnie to do szaleństwa przez półtora dnia, ale znalazłem rozwiązanie, jeśli wszystkie inne rozwiązania zostały wypróbowane bezskutecznie.

To jest dla macOS.

  • Idź do Monitor aktywności (szukaj w centrum uwagi dla: aktywność)
  • W monitorowaniu aktywności wyszukaj httpd, który jest usługą Apache
  • Wybierz ten, który należy do roota i kliknij X w lewym górnym rogu, aby go zamknąć.

W tym momencie natychmiast przestałem otrzymywać błędy 403 i wszystko zaczęło działać zgodnie z oczekiwaniami. Dziwne jest to, że nawet nie musiałem ponownie uruchamiać apache, to po prostu działało, chyba zrestartowało się samo, kiedy poszedłem do mojego lokalnego hosta, szczerze mówiąc, nie wiem, ale chyba problem polega na tym, że Apache nie uruchamia się ponownie przy użyciu restartu apachectl lub stop lub start. Mam nadzieję, że to komuś pomoże.

RAC
źródło
1
Po godzinach zmarnowanego czasu rozwiązało to również moje problemy.
ever.wakeful
10

Problem jest w VirtualHost, ale prawdopodobnie nie jest

Wymagaj wszystkich przyznanych

Potwierdź Twój config jest poprawna, tutaj jest poprawna próbka wprowadź opis zdjęcia tutaj

Albert.Qing
źródło
Uwzględnienie <Directory ...> ... </Directory>wierszy działało dla mnie, ponieważ korzystałem ze ścieżki do katalogu, która nie była wcześniej zdefiniowana w konfiguracjach Apache wcześniej.
Don Wilson,
4

Jeśli przejrzysz dziennik błędów i ponownie załadujesz stronę, powinieneś zobaczyć więcej informacji na temat dokładnego problemu.

Chwyć zmienne środowiskowe, aby $ {APACHE_LOG_DIR} faktycznie działał ...

source /etc/apache2/envvars

Potem ogon i patrz ...

tail -f ${APACHE_LOG_DIR}/error.log
Shylo Hana
źródło
5
To jest błąd z dzienników: „AH01630: klient odmówiony przez konfigurację serwera”
Hazem Hagrass
6
Jeśli dodasz LogLevel debugdo VirtualHost, jest to dobra rada, ponieważ zobaczysz wiersze takie jak „Wymagaj wszystkich odmów: odmowa” i „<RequireAny>: odmowa” (tj. Znacznie bardziej przydatne niż tylko „klient odmówiony przez konfigurację serwera”, jak to faktycznie mówi, która konfiguracja!)
Darren Cook
4

Rozwiązałem się po kilku godzinach.

Zainstalowałem Apache / 2.4.7 (Ubuntu) poprzez coookbook w vagrant vm.

Plik /etc/apache2/apache2.conf <VirtualHost *:80>domyślnie nie ma elementu.

Zrobiłem dwie zmiany, aby to zrobić

  1. dodany <VirtualHost *:80>
  2. dodano
    Opcje Indeksy FollowSymLinks
    AllowOverride all
    Allow from all

potem w końcu właśnie uruchomiłem vm ..

Giri Babu
źródło
4

Czy ktoś myślał o tym, że domyślny serwer Wamp nie zawiera httpd-vhosts.confpliku. Moje podejście polega na usunięciu poniższej notatki

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

w httpd.confpliku To wszystko.

Heier
źródło
+1 Ten pracował dla mnie, jako dobrze, ale być może lepszym rozwiązaniem jest, aby zachować conf/extra/httpd-vhosts.confplik i zastąpić w nim Require localzRequire all granted
Alex pandrea
4

w moim przypadku,

Używam macOS Mojave (Apache / 2.4.34). Wystąpił problem z ustawieniami hosta wirtualnego w pliku /etc/apache2/extra/httpd-vhosts.conf. po dodaniu wymaganego znacznika katalogu mój problem zniknął.

Wymagaj wszystkich przyznanych

Mam nadzieję, że pełna struktura konfiguracji wirtualnego hosta cię uratuje.

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

wszystko, co musisz zrobić, zastąp nazwę MainProjectFolderName dokładną nazwą ProjectFolderName.

sh6210
źródło
2

Doprowadzało mnie to do szału. W końcu zorientowałem się, na czym polega problem: używałem bezpośrednich ścieżek do dziennika błędów i były one błędne.

Dlaczego Apache wyświetla niejasny (i zły) komunikat o błędzie? Zamiast tego użyj poprawnego i przydatnego komunikatu o błędzie, takiego jak: Ścieżka do dyrektywy ErrorLog „Nieprawidłowa ścieżka / nazwa pliku / nazwa pliku.log”

W każdym razie, aby to naprawić, upewnij się, że dyrektywy dziennika błędów wyglądają mniej więcej tak:

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
RyanNerd
źródło
2

Jeśli używasz Apache 2.4 w WampServer w systemie operacyjnym Windows.

Musisz otworzyć plik https-vhosts.conf w notatniku.

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

Jeśli nie możesz znaleźć powyższego pliku. sprawdź zrzut ekranu poniżej 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>

W powyższym kodzie Zamień

Require local

z

Require all granted

I zapisz to. Uruchom ponownie usługę Apache i spróbuj ponownie.

Dev Semicolon
źródło
1

Jeśli masz hosta https, nie zapomnij też wprowadzić Require all grantedzmian w konfiguracji ssl.

Czasami warto sprawdzić uprawnienia jako użytkownik 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
źródło
1

W przypadku Wamp 3 (Apache 2.4), oprócz przełączania serwera do trybu online zgodnie z opisem w innych odpowiedziach, w pliku Hostów wirtualnych conf/extra/httpd-vhosts.conf
może być konieczna wymiana

Require local

z

Require all granted



Ma to zastosowanie, jeśli httpd.confmasz

Include conf/extra/httpd-vhosts.conf
Alex Pandrea
źródło
1

Podczas korzystania z Ubuntu sprawdź, czy moduł CGI jest włączony. Jeśli nie:

sudo a2enmod cgi
hfmanson
źródło
Moduł CGI musiał być włączony. Program w końcu zadziałał.
Steve R.,
1

Upewnij się, że uwzględniono wszelkie konfiguracje specyficzne dla użytkownika!

Jeśli żadna z pozostałych odpowiedzi na tej stronie nie działa, oto, na co wpadłem po godzinach marszu.

Użyłem konfiguracji specyficznych dla użytkownika, z Sitesokreślonym jako mój UserDirw /private/etc/apache2/extra/httpd-userdir.conf. Jednak zabroniono mi dostępu do punktu końcowego http://localhost/~jwork/.

Widziałem, /var/log/apache2/error_logże dostęp do /Users/jwork/Sites/był blokowany. Mogłem jednak uzyskać dostęp do DocumentRoot przez http://localhost/. To sugeruje, że nie mam uprawnień do przeglądania ~jworkużytkownika. Ale o ile mogę powiedzieć przez ps aux | egrep '(apache|httpd)'i lsof -i :80, Apache został uruchomiony dla jworkużytkownika, więc coś było wyraźnie nie napisać o moim konfiguracji użytkownika.

Biorąc pod uwagę użytkownika jwork, oto mój plik konfiguracyjny:

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

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

Ta konfiguracja jest całkowicie poprawna. Stwierdziłem jednak, że moja konfiguracja użytkownika nie została uwzględniona:

/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

Zauważ, że jest to domyślna ścieżka do pliku conf userdir, ale jak zobaczysz poniżej, można ją skonfigurować w httpd.conf. Upewnij się, że następujące linie są włączone:

/private/etc/apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so
Jamie Birch
źródło
1

Dla tych, którzy utknęli na tym błędzie jak ja i nic nie pomogło z góry: sprawdź, czy folder problemów z error.log faktycznie istnieje na twoim serwerze. Mój został wygenerowany automatycznie przez Django w niewłaściwym miejscu (wtedy został pomieszany ze statycznym rootem manage.py collectstatic). Nie mam pojęcia, dlaczego nie można poprawnie nazwać błędów.

Dmitry
źródło
Dzięki za przypomnienie, żebym użył mojego mózgu, naprawiłem mój problem. +1 haha
orangecaterpillar
0

Oprócz brakujących Orderi Allowdyrektyw wymienionych w innych odpowiedziach należy pamiętać, że DirectoryMatchten błąd może również powodować niepasujące wyrażenie regularne dyrektywy.

Jeśli żądana ścieżka jest /home/user-foo1bar/www/myproject/dopasowująca, dopasowanie nie będzie zgodne

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

dlatego nawet poprawna konfiguracja dostępu może powodować ten błąd.

spróbuj złapać w końcu
źródło
0

Jedną z niejasnych (dopiero co sobie z tym poradziłem), ale możliwą do tego przyczyn, jest wewnętrzna reguła mod_rewrite w głównym pliku konfiguracyjnym (nie .htaccess), która zapisuje ścieżkę istniejącą w katalogu głównym systemu plików serwera. Załóżmy, że masz /mediakatalog w swojej witrynie i przepisujesz coś takiego:

RewriteRule /some_image.png /media/some_other_location.png

Jeśli masz /mediakatalog w katalogu głównym serwera, nastąpi próba przepisania (co spowoduje błąd odmowy dostępu) zamiast katalogu w katalogu witryny, ponieważ katalog główny systemu plików jest sprawdzany najpierw przez mod_rewrite pod kątem istnienia pierwszego katalogu na ścieżce, przed katalogiem witryny.

Nigel B. Peck
źródło
0

Problemem może być to, że dyrektywa nie znajduje się w katalogu <Directory>

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

Do dyrektywy można się odwoływać w sekcji <Katalog>, <Pliki> lub <Lokalizacja>, a także w plikach .htaccess, aby kontrolować dostęp do określonych części serwera. Dostęp można kontrolować na podstawie nazwy hosta klienta lub adresu IP.

Sérgio
źródło
0

Mam inny, który może być komuś przydatny. Otrzymywał ten sam komunikat o błędzie po aktualizacji z PHP 5.6 => 7.0. Zmieniliśmy ustawienia przesyłania PHP i zapomnieliśmy zmienić po skopiowaniu. Mimo że w tym czasie nie przesyłałem zdjęć, Silverstripe (nasz CMS) odmówił zapisania i zgłasza ten błąd. Zwiększono rozmiar przesyłanego obrazu i od razu zadziałało.

Andrew MacNaughton
źródło
0

Gdyby to pomogło komukolwiek googlować się tak jak ja, miałem ten komunikat o błędzie, próbując uzyskać dostęp do pliku SVG na moim serwerze, np . Https://example.com/images/file.svg . Inne typy plików wydawały się w porządku, tylko SVG zawiodły.

I polować wokół /etc/httpdpliki conf sprawdzana każdegorequire all denied rodzaju konfiguracji, i po prostu nie mógł znaleźć co config był o ten efekt.

Przekręciłem LogLevel do debugowania w konfiguracji VirtualHost i mogłem zobaczyć rejestrowanie mod_authz_core z podaniem, że obowiązuje „Wymagaj wszystkich odrzuconych”:

[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

Poprzez ślepe testy przeniosłem plik do katalogu głównego katalogu głównego i stwierdziłem, że mogę uzyskać do niego dostęp pod adresem https://example.com/file.svg .. więc nie udało się to tylko w folderze „images”. Doprowadziło mnie to do pliku .htaccess w folderze obrazów, o którym nie miałem pojęcia, że ​​tam jest.

Okazuje się, że Zen Cart 1.5 jest wyposażony w plik images / .htaccess, który ma:

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

To było bardzo denerwujące i mam nadzieję, że może to przypomnieć innym, aby sprawdzali pliki .htaccess na każdym poziomie systemu plików prowadzącego do pliku, do którego masz problemy z dostępem, na wypadek, gdyby trwała taka głupota.

Neek
źródło
0

Rozwiązałem ten problem, dodając dostęp do katalogu do wpisu: 80.

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

Zanim wszyscy otrzymają ode mnie „bezpieczeństwo”, w moich szczególnych okolicznościach nie jest to kwestia bezpieczeństwa.

Jeśli używasz zdalnego zasobu, zalecam zamiast tego upewnić się, że twoje żądanie CURL przechodzi przez HTTPS / TLS, a następnie ten wpis katalogu idzie na port 443.

AdheneManx
źródło
0

Ten „błąd” jest w rzeczywistości nowym normalnym zachowaniem Apache 2.4. W moim przypadku miałem bardzo szczegółową zasadę odmowy dostępu do dowolnego folderu lub pliku o nazwie zaczynającej się od „.”, Więc musiałem ustawić wyjątek dla określonego folderu publicznego, który wymaga tak nieparzystej nazwy.

Dla przypomnienia, moja szczególna zasada Przepisywania to:

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

Ta reguła [F] stosuje się do wszystkiego, zaczynając od „.” ale .trusteddzięki magii wyrażenia regularnego „?!” negacja.

develCuy
źródło
0

Ponieważ ten wątek jest pierwszą rzeczą, która pojawia się podczas wyszukiwania wspomnianego błędu, chciałbym dodać kolejną możliwą przyczynę tego błędu: możesz być mod_evasiveaktywny, a klient widzący ten błąd po prostu przekroczył limity skonfigurowane w twoimmod_evasive.conf

Jest to szczególnie ważna przyczyna do zbadania, jeśli nagle pojawia się ten błąd dla klienta, który nie miał wcześniej problemów i nic się nie zmieniło.

(jeśli mod_evasivejest to przyczyną, błąd sam zniknie, jeśli klient chwilowo przestanie próbować uzyskać dostęp do witryny; może to jednak świadczyć o tym, że skonfigurowałeś zbyt wąskie limity)

Artur
źródło