Apache2 userdir habilitado, pero aún no tiene acceso

9

Estoy tratando de configurar un servidor apache en mi computadora portátil Kubuntu 13.04. He instalado el paquete apache2 y sudo a2enmod userdir; sudo service apache2 restart, aún cuando lo visito http://localhost/~user, dice algo como esto:

Forbidden

You don't have permission to access /~user on this server.

Apache/2.2.22 (Ubuntu) Server at localhost Port 80

Consecuencia de tail /var/log/apache2/access.log

127.0.0.1 - - [02/Aug/2013:16:22:01 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:16:22:02 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:35:30 +0200] "GET /~kaiyin HTTP/1.1" 403 501 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:35:30 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:35:30 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:36:26 +0200] "GET /favicon.ico HTTP/1.1" 404 499 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:36:26 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:21:05:17 +0200] "GET /~kaiyin HTTP/1.1" 403 501 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:21:05:17 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:21:05:17 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"

Consecuencia de tail /var/log/apache2/error.log

[Fri Aug 02 21:05:17 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:05:17 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:06:54 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:06:54 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:06:59 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /~kaiyin denied
[Fri Aug 02 21:06:59 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:06:59 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:07:17 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /~kaiyin denied
[Fri Aug 02 21:07:17 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:07:17 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
qed
fuente
¿Tienes un public_htmldirectorio para el usuario? ¿El usuario que ejecuta apache tiene permiso para leerlo?
jordanm
@jordanm Sí, lo configuré en 755, también probé 777.
qed el

Respuestas:

8

Los public_htmldirectorios deben tener sus permisos de esta manera para que el usuario que está ejecutando Apache pueda acceder a él:

$ chmod -R 755 ~/public_html

todavía no funciona?

Si observa los registros de errores de Apache, es posible que vea una línea como esta:

[Vie 02 de agosto 21:06:59 2013] [error] [cliente 127.0.0.1] (13) Permiso denegado: acceso a / ~ kaiyin denegado

Esto le dice que Apache no tiene permisos para navegar al directorio de su usuario (~ kaiyin) en este ejemplo.

¿Cómo arreglar esto?

Debe asegurarse de que los bits de lectura + ejecución estén configurados para un grupo del que Apache es miembro o que los demás bits de lectura + ejecución estén configurados en el directorio del usuario para que Apache pueda acceder a la public_htmlcarpeta que se encuentra debajo.

Ejemplo

/home
|-- [drwxr-x---]  /home/sam

/home/sam
|-- [drwxr-xr-x]  /home/sam/public_html

Referencias

slm
fuente
Ya lo hice, pero todavía tengo un 403 prohibido.
qed
@CravingSpirit - sigue los registros de apache ( /var/log/httpd/access.log) y ( /var/log/httpd/error.log) para ver si hay mensajes adicionales.
slm
He agregado el registro a la publicación.
qed
@CravingSpirit: ¿notas el acceso denegado en el ~ kaiyin`? El usuario de Apache no tiene acceso a los directorios de nivel superior de los usuarios. Necesita derechos de lectura + ejecución para que pueda acceder a ellos.
slm
2
En realidad, casi seguro que no necesitas 755; 711 o incluso 710 grupo www-data debe hacer en los padres de public_html; también lo hará en public_html si no necesita listados de archivos, de lo contrario Apache necesitará leer también (por lo tanto, 755/750 en lugar de 711/710).
un CVn
1
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root

  <Directory /home/*/public_html>
    AllowOverride All
    Options MultiViews Indexes SymLinksIfOwnerMatch
    <Limit GET POST OPTIONS>
      # Apache <= 2.2:
      #Order allow,deny
      #Allow from all

      # Apache >= 2.4:
      Require all granted
    </Limit>
    <LimitExcept GET POST OPTIONS>
      # Apache <= 2.2:
      #Order deny,allow
      #Deny from all

      # Apache >= 2.4:
      Require all denied
    </LimitExcept>
  </Directory>
</IfModule>

Asegúrese de tener la configuración correcta en /etc/apache2/mods-enabled/userdir.conf. Recibí el permiso denegado después de cambiar mi public_html y luego decidí verificar el userdir.conf. Noté que había configuraciones para versiones anteriores de apache, así como también nuevas. Sabía que estaba ejecutando la última versión, así que habilité las configuraciones más nuevas y ahora todo funciona bien

Darryl
fuente
0

También puede usar el /etc/hostsarchivo para eliminar la necesidad de una URL temporal. Si hay una referencia para la URL completa en el tema o complemento (si tiene alguno), el sitio no mostrará el contenido en el formato adecuado.

Karthik
fuente