¿Cómo arreglar 403 en Mac OS X Apache incorporado?

Estoy tratando de establecer un entorno local en mi nuevo MacBook Air 13 ": Apache integrado con mi propio DocumentRootPHP y MySQL. Por lo general, actualizo /etc/hostssolo para ejecutar mis sitios web locales con un enlace permanente:. local/examplePara referencias, generalmente comprobar:

• ¿Cómo convertir Mac OS X Lion en un servidor web?
• Habilitar Apache en Mac OS X Mountaion Lion
• Permisos de Apache

Esta vez estoy simplemente conseguir una Prohibida 403 de error cada vez que me golpeó 127.0.0.1, localhosto local. Primero vi a través del terminal que tanto Apache como PHP se están ejecutando (aunque no puedo ver páginas PHP); luego actualicé todos los permisos de acuerdo con los permisos de Apache ; ahora solo estoy desesperado. Estas son las configuraciones relevantes de Apache:

• /etc/hosts( ver archivo - agregada una línea)
• /etc/apache2/httpd.conf( ver archivo - actualizado el DocumentRoot)
• /etc/apache2/users/joao.conf( ver archivo - creó este archivo)
• /etc/apache2/extra/httpd-vhosts.conf( ver archivo - actualizado VirtualHost)

Parece que Apache de alguna manera me está negando el acceso a mi DocumentRoot(que por cierto lo es ~/Sites). Debido a ~/Sitesque en realidad es un enlace simbólico, intenté actualizar DocumentRootcon las siguientes rutas (todas apuntando al mismo directorio):

• ~/Sites
• /Users/joao/Sites
• /Users/joao/Dropbox/Workflow/Sites(el directorio original )

Todavía lanzando 403 . ¿Alguna idea de cómo solucionar / depurar esto?

Actualización rápida/var/log/apache2/joao.pt-error_log : así es como se ve mi :

[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

Tengo un alias especificado en el servidor OSX que apunta a un directorio de usuarios. Pasé mucho tiempo modificando y jugando con _www usuario, agregando permisos ejecutables de forma recursiva, desinstalando macports y todo tipo de cosas tratando de hacer que esto funcione. No tengo idea de por qué no estaba funcionando.

Finalmente, acabo de marcar la casilla de verificación "carpeta compartida" en el Finder para esa carpeta, y funcionó , en el dominio especificado, con php activo, de la manera que quería. : / ... así que fue fácil.

Actualizo a macOSS Sierra , versión 10.12

Me enfrento al mismo problema, hice dos cosas para solucionarlo correctamente. Los siguientes son mis enfoques.

1) Verifique el archivo " /private/etc/apache2/extra/httpd-userdir.conf ". Cambio

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

a

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

2) ** Y edite su " /etc/apache2/httpd.conf"

cambio

Options FollowSymLinks Multiviews

a

Options FollowSymLinks Multiviews Indexes

Finalmente, la raíz de tu documento se verá así:

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

3) Reiniciar apache

sudo apachectl restart

Si aún enfrenta el problema, consulte Cómo configurar Apache en macOS Sierra 10.12

Generalmente soluciono esto configurando el usuario de Apache para mí en entornos locales y en máquinas donde el único usuario que usa Apache soy yo. En /private/etc/apache2/httpd.conf, establezca Usersu nombre de usuario _www, por ejemplo:

User _www

->

User joao

Y luego reinicie Apache:

$ sudo apachectl restart

Pasos adicionales:

1. Si tiene sesiones activas, van a dar errores de permiso ya que aún son propiedad de ellos _www. Poseerlos:

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

Trascendencia:

Después de esto, Apache (y PHP et al.) Se ejecutará como usted y obtendrá permiso de lectura / escritura para todos los archivos que tenga permiso de lectura / escritura. Pero dado que este es solo un entorno de desarrollo local, eso no debería ser un problema a menos que no tenga reglas para bloquear Apache en su firewall y permita que archivos cuestionables como exploradores de archivos, shells, scripts que puedan contener vulnerabilidades se ejecuten bajo Apache; en cuyo caso, cualquiera que incluya a su vecino wifi público en un café puede ingresar http://<your IP>y hacer lo que esos scripts le permitan hacer.

De hecho, debe evitar esto independientemente de los scripts que ejecute o incluso si no configura el usuario de Apache para usted, ya que probablemente no desee que personas externas aleatorias puedan ver el contenido de su localhost.

Prevención:

1. Haga que Apache escuche solo localhost. De nuevo en httpd.conf:

   Listen 80
   

   ->

   Listen 127.0.0.1:80
   

   Y reinicie Apache nuevamente:

   $ sudo apachectl restart
   

2. Deshabilite Apache en el firewall de la aplicación (tenga en cuenta que es posible que ya lo haya deshabilitado si hizo clic en Denysi / cuando se le preguntó durante la primera vez que ejecuta Apache):

   1. Abrir System Preferences» Security & Privacy» Firewall.
   2. Haga clic en el ícono de bloqueo en la esquina inferior izquierda e ingrese su contraseña si es necesario.
   3. Encienda el firewall si está deshabilitado.
   4. Haga clic Firewall Options.
   5. Haz clic en el +botón.
   6. Presione cmd ⌘+ ⇧ shift+ Ge ingrese /usr/sbin/httpdy haga clic Add(si httpdno aparece allí, puede buscarlo en la terminal which httpd)
   7. En la lista, haga clic httpdy seleccione Block incoming connections.
   8. Hit OK.

   9. Vuelva a cargar el firewall:

      $ 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. Restrinja PHP a la raíz del documento. En php.ini:

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

   ( /var/tmp/es para sesiones)

Use las tres soluciones para asegurarse en caso de que una de ellas se desactive por alguna razón.

_{- Tenga en cuenta que como mi idioma activo en mi máquina no es el inglés, la redacción puede ser un poco diferente (las opciones de menú y la redacción pueden ser diferentes independientemente del idioma en varias versiones de OS X).}

_{- Las líneas que comienzan con $deben ingresarse en la línea de comando (Terminal o iTerm, etc.), con el $eliminado.}

Acabo de resolver mi problema estableciendo permisos no solo para el DocumentRootdirectorio, sino también para todos sus directorios principales. Así es como lo hice .

(13) Permiso denegado

El error 13 indica un problema de permisos del sistema de archivos. Es decir, a Apache se le negó el acceso a un archivo o directorio debido a permisos incorrectos. En general, no implica un problema en los archivos de configuración de Apache.

Para servir archivos, Apache debe tener el permiso apropiado otorgado por el sistema operativo para acceder a esos archivos. En particular, el Usuario o Grupo especificado en httpd.conf debe poder leer todos los archivos que se servirán y buscar en el directorio que contiene esos archivos, junto con todos los directorios principales hasta la raíz del sistema de archivos.

Los permisos típicos en un sistema similar a Unix para recursos que no son propiedad del Usuario o Grupo especificado en httpd.conf serían 644 -rw-r - r-- para archivos ordinarios y 755 drwxr-xrx para directorios o scripts CGI. También es posible que deba verificar los permisos extendidos (como los permisos SELinux) en los sistemas operativos que los admiten.

Si está ejecutando 2.4, el código de error AH puede brindarle más información aquí.

• AH00132: los permisos de archivo deniegan el acceso al servidor
• AH00035: acceso denegado porque faltan permisos de búsqueda en un componente de la ruta Un ejemplo

Digamos que recibió el error Permiso denegado al acceder al archivo /usr/local/apache2/htdocs/foo/bar.html en un sistema similar a Unix.

Primero verifique los permisos existentes en el archivo:

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

Arreglos si es necesario:

chmod 644 bar.html

Luego haga lo mismo para el directorio y cada directorio padre (/ 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

En algunos sistemas, la utilidad namei se puede usar para ayudar a encontrar problemas de permisos enumerando los permisos a lo largo de cada componente de la ruta:

namei -m /usr/local/apache2/htdocs/foo/bar.html Si su sistema no tiene namei, puede usar parsepath. Se puede obtener desde aquí.

Si todos los permisos estándar son correctos y aún obtiene un error de Permiso denegado, debe verificar los permisos extendidos. Por ejemplo, puede usar el comando setenforce 0 para desactivar SELinux y verificar si el problema desaparece. Si es así, ls -alZ se puede usar para ver el permiso de SELinux y chcon para solucionarlos.

En casos raros, esto puede ser causado por otros problemas, como un problema de permisos de archivos en otra parte de su archivo apache2.conf. Por ejemplo, una directiva WSGIScriptAlias ​​que no se asigna a un archivo real. El mensaje de error puede no ser exacto sobre qué archivo era ilegible.

NO configure archivos o directorios en modo 777, incluso "solo para probar", incluso si "es solo un servidor de prueba". El propósito de un servidor de prueba es hacer las cosas bien en un entorno seguro, no salirse con la suya. Todo lo que le dirá es si el problema está en los archivos que realmente existen.

Guiones CGI

Aunque el permiso del script CGI puede parecer correcto, el binario real especificado en el shebang podría no tener los permisos adecuados para ejecutarse. (O algún directorio en su ruta, verifique con namei como se explicó anteriormente).

(13) Permiso denegado: proxy: HTTP: error al intentar conectarse a 127.0.0.1:8080 (localhost)

Este error no se trata realmente de permisos de archivos ni nada de eso. Lo que realmente significa es que a httpd se le ha denegado el permiso para conectarse a esa dirección IP y puerto.

La causa más común de esto es que SELinux no permite que httpd realice conexiones de red.

Para resolverlo, debe cambiar un valor booleano SELinux (que persistirá automáticamente en los reinicios). También puede reiniciar httpd para restablecer el proxy trabajador, aunque esto no es estrictamente necesario.

# setsebool -P httpd_can_network_connect 1

Los siguientes pasos me funcionaron en High Sierra con Apache 2.4

(Basado en el siguiente excelente tutorial: http://www.cgi101.com/book/connect/mac.html , actualizado con pasos adicionales para las diferencias de versión)

1. Mueva el archivo a:

   /Library/WebServer/CGI-Executables
   

2. Verifique que el archivo tenga permisos de ejecución:

   ls -l  /Library/WebServer/CGI-Executables
   

   Si no usa:

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

3. Descomente las siguientes líneas en /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. Cambie también la sección del directorio "/ Library / WebServer / CGI-Executables" a:

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

5. Luego reinicie Apache:

   sudo apachectl -k restart
   

Casi con cada nueva versión de macOS, los cambios se perderán y tendrá que rehacer el trabajo e incluso realizar diferentes pasos para solucionarlo. Su mejor amigo son los registros de Apache ubicados en / var / log / apache2 / (/ var / log / apache2 / error_log)

Estaba usando ACL para establecer permisos, siguiendo las instrucciones en " Cómo configurar permisos de archivos y directorios para Apache en Mac OS X ", pero aún obtenía:

[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

Luego leí " (13) Permiso denegado " (vinculado a la respuesta de João Ramos ) e intenté agregar "ejecutar" a la ACL. Eso funciono.

¡Reinicia tu computadora! Esto funcionó para mí.

Pero antes que nada, había cambiado el usuario en Apache a mí mismo (de _www), ya que es un entorno local / de prueba. Entonces, en última instancia, tiene algo que ver con los permisos.

Luego reinicie la máquina, al igual que Windows;).

OP describe un problema que surge al intentar configurar un entorno de servidor web local en una Mac, usando Apache, PHP y MySQL, con un DocumentRoot personalizado, e incluye una mención del uso de VirtualHost (vhost). OP informa que obtiene un error prohibido 403 al acceder a localhost.

Un artículo en coolestguidesontheplanet describe cómo la configuración de hosts virtuales en Apache provoca la "pérdida de host local". En otras palabras, la causa raíz del problema del OP podría ser una habilitación incompleta de vhosts.

"Una vez que [los hosts virtuales están] configurados, pierdes la raíz de tu documento anterior anteriormente en / Library / WebServer / Documents o accedes en el navegador en http: // localhost : obtienes un error prohibido 403".

El artículo continúa explicando cómo reparar localhost en un entorno vhost.

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

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

También explica cómo solucionar "problemas de permisos con cosas como actualizaciones y autenticación" asociados con "el uso de la carpeta Usuarios / nombre de usuario / Sitios para vhosts".

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/