Jak naprawić błąd 403 we wbudowanym Apache Mac OS X?

Próbuję ustawić lokalnego środowiska na mój nowy MacBook Air 13" : wbudowany Apache z własną rękę DocumentRoot, PHP i MySQL zwykle zaktualizować. /etc/hostsWystarczy uruchomić moje lokalne strony z ładną odnośnik: local/example. Dla odniesienia, zwykle czek:

• Jak zamienić Mac OS X Lion w serwer WWW?
• Włączanie Apache w Mac OS X Mountaion Lion
• Uprawnienia Apache

Tym razem ja po prostu się 403 Zakazane błąd za każdym razem uderzę 127.0.0.1, localhostalbo local. Najpierw zobaczyłem w terminalu, że zarówno Apache, jak i PHP działają (chociaż nie mogę przeglądać stron PHP); następnie zaktualizowałem wszystkie uprawnienia zgodnie z uprawnieniami Apache ; teraz jestem po prostu zdesperowany. Oto odpowiednie konfiguracje Apache:

• /etc/hosts( wyświetl plik - dodano jedną linię)
• /etc/apache2/httpd.conf( wyświetl plik - zaktualizowano DocumentRoot)
• /etc/apache2/users/joao.conf( wyświetl plik - utworzono ten plik)
• /etc/apache2/extra/httpd-vhosts.conf( wyświetl plik - zaktualizowano VirtualHost)

Wygląda na to, że Apache w jakiś sposób odmawia mi dostępu do mojego DocumentRoot(co przy okazji jest ~/Sites). Ponieważ ~/Sitestak naprawdę jest dowiązaniem symbolicznym, próbowałem zaktualizować DocumentRootza pomocą następujących ścieżek (wszystkie wskazujące na ten sam katalog):

• ~/Sites
• /Users/joao/Sites
• /Users/joao/Dropbox/Workflow/Sites( oryginalny katalog)

Nadal rzucam 403 . Wszelkie pomysły, jak to naprawić / debugować?

Szybka aktualizacja - oto jak /var/log/apache2/joao.pt-error_logwyglądam:

[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to / denied
[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:47 2013] [error] [client ::1] (13)Permission denied: access to / denied
[Sun Jul 07 12:50:47 2013] [error] [client ::1] (13)Permission denied: access to / denied
[Sun Jul 07 12:50:48 2013] [error] [client ::1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:48 2013] [error] [client ::1] (13)Permission denied: access to /favicon.ico denied

Mam określony alias na serwerze OSX wskazujący katalog użytkownika. Długo spędziłem czas na chmodding i bawiąc się z użytkownikiem _www, rekurencyjnie dodając uprawnienia do plików wykonywalnych, odinstalowując Macports i wiele innych rzeczy próbujących to uruchomić. Nie mam pojęcia, dlaczego to nie działało.

W końcu po prostu zaznaczyłem pole wyboru „folder współdzielony” w Finderze dla tego folderu i działało ono w określonej domenie z aktywnym php, tak jak tego chciałem. : / ... więc to było łatwe.

Aktualizuję do macOSS Sierra , wersja 10.12

Mam do czynienia z tym samym problemem, zrobiłem dwie rzeczy, aby to naprawić poprawnie. Oto moje podejście.

1) Sprawdź plik „ /private/etc/apache2/extra/httpd-userdir.conf ”. Zmiana

#Include /private/etc/apache2/users/*.conf

do

Include /private/etc/apache2/users/*.conf

2) ** I edytuj swoje „ /etc/apache2/httpd.conf”

zmiana

Options FollowSymLinks Multiviews

do

Options FollowSymLinks Multiviews Indexes

w końcu Twój katalog główny będzie wyglądał następująco:

DocumentRoot "/Library/WebServer/Documents"
<Directory "/Library/WebServer/Documents">
Options FollowSymLinks Multiviews Indexes
MultiviewsMatch Any
AllowOverride All
Require all granted

3) Uruchom ponownie apache

sudo apachectl restart

Nadal masz problem, sprawdź, jak skonfigurować Apache w systemie macOS Sierra 10.12

Zazwyczaj naprawiam to, ustawiając użytkownika Apache dla siebie w środowiskach lokalnych i na komputerach, na których jedynym użytkownikiem, który używa Apache, jestem ja. W /private/etc/apache2/httpd.confustaw Userswoją nazwę użytkownika z _wwwnp .:

User _www

->

User joao

Następnie uruchom ponownie Apache:

$ sudo apachectl restart

Dodatkowe kroki:

1. Jeśli masz aktywne sesje, będą dawać błędy uprawnień, ponieważ nadal są własnością _www. Posiadaj je:

   $ sudo chown joao: /var/tmp/sess_*
   

Implikacje:

Następnie Apache (i PHP i in.) Będą działać tak jak Ty i uzyskają uprawnienia do odczytu / zapisu do wszystkich plików, które masz uprawnienia do odczytu / zapisu. Ale ponieważ jest to tylko lokalne środowisko programistyczne, nie powinno to stanowić problemu, chyba że nie masz reguł blokujących Apache w swojej zaporze ogniowej i nie zezwalasz, aby pod Apache działały podejrzane pliki, takie jak eksploratory plików, powłoki, skrypty; w takim przypadku każdy, w tym twój publiczny sąsiad Wi-Fi w kawiarni, może wejść http://<your IP>i zrobić wszystko, na co pozwalają te skrypty.

W rzeczywistości powinieneś temu zapobiec bez względu na uruchamiane skrypty, a nawet jeśli nie ustawisz dla siebie użytkownika Apache, ponieważ prawdopodobnie nie chcesz, aby przypadkowi ludzie mogli widzieć jego zawartość localhost.

Zapobieganie:

1. Niech Apache nasłuchuje tylko hosta lokalnego. Ponownie w httpd.conf:

   Listen 80
   

   ->

   Listen 127.0.0.1:80
   

   I uruchom ponownie Apache ponownie:

   $ sudo apachectl restart
   

2. Wyłącz Apache w zaporze aplikacji (zwróć uwagę, że mogłeś już go wyłączyć, jeśli kliknąłeś, Denyjeśli / kiedy został on zapytany przy pierwszym uruchomieniu Apache):

   1. Otwórz System Preferences» Security & Privacy» Firewall.
   2. Kliknij ikonę kłódki w lewym dolnym rogu i w razie potrzeby wprowadź hasło.
   3. Włącz zaporę, jeśli jest wyłączona.
   4. Kliknij Firewall Options.
   5. Kliknij +przycisk.
   6. Naciśnij cmd ⌘+ ⇧ shift+ Gi wejdź /usr/sbin/httpdi kliknij Add(jeśli httpdsię tam nie pojawi, możesz poszukać go w terminalu przez which httpd)
   7. Na liście kliknij httpdi wybierz Block incoming connections.
   8. Hit OK.

   9. Załaduj ponownie zaporę:

      $ launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
      $ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist
      $ launchctl load /System/Library/LaunchAgents/com.apple.alf.useragent.plist
      $ sudo launchctl load /System/Library/LaunchDaemons/com.apple.alf.agent.plist
      

3. Ogranicz PHP do katalogu głównego dokumentu. W php.ini:

   open_basedir = /Users/joao/Sites/:/var/tmp/
   

   ( /var/tmp/dotyczy sesji)

Użyj wszystkich trzech rozwiązań, aby zabezpieczyć się na wypadek, gdyby jedno z nich zostało wyłączone z jakiegoś powodu.

_{- Należy pamiętać, że ponieważ mój aktywny język na moim komputerze nie jest w języku angielskim, dobrze wiem, sformułowanie może być nieco inne (opcje menu i brzmienie mogą być różne niezależnie od języka w różnych wersjach systemu OS X).}

_{- Linie zaczynające się od $muszą zostać wprowadzone w wierszu poleceń (Terminal lub iTerm itp.), Z $usuniętymi.}

Właśnie rozwiązałem mój problem, ustawiając uprawnienia nie tylko do DocumentRootkatalogu, ale także do wszystkich jego katalogów nadrzędnych. Tak to zrobiłem .

(13) Odmowa zezwolenia

Błąd 13 wskazuje na problem z uprawnieniami systemu plików. Oznacza to, że Apache odmówiono dostępu do pliku lub katalogu z powodu niepoprawnych uprawnień. Zasadniczo nie oznacza to problemu w plikach konfiguracyjnych Apache.

Aby udostępniać pliki, Apache musi mieć odpowiednie uprawnienia przyznane przez system operacyjny na dostęp do tych plików. W szczególności użytkownik lub grupa określone w httpd.conf muszą być w stanie odczytać wszystkie pliki, które będą obsługiwane, i przeszukać katalog zawierający te pliki, wraz ze wszystkimi katalogami nadrzędnymi aż do katalogu głównego systemu plików.

Typowe uprawnienia w systemie uniksowym dla zasobów, które nie są własnością użytkownika lub grupy określone w httpd.conf, to 644 -rw-r - r-- dla zwykłych plików i 755 drwxr-xrx dla katalogów lub skryptów CGI. Konieczne może być również sprawdzenie rozszerzonych uprawnień (takich jak uprawnienia SELinux) w systemach operacyjnych, które je obsługują.

Jeśli korzystasz z wersji 2.4, kod błędu AH może dać ci więcej informacji tutaj.

• AH00132: uprawnienia do plików odmawiają dostępu do serwera
• AH00035: odmowa dostępu, ponieważ brakuje uprawnień do wyszukiwania w komponencie ścieżki Przykład

Powiedzmy, że wystąpił błąd odmowy dostępu podczas uzyskiwania dostępu do pliku /usr/local/apache2/htdocs/foo/bar.html w systemie uniksopodobnym.

Najpierw sprawdź istniejące uprawnienia do pliku:

cd /usr/local/apache2/htdocs/foo
ls -l bar.htm

Napraw je, jeśli to konieczne:

chmod 644 bar.html

Następnie zrób to samo dla katalogu i każdego katalogu nadrzędnego (/ usr / local / apache2 / htdocs / foo, / usr / local / apache2 / htdocs, / usr / local / apache2, / usr / local, / usr):

ls -la
chmod +x .
cd ..
# repeat up to the root

W niektórych systemach można użyć nazwy narzędzia, aby pomóc w znalezieniu problemów z uprawnieniami, wymieniając uprawnienia wzdłuż każdego komponentu ścieżki:

namei -m /usr/local/apache2/htdocs/foo/bar.html Jeśli twój system nie ma namei, możesz użyć parsepath. Można go uzyskać stąd.

Jeśli wszystkie standardowe uprawnienia są prawidłowe i nadal pojawia się błąd Odmowa zezwolenia, należy sprawdzić, czy nie ma uprawnień rozszerzonych. Na przykład możesz użyć polecenia setenforce 0, aby wyłączyć SELinux i sprawdzić, czy problem zniknie. Jeśli tak, można użyć ls -alZ, aby wyświetlić uprawnienia SELinux i chcieć je naprawić.

W rzadkich przypadkach może to być spowodowane innymi problemami, takimi jak problem z uprawnieniami do plików w innym miejscu pliku apache2.conf. Na przykład dyrektywa WSGIScriptAlias ​​nie jest mapowana na rzeczywisty plik. Komunikat o błędzie może nie być dokładny w odniesieniu do tego, który plik był nieczytelny.

NIE ustawiaj plików ani katalogów w tryb 777, nawet „tylko w celu przetestowania”, nawet jeśli „to tylko serwer testowy”. Celem serwera testowego jest poprawne działanie w bezpiecznym środowisku, a nie unikanie błędnego działania. Powie ci tylko, czy problem dotyczy plików, które faktycznie istnieją.

Skrypty CGI

Chociaż uprawnienie do skryptu CGI może wyglądać poprawnie, rzeczywisty plik binarny określony w shebang może nie mieć odpowiednich uprawnień do uruchomienia. (Lub jakiś katalog na swojej ścieżce, sprawdź w namei jak wyjaśniono powyżej.)

(13) Odmowa dostępu: proxy: HTTP: próba połączenia z 127.0.0.1:8080 (localhost) nie powiodła się

Ten błąd tak naprawdę nie dotyczy uprawnień do plików ani nic podobnego. W rzeczywistości oznacza to, że httpd odmówiono zgody na połączenie z tym adresem IP i portem.

Najczęstszą przyczyną tego jest to, że SELinux nie zezwala httpd na nawiązywanie połączeń sieciowych.

Aby rozwiązać ten problem, musisz zmienić wartość logiczną SELinux (która będzie automatycznie utrzymywana podczas restartów). Możesz także zrestartować httpd, aby zresetować proces roboczy proxy, chociaż nie jest to bezwzględnie wymagane.

# setsebool -P httpd_can_network_connect 1

Poniższe kroki działały dla mnie na High Sierra z uruchomionym Apache 2.4

(Na podstawie następującego doskonałego samouczka: http://www.cgi101.com/book/connect/mac.html , zaktualizowano o dodatkowe kroki dotyczące różnic wersji)

1. Przenieś plik do:

   /Library/WebServer/CGI-Executables
   

2. Sprawdź, czy plik ma uprawnienia do wykonywania:

   ls -l  /Library/WebServer/CGI-Executables
   

   Jeśli nie, użyj:

   chmod -x  /Library/WebServer/CGI-Executables/myfile.cgi
   

3. Odkomentuj następujące wiersze w /etc/apache2/httpd.conf

   AddHandler cgi-script .cgi .pl
   
   AddType text/html .shtml
   AddOutputFilter INCLUDES .shtml
   
   LoadModule cgi_module libexec/apache2/mod_cgi.so
   

4. Zmień także sekcję Katalog „/ Library / WebServer / CGI-Executables” na:

   <Directory "/Library/WebServer/CGI-Executables">
    AllowOverride None
    Options ExecCGI
    Require all granted
   </Directory>
   

5. Następnie uruchom ponownie Apache:

   sudo apachectl -k restart
   

Niemal z każdą nową wersją systemu macOS zmiany zostaną utracone i konieczne będzie ponowne wykonanie pracy, a nawet wykonanie różnych kroków w celu jej naprawy. Twoim najlepszym przyjacielem są dzienniki Apache znajdujące się w / var / log / apache2 / (/ var / log / apache2 / error_log)

Korzystałem z list ACL do ustawiania uprawnień, postępując zgodnie z instrukcjami w „ Jak ustawić uprawnienia do plików i katalogów dla Apache w Mac OS X ”, ale nadal otrzymuję:

[Wed Feb 12 15:43:51 2014] [error] [client ::1] (13)Permission denied: access to /trace/trace.php denied (filesystem path '/Library/WebServer/Documents/trace/trace.php') because search permissions are missing on a component of the path

Potem przeczytałem „ (13) Odmowa dostępu ” (do której link znajduje się w odpowiedzi João Ramosa ) i próbowałem dodać „wykonanie” do ACL. To się udało.

Zrestartuj swój komputer! To zadziałało dla mnie.

Ale przede wszystkim zmieniłem użytkownika pod Apache na siebie (z _www), ponieważ jest to środowisko lokalne / testowe. Ostatecznie ma to coś wspólnego z uprawnieniami.

Następnie uruchom ponownie komputer, podobnie jak Windows;).

OP opisuje problem powstający podczas próby skonfigurowania lokalnego środowiska serwera WWW na komputerze Mac przy użyciu Apache, PHP i MySQL z niestandardowym DocumentRoot, a także wzmiankę o korzystaniu z VirtualHost (vhost). OP zgłasza błąd 403 Forbidden podczas uzyskiwania dostępu do localhost.

Artykuł w coolestguidesontheplanet opisuje, w jaki sposób konfiguracja wirtualnych hostów w Apache powoduje „utratę lokalnego hosta”. Innymi słowy, podstawową przyczyną problemu OP może być niepełne włączenie vhostów.

„Po skonfigurowaniu [wirtualnych hostów] utracisz swój starszy katalog główny wcześniej w / Library / WebServer / Documents lub dostęp do przeglądarki w http: // localhost - otrzymujesz błąd 403.”

W artykule wyjaśniono, jak naprawić localhost w środowisku vhost.

Add these lines to file /etc/apache2/extra/httpd-vhosts.conf:

   <VirtualHost *:80> 
   ServerName localhost 
   DocumentRoot /Library/WebServer/Documents/ 
   </VirtualHost>

Wyjaśnia także, jak rozwiązać „problemy z uprawnieniami związane z aktualizacjami i uwierzytelnianiem” związane z „korzystaniem z folderu Users / username / Sites dla vhostów”.

Instead of using the default UID _www, use your own User and Group.

In the terminal, enter command 

    id

Find your UID and GID. 
Update file httpd.conf
In section <IfModule unixd_module>
Change User and Group to your local UID and GID.

https://coolestguidesontheplanet.com/set-virtual-hosts-apache-mac-osx-10-10-yosemite/