30 votos

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

Estoy tratando de establecer un entorno local en mi nuevo Macbook Air 13": Apache incorporado con mi propio DocumentRoot , PHP, y MySQL. Suelo actualizar /etc/hosts sólo para ejecutar mis sitios web locales con un bonito permalink: local/example . En cuanto a las referencias, suelo comprobarlas:

Esta vez simplemente estoy recibiendo un 403 Prohibido error cada vez que pulso 127.0.0.1 , localhost o local . Primero vi a través del terminal que tanto Apache como PHP se están ejecutando (aunque no puedo ver las páginas de PHP); luego actualicé todos los permisos de acuerdo a Permisos de Apache Ahora estoy desesperado. Aquí están las configuraciones relevantes de Apache:

  • /etc/hosts ( ver archivo - se ha añadido una línea)
  • /etc/apache2/httpd.conf ( ver archivo - actualizó 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 me está negando de alguna manera el acceso a mi DocumentRoot (que por cierto es ~/Sites ). Porque ~/Sites es en realidad un enlace simbólico, entonces traté de actualizar DocumentRoot con las siguientes rutas (todas apuntan al mismo directorio):

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

Sigue lanzando 403 . ¿Alguna idea de cómo arreglar/depurar esto?

Actualización rápida - esto es lo que mi /var/log/apache2/joao.pt-error_log parece:

[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

25voto

user3481991 Puntos 91

Tengo un alias especificado en el servidor de OSX que apunta a un directorio de usuario. Pasé un largo tiempo chmodding y jugando con el usuario _www, añadiendo permisos ejecutables de forma recursiva, desinstalando macports y todo tipo de cosas tratando de conseguir que esto funcione. Ni idea de por qué no funcionaba.

Al final, Acabo de marcar la casilla "carpeta compartida" en el Finder para esa carpeta, y ha funcionado ...en el dominio especificado, con php activo, de la manera que yo quería. :/ ...así que fue fácil.

0 votos

A mí no me funcionó. He creado una carpeta /Sites (en mi Root / ) y puse mis archivos allí, configurando las opciones de Alias y Directorio en consecuencia. Funcionó bien.

18voto

Halil Özgür Puntos 141

Generalmente lo soluciono poniendo como usuario de Apache a mi mismo en entornos locales y en máquinas donde el único usuario que usa Apache soy yo. En /private/etc/apache2/httpd.conf , set User a su nombre de usuario de _www Por ejemplo:

User _www

->

User joao

Y luego reiniciar Apache:

$ sudo apachectl restart

Pasos adicionales:

  1. Si tienes sesiones activas, van a dar errores de permiso ya que siguen siendo propiedad de _www . Poseerlos:

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

Implicaciones:

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 como esto es sólo un entorno de desarrollo local, eso no debería ser un problema a menos que no tengas reglas para bloquear Apache en tu firewall y dejar que archivos dudosos como exploradores de archivos, shells, scripts que puedan contener vulnerabilidades se ejecuten bajo Apache; en cuyo caso cualquiera, incluyendo su vecino de wifi público en un café, puede entrar http://<your IP> y hacer lo que esos scripts les permitan hacer.

De hecho, deberías prevenir esto independientemente de los scripts que ejecutes o incluso si no estableces el usuario de Apache como tú mismo, ya que probablemente no quieres que personas ajenas al azar puedan ver el contenido de tu localhost .

La prevención:

  1. Hacer que Apache escuche sólo a localhost. De nuevo, en httpd.conf :

    Listen 80

    ->

    Listen 127.0.0.1:80

    Y vuelve a reiniciar Apache:

    $ sudo apachectl restart
  2. Desactive Apache en el cortafuegos de aplicaciones (tenga en cuenta que es posible que ya lo haya desactivado si ha hecho clic en Deny si/cuando se le preguntó durante la primera vez que ejecutó Apache):

    1. Abrir System Preferences " Security & Privacy " Firewall .
    2. Haga clic en el icono del candado situado en la parte inferior izquierda e introduzca su contraseña si es necesario.
    3. Activa el cortafuegos si está desactivado.
    4. Haga clic en Firewall Options .
    5. Haga clic en el botón + botón.
    6. Golpea cmd + shift + G e introduzca /usr/sbin/httpd y haga clic en Add (Si httpd no aparece allí, puede buscarlo en el terminal mediante which httpd )
    7. En la lista, haga clic en httpd y seleccione Block incoming connections .
    8. Golpea OK .
    9. Vuelva a cargar el cortafuegos:

      $ 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. Restringir PHP a root del documento. En php.ini :

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

    ( /var/tmp/ es para las sesiones)

Utiliza las tres soluciones para asegurarte 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 ahora mismo, la redacción puede ser un poco diferente (las opciones del menú y la redacción pueden ser diferentes independientemente del idioma en varias versiones de OS X).

- Las líneas que empiezan por <code>$</code> deben introducirse en la línea de comandos (Terminal o iTerm, etc.), con el <code>$</code> eliminado.

0 votos

Confirmo que cambiando "Usuario" por mi nombre de usuario y "Grupo" por "personal" se ha solucionado el error 403 con XAMPP 7.1 en MacOS Big Sur

0 votos

También confirmar que el cambio de "Usuario" a mi nombre de usuario y "Grupo" a "personal" resuelto el 403, MacOS Big Sur, apache instalado a través de brew. (También he establecido permisos en la carpeta www y compartido (en Finder) antes de que, que mayo han ayudado). Muchas gracias. z

13voto

Rakesh James Puntos 211

Actualizo a macOSS Sierra , Versión 10.12

Me encuentro con el mismo problema, hice dos cosas para solucionarlo correctamente. Lo siguiente es mi enfoque.

1) Por favor, compruebe " /privado/etc/apache2/extra/httpd-userdir.conf ". Cambiar

#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 su doc Root tendrá el siguiente aspecto,

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 todavía tiene problemas, por favor, compruebe Cómo configurar Apache en MacOS Sierra 10.12

5voto

John Doucette Puntos 199

Acabo de resolver mi problema configurando los permisos no sólo para el DocumentRoot sino también a todos sus directorios padre. 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 ha denegado el acceso a un fichero o directorio debido a unos permisos incorrectos. En general, no implica un problema en los archivos de configuración de Apache.

Para poder 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 ser capaz de leer todos los archivos que serán servidos y buscar en el directorio que contiene esos archivos, junto con todos los directorios padre hasta root del sistema de archivos.

Los permisos típicos en un sistema tipo unix para los 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-x-r-x para directorios o CGI scripts. También puede ser necesario comprobar los permisos extendidos (como los permisos SELinux) en los sistemas operativos que los soportan.

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

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

Supongamos que ha recibido el error Permission Denied al acceder al archivo /usr/local/apache2/htdocs/foo/bar.html en un sistema tipo unix.

Primero compruebe los permisos existentes en el archivo:

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

Arréglelos si es necesario:

chmod 644 bar.html

A continuación, haga lo mismo con el directorio y con 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 puede ser utilizada para ayudar a encontrar problemas de permisos, listando 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 utilizar parsepath. Se puede obtener desde aquí.

Si todos los permisos estándar son correctos y sigue obteniendo un error de Permiso Denegado, debería comprobar los permisos extendidos. Por ejemplo, puede utilizar el comando setenforce 0 para desactivar SELinux y comprobar si el problema desaparece. Si es así, se puede usar ls -alZ para ver los permisos de SELinux y chcon para arreglarlos.

En casos raros, esto puede ser causado por otros problemas, como un problema de permisos de archivo en otra parte de su archivo apache2.conf. Por ejemplo, una directiva WSGIScriptAlias que no está asignada a un archivo real. El mensaje de error puede no ser exacto en cuanto a qué archivo es ilegible.

NO ponga los archivos o directorios en modo 777, incluso "sólo para probar", aunque "sólo sea 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 haciéndolo mal. Lo único que te dirá es si el problema es con archivos que realmente existen.

CGI scripts

Aunque el permiso CGI script puede parecer correcto, el binario real especificado en el shebang puede no tener los permisos adecuados para ser ejecutado. (O algún directorio en su ruta, compruebe con namei como se ha explicado anteriormente).

(13)Permiso denegado: proxy: HTTP: intento de conexión a 127.0.0.1:8080 (localhost) fallido

Este error no tiene que ver con los permisos de los archivos ni nada parecido. 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 haga conexiones de red.

Para resolverlo, necesitas cambiar un valor booleano de SELinux (que persistirá automáticamente a través de 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

1 votos

¿Podría resumir los puntos básicos en su respuesta? Gracias.

2 votos

Conceder acceso a todo su directorio padre sería una enorme ¡infracción de seguridad!

1 votos

Esta respuesta no es útil. La solución funciona para máquinas / configuraciones linux. OSX tiene una estructura de directorios diferente, especialmente para apache (ubicado en /Library/WebServer) la solución dada no es para OSx, como lo hace el apple.stackexchange.

4voto

Rouke Puntos 41

Los siguientes pasos me han funcionado 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. Mueve el archivo a:

    /Library/WebServer/CGI-Executables
  2. Verifique que el archivo tiene 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. Además, cambie la estrofa del directorio "/Library/WebServer/CGI-Executables" por:

    <Directory "/Library/WebServer/CGI-Executables">
     AllowOverride None
     Options ExecCGI
     Require all granted
    </Directory>
  5. A continuación, reinicie Apache:

    sudo apachectl -k restart

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

1 votos

No es una respuesta sino una observación. #Instrucción número 1 de arriba: Mover el archivo a: ¿Qué archivo?

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X