Wie behebt man 403 in Mac OS X integriertem Apache?

Ich versuche , eine lokale Umgebung auf meine neue MacBook Air 13" zu setzen: integrierten Apache mit meiner eigenen DocumentRoot, PHP und MySQL ich in der Regel aktualisieren. /etc/hostsNur meine lokalen Websites mit einem hübschen permalink auszuführen: local/example. Für Referenzen, ich in der Regel prüfen:

• Wie verwandle ich Mac OS X Lion in einen Webserver?
• Aktivieren von Apache in Mac OS X Mountaion Lion
• Apache-Berechtigungen

Dieses Mal erhalte ich einfach jedes Mal , wenn ich , oder drücke, einen 403 Forbidden- Fehler . Zuerst habe ich über das Terminal gesehen, dass sowohl Apache als auch PHP ausgeführt werden (obwohl ich keine PHP-Seiten anzeigen kann). dann habe ich alle Berechtigungen gemäß den Apache-Berechtigungen aktualisiert ; jetzt bin ich nur noch verzweifelt Hier sind die relevanten Apache-Konfigurationen:127.0.0.1localhostlocal

• /etc/hosts( Datei anzeigen - eine Zeile hinzugefügt)
• /etc/apache2/httpd.conf( Datei anzeigen - aktualisiert die DocumentRoot)
• /etc/apache2/users/joao.conf( Datei anzeigen - diese Datei erstellt)
• /etc/apache2/extra/httpd-vhosts.conf( Datei anzeigen - aktualisiert VirtualHost)

Es sieht so aus, als würde mir Apache irgendwie den Zugang zu meinem verweigern DocumentRoot(was übrigens so ist ~/Sites). Da ~/Siteses sich eigentlich um einen Symlink handelt, habe ich dann versucht, DocumentRootmit den folgenden Pfaden zu aktualisieren (alle zeigen auf dasselbe Verzeichnis):

• ~/Sites
• /Users/joao/Sites
• /Users/joao/Dropbox/Workflow/Sites(das ursprüngliche Verzeichnis)

403 immer noch werfen . Irgendwelche Ideen, wie man das behebt / debuggt?

Schnelles Update - so /var/log/apache2/joao.pt-error_logsieht mein Update aus:

[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

Ich habe in OSX Server einen Alias ​​angegeben, der auf ein Benutzerverzeichnis verweist. Ich habe lange Zeit mit _www-Benutzern gearbeitet, ausführbare Berechtigungen rekursiv hinzugefügt, Macports deinstalliert und alles Mögliche versucht, um dies zum Laufen zu bringen. Keine Ahnung, warum es nicht funktionierte.

Schließlich habe ich nur das Kontrollkästchen "Freigegebener Ordner" im Finder für diesen Ordner aktiviert und es funktionierte auf der angegebenen Domain mit aktivem PHP so, wie ich es wollte. : / ... das war also einfach.

Ich aktualisiere auf macOSS Sierra , Version 10.12

Ich habe das gleiche Problem, ich habe zwei Dinge getan, um es richtig zu beheben. Es folgen meine Ansätze.

1) Überprüfen Sie die Datei " /private/etc/apache2/extra/httpd-userdir.conf ". Veränderung

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

zu

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

2) ** Und bearbeite deine " /etc/apache2/httpd.conf"

Veränderung

Options FollowSymLinks Multiviews

zu

Options FollowSymLinks Multiviews Indexes

Schließlich sieht Ihr Doc-Root folgendermaßen aus:

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

3) Starten Sie Apache neu

sudo apachectl restart

Wenn Sie immer noch mit dem Problem konfrontiert sind, überprüfen Sie bitte, wie Sie Apache in macOS Sierra 10.12 einrichten

Ich behebe dies im Allgemeinen, indem ich den Apache-Benutzer in lokalen Umgebungen und auf Computern, auf denen der einzige Benutzer, der Apache verwendet, ich bin, auf mich selbst einstelle. In /private/etc/apache2/httpd.confsetzen Sie Userauf Ihren Benutzernamen von _wwwzB:

User _www

->

User joao

Und dann starte Apache neu:

$ sudo apachectl restart

Zusätzliche Schritte:

1. Wenn Sie aktive Sitzungen haben, geben sie Berechtigungsfehler, da sie immer noch im Besitz von sind _www. Besitze sie:

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

Implikationen:

Danach wird Apache (und PHP et al.) Wie Sie ausgeführt und erhält Lese- / Schreibberechtigung für alle Dateien, die Sie über Lese- / Schreibberechtigung verfügen. Da es sich jedoch nur um eine lokale Entwicklungsumgebung handelt, sollte dies kein Problem sein, es sei denn, Sie haben keine Regeln zum Blockieren von Apache in Ihrer Firewall und lassen fragwürdige Dateien wie Datei-Explorer, Shells und Skripte, die möglicherweise Schwachstellen enthalten, unter Apache laufen. In diesem Fall kann jeder, einschließlich Ihres öffentlichen WLAN-Nachbarn, in ein Café eintreten http://<your IP>und alles tun, was diese Skripte ihnen erlauben.

Tatsächlich sollten Sie dies unabhängig von den von Ihnen ausgeführten Skripten verhindern oder auch dann, wenn Sie den Apache-Benutzer nicht auf sich selbst festlegen, da Sie wahrscheinlich nicht möchten, dass zufällige Außenstehende den Inhalt Ihrer Skripten sehen können localhost.

Verhütung:

1. Lassen Sie Apache nur localhost hören. Wieder in httpd.conf:

   Listen 80
   

   ->

   Listen 127.0.0.1:80
   

   Und starte Apache erneut:

   $ sudo apachectl restart
   

2. Deaktivieren Sie Apache in der Anwendungsfirewall (beachten Sie, dass Sie es möglicherweise bereits deaktiviert haben, wenn Sie Denybeim ersten Ausführen von Apache auf die Frage geklickt haben ):

   1. Öffnen Sie System Preferences» Security & Privacy» Firewall.
   2. Klicken Sie auf das Schlosssymbol unten links und geben Sie bei Bedarf Ihr Passwort ein.
   3. Schalten Sie die Firewall ein, wenn sie deaktiviert ist.
   4. Klicken Sie auf Firewall Options.
   5. Klicken Sie auf die +Schaltfläche.
   6. Drücken Sie cmd ⌘+ ⇧ shift+ Gund geben Sie ein /usr/sbin/httpdund klicken Sie auf Add(Wenn httpdes dort nicht angezeigt wird, können Sie im Terminal danach suchen which httpd).
   7. Klicken Sie in der Liste auf httpdund wählen Sie Block incoming connections.
   8. Hit OK.

   9. Laden Sie die Firewall neu:

      $ 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. Beschränken Sie PHP auf das Dokumentstammverzeichnis. In php.ini:

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

   ( /var/tmp/ist für Sitzungen)

Verwenden Sie alle drei Lösungen, um sich abzusichern, falls eine aus irgendeinem Grund deaktiviert wird.

_{- Beachten Sie, dass meine aktive Sprache auf meinem Computer nicht Englisch ist und die Formulierung möglicherweise ein wenig anders ist (Menüoptionen und -formulierungen können unterschiedlich sein, unabhängig von der Sprache in verschiedenen OS X-Versionen).}

_{- Zeilen, die mit beginnen, $müssen in der Befehlszeile (Terminal oder iTerm usw.) eingegeben und $entfernt werden.}

Ich habe gerade mein Problem behoben, indem ich Berechtigungen nicht nur für das DocumentRootVerzeichnis, sondern auch für alle übergeordneten Verzeichnisse festgelegt habe. So habe ich es gemacht .

(13) Erlaubnis verweigert

Fehler 13 weist auf ein Dateisystem-Berechtigungsproblem hin. Das heißt, Apache wurde der Zugriff auf eine Datei oder ein Verzeichnis aufgrund falscher Berechtigungen verweigert. Im Allgemeinen handelt es sich nicht um ein Problem in den Apache-Konfigurationsdateien.

Um Dateien bereitzustellen, muss Apache über die vom Betriebssystem erteilte Berechtigung verfügen, auf diese Dateien zuzugreifen. Insbesondere muss der in httpd.conf angegebene Benutzer oder die Gruppe in der Lage sein, alle zu versorgenden Dateien zu lesen und das Verzeichnis mit diesen Dateien sowie alle übergeordneten Verzeichnisse bis zum Stammverzeichnis des Dateisystems zu durchsuchen.

Typische Berechtigungen auf einem Unix-ähnlichen System für Ressourcen, die nicht dem in httpd.conf angegebenen Benutzer oder der in httpd.conf angegebenen Gruppe gehören, sind 644 -rw-r - r-- für normale Dateien und 755 drwxr-xrx für Verzeichnisse oder CGI-Skripten. Möglicherweise müssen Sie auch erweiterte Berechtigungen (z. B. SELinux-Berechtigungen) auf Betriebssystemen überprüfen, die diese unterstützen.

Wenn Sie 2.4 ausführen, enthält der AH-Fehlercode hier möglicherweise weitere Informationen.

• AH00132: Dateiberechtigungen verweigern den Serverzugriff
• AH00035: Zugriff verweigert, da für eine Komponente des Pfads Suchberechtigungen fehlen. Ein Beispiel

Nehmen wir an, Sie haben auf einem Unix-ähnlichen System den Fehler "Permission Denied" erhalten, als Sie auf die Datei /usr/local/apache2/htdocs/foo/bar.html zugegriffen haben.

Überprüfen Sie zunächst die vorhandenen Berechtigungen für die Datei:

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

Repariere sie falls nötig:

chmod 644 bar.html

Machen Sie dann dasselbe für das Verzeichnis und jedes übergeordnete Verzeichnis (/ 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

Auf einigen Systemen kann das Dienstprogramm namei zum Auffinden von Berechtigungsproblemen verwendet werden, indem die Berechtigungen für jede Komponente des Pfads aufgelistet werden:

namei -m /usr/local/apache2/htdocs/foo/bar.html Wenn Ihr System keinen namei hat, können Sie parsepath verwenden. Es kann hier bezogen werden.

Wenn alle Standardberechtigungen korrekt sind und der Fehler "Berechtigung verweigert" weiterhin angezeigt wird, sollten Sie nach erweiterten Berechtigungen suchen. Mit dem Befehl setenforce 0 können Sie beispielsweise SELinux deaktivieren und überprüfen, ob das Problem behoben ist. In diesem Fall kann ls -alZ verwendet werden, um die SELinux-Berechtigung anzuzeigen, und chcon, um sie zu beheben.

In seltenen Fällen kann dies durch andere Probleme verursacht werden, z. B. durch ein Dateiberechtigungsproblem an einer anderen Stelle in Ihrer apache2.conf-Datei. Beispielsweise eine WSGIScriptAlias-Direktive, die keiner tatsächlichen Datei zugeordnet ist. Möglicherweise ist die Fehlermeldung nicht genau, welche Datei nicht lesbar war.

Setzen Sie Dateien oder Verzeichnisse NICHT in den Modus 777, auch nicht "nur zum Testen", selbst wenn "es sich nur um einen Testserver handelt". Der Zweck eines Testservers ist es, in einer sicheren Umgebung alles richtig zu machen und nicht durchzukommen, wenn etwas falsch gemacht wird. Sie erfahren nur, ob das Problem bei tatsächlich vorhandenen Dateien liegt.

CGI-Skripte

Obwohl die CGI-Skriptberechtigung möglicherweise korrekt aussieht, verfügt die im shebang angegebene Binärdatei möglicherweise nicht über die erforderlichen Berechtigungen, um ausgeführt zu werden. (Oder ein Verzeichnis auf seinem Pfad, erkundigen Sie sich bei namei, wie oben erläutert.)

(13) Berechtigung verweigert: Proxy: HTTP: Versuch, eine Verbindung zu 127.0.0.1:8080 (localhost) herzustellen, fehlgeschlagen

Bei diesem Fehler geht es nicht wirklich um Dateiberechtigungen oder ähnliches. Tatsächlich bedeutet dies, dass httpd die Berechtigung zum Herstellen einer Verbindung mit dieser IP-Adresse und diesem Port verweigert wurde.

Die häufigste Ursache hierfür ist, dass SELinux httpd nicht zulässt, Netzwerkverbindungen herzustellen.

Um dieses Problem zu beheben, müssen Sie einen SELinux-Booleschen Wert ändern (der bei Neustarts automatisch beibehalten wird). Sie können auch httpd neu starten, um den Proxy-Worker zurückzusetzen, obwohl dies nicht unbedingt erforderlich ist.

# setsebool -P httpd_can_network_connect 1

Die folgenden Schritte funktionierten für mich in High Sierra mit Apache 2.4

(Basierend auf dem folgenden hervorragenden Tutorial: http://www.cgi101.com/book/connect/mac.html , aktualisiert mit zusätzlichen Schritten für Versionsunterschiede)

1. Verschieben Sie die Datei nach:

   /Library/WebServer/CGI-Executables
   

2. Stellen Sie sicher, dass die Datei über Ausführungsberechtigungen verfügt:

   ls -l  /Library/WebServer/CGI-Executables
   

   Wenn nicht verwenden:

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

3. Kommentieren Sie die folgenden Zeilen in /etc/apache2/httpd.conf aus

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

4. Ändern Sie auch die Zeilengruppe "/ Library / WebServer / CGI-Executables" in:

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

5. Dann starte Apache neu:

   sudo apachectl -k restart
   

Fast bei jeder neuen MacOS-Version gehen die Änderungen verloren und Sie müssen die Arbeit wiederholen und sogar verschiedene Schritte ausführen, um sie zu beheben. Ihr bester Freund sind die Apache-Protokolle in / var / log / apache2 / (/ var / log / apache2 / error_log).

Ich habe Zugriffssteuerungslisten zum Festlegen von Berechtigungen verwendet. Befolgen Sie dazu die Anweisungen unter " Festlegen von Datei- und Verzeichnisberechtigungen für Apache unter Mac OS X ".

[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

Dann las ich " (13) Permission Denied " (verknüpft mit der Antwort von João Ramos ) und versuchte, der ACL "execute" hinzuzufügen. Das hat funktioniert.

Starte deinen Computer neu! Das hat bei mir funktioniert.

Aber zunächst einmal hatte ich den Benutzer unter Apache selbst verändert (von _www), da es sich um eine lokale / Testumgebung ist. Letztendlich hat es also etwas mit Berechtigungen zu tun.

Starten Sie dann den Computer wie Windows neu;).

OP beschreibt ein Problem, das beim Einrichten einer lokalen Webserver-Umgebung auf einem Mac unter Verwendung von Apache, PHP und MySQL mit einem benutzerdefinierten DocumentRoot auftritt. Außerdem wird die Verwendung von VirtualHost (vhost) erwähnt. OP meldet, dass beim Zugriff auf localhost ein 403 Forbidden-Fehler auftritt.

Ein Artikel bei coolestguidesontheplanet beschreibt, wie das Einrichten virtueller Hosts in Apache zum "Verlust von Localhost" führt. Mit anderen Worten, die Hauptursache für das OP-Problem könnte eine unvollständige Aktivierung von vhosts sein.

"Sobald [virtuelle Hosts] eingerichtet sind, verlieren Sie Ihr älteres Dokumentenstammverzeichnis, das Sie zuvor unter / Library / WebServer / Documents oder im Browser unter http: // localhost abgerufen haben. Es wird ein 403 Forbidden Error angezeigt ."

In diesem Artikel wird erläutert, wie localhost in einer vhost-Umgebung repariert wird.

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

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

Außerdem erfahren Sie, wie Sie "Berechtigungsprobleme mit Updates und Authentifizierungen" beheben, die mit "Verwenden des Ordners Users / username / Sites für vhosts" zusammenhängen.

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/