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

Acabo de resolver mi problema configurando los permisos no solo para el directorio DocumentRoot , sino también para todos sus directorios principales. Esto es cómo 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 adecuado 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 los contiene, 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 comunes y 755 drwxr-xrx para directorios o scripts CGI . Es posible que también deba verificar los permisos extendidos (como los permisos de SELinux) en los sistemas operativos que los admiten.

     

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

     

• AH00132: los permisos de archivos niegan 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 de 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

  

Corríjalos 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 al enumerar 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 nombre, puede usar parsepath. Se puede obtener desde aquí.

     

Si todos los permisos estándar son correctos y aún recibe 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 los permisos 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 no se asigna a un archivo real. Es posible que el mensaje de error no sea exacto sobre qué archivo era ilegible.

     

NO configure los archivos o directorios en el 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 es con los archivos que realmente existen.

     

scripts 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: intento de conexión a 127.0.0.1:8080 (localhost) fallido

     

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

     

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

     

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

     

# setsebool -P httpd_can_network_connect 1

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

Eventualmente, 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 forma que quería. : / ... así que fue fácil.

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

User _www

- >

User joao

Y luego reinicie Apache:

$ sudo apachectl restart

Pasos adicionales:

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

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

Implicaciones:

Después de esto, Apache (y PHP et al.) se ejecutarán como usted y obtendrán permiso de lectura / escritura para todos los archivos que tengan permiso de lectura / escritura. Pero como este es solo un entorno de desarrollo local, no debería ser un problema a menos que no tenga reglas para bloquear Apache en su firewall y permita que los archivos cuestionables, como exploradores de archivos, shells, scripts que pueden contener vulnerabilidades corre 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, deberías evitar esto independientemente de los scripts que ejecutes, o incluso si no configuras el usuario de Apache para ti mismo, ya que probablemente no quieras que personas ajenas al azar puedan ver el contenido de tu localhost .

Prevention:

1. Haz que Apache escuche solo a localhost. De nuevo, en httpd.conf :

   Listen 80
   

   - >

   Listen 127.0.0.1:80
   

   Y reinicie Apache de nuevo:

   $ sudo apachectl restart
   

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

   1. Abrir System Preferences » Security & Privacy » Firewall .
   2. Haga clic en el icono de candado en la esquina inferior izquierda e ingrese su contraseña si es necesario.
   3. Active el firewall si está desactivado.
   4. Haz clic en Firewall Options .
   5. Haz clic en el botón + .
   6. Presione cmd ⌘ + ⇧ shift + G e ingrese /usr/sbin/httpd y haga clic en Add (Si httpd no lo hace Aparece allí, puedes buscarlo en el terminal por which httpd )
   7. En la lista, haga clic en httpd y seleccione Block incoming connections .
   8. Pulsa OK .

   9. Vuelve 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 protegerse en caso de que una de ellas se deshabilite por alguna razón.

_{: tenga en cuenta que como mi idioma activo en mi máquina no es el inglés, las palabras pueden ser un poco diferentes (las opciones de menú y las palabras 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 comandos (Terminal o iTerm, etc.), con el $ eliminado.}

Actualizo a macOSS Sierra , Versión 10.12

Me enfrento al mismo problema, hice dos cosas para solucionarlo correctamente. Siguiendo 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 edita tu " /etc/apache2/httpd.conf"

cambiar

Options FollowSymLinks Multiviews

a

Options FollowSymLinks Multiviews Indexes

Finalmente, la raíz de tu documento tendrá el siguiente aspecto,

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

3) Reinicia Apache

sudo apachectl restart

Aún enfrentando el problema, por favor verifique Cómo configurar Apache en macOS Sierra 10.12

Los siguientes pasos me funcionaron en High Sierra con Apache 2.4

(Basado en el excelente tutorial siguiente: enlace , actualizado con pasos adicionales para las diferencias de versión)

1. Mueve 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 se 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. También cambie la stanza "/ Library / WebServer / CGI-Executables" del Directorio 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 sigue obteniendo:

[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 en respuesta de João Ramos ) e intentó agregar "ejecutar" a la ACL. Eso funcionó.