Apache no seguirá enlaces simbólicos (403 Prohibido)


90

Tengo problemas para configurar Apache en Ubuntu. He estado siguiendo esta guía .

# /usr/sbin/apache2 -v
Server version: Apache/2.2.17 (Ubuntu)
Server built:   Feb 22 2011 18:33:02

Mi directorio público, / var / www, puede servir y ejecutar correctamente las páginas PHP que se colocan en él. Sin embargo, quiero crear un enlace simbólico en / var / www que apunte a un directorio en mi carpeta de inicio y sirva páginas allí.

[root /var/www]# ll
total 36
drwxr-xr-x  3 root root 4096 2011-09-11 14:22 .
drwxr-xr-x 14 root root 4096 2011-06-04 22:49 ..
lrwxrwxrwx  1 root root   16 2011-09-11 13:21 about -> /root/site/about

Cuando intento acceder a / about en el navegador, obtengo

Forbidden

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

Hasta donde yo sé, le di suficientes privilegios a los archivos que quiero servir:

[root ~/site/about]# ll
total 24
drwxr-xr-x 5 root root 4096 2011-09-11 13:20 .
drwxr--r-- 3 root root 4096 2011-09-11 13:19 ..
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 contact
-rwxr-xr-x 1 root root 1090 2011-09-11 13:19 index.php
drwxr-xr-x 2 root root 4096 2011-09-11 13:20 me
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 resume

Soy consciente de la opción FollowSymLinks y creo que está configurada en mi archivo / etc / apache2 / sites-enabled / 000-default:

DocumentRoot /var/www
<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>
<Directory /var/www/>
    Options FollowSymLinks Indexes MultiViews
    AllowOverride None
    Order allow,deny
    allow from all
</Directory>

¿Alguna idea de lo que podría estar perdiendo?

Respuestas:


126

Compruebe que Apache tiene derechos de ejecución para /root, /root/sitey /root/site/about.

Correr:

chmod o+x /root /root/site /root/site/about

8
Muchas gracias ... No me di cuenta de que los directorios principales también tenían que ser ejecutables.
Tim

39
Bueno, no digo que no funcione, pero en general, dar o + x en / root no es una buena idea;)
Michal Rzemieniecki

11
Michal tiene razón. Descubrí que podía usar ACL (en Mac, al menos):, chmod -R +a "_www allow list,search,readattr" /root /root/site /root/site/aboutque otorga esos permisos solo a la aplicación apache (_www), que es un poco más segura que "otra".
James S

1
En Mac OS (10.9.4), mi ~ / Documents no tenía derechos de ejecución y tenía un repositorio de git donde alojaría los archivos de mi sitio. ¡Conceder chmod o + x en ~ / Documents hizo el truco! ¡Gracias!
Ernani Joppert

1
¡Finalmente obtuve la respuesta! Gracias.
whoan

21

El error 403 también puede deberse a un sistema de archivos cifrado, por ejemplo, un enlace simbólico a una carpeta de inicio cifrada .

Si su enlace simbólico apunta a la carpeta cifrada, el usuario de apache (por ejemplo, www-data) no puede acceder al contenido, incluso si los permisos de apache y de archivo / carpeta están configurados correctamente. El acceso del usuario de www-data se puede probar con una llamada de este tipo:

sudo -u www-data ls -l /var/www/html/<your symlink>/

Existen alternativas / soluciones para esto, por ejemplo, agregar el usuario de www-data a su grupo privado (expone los datos cifrados al usuario web) o configurando una carpeta rsynced sin cifrar (probablemente bastante segura). Yo mismo probablemente buscaré una solución rsync durante el desarrollo.

/ubuntu/633625/public-folder-in-an-encrypted-home-directory

Una herramienta conveniente para mis propósitos es lsyncd . Esto me permite trabajar directamente en mi carpeta de inicio cifrada y poder ver los cambios casi instantáneamente en la página web de Apache. La sincronización se desencadena por cambios en el sistema de archivos, llamando a un rsync. Como solo trabajo en páginas web y scripts bastante pequeños, la sincronización es muy rápida. Decidí usar un breve retraso de 1 segundo antes de que se inicie rsync, aunque es posible establecer un retraso de 0 segundos .

Instalación de lsyncd (en Ubuntu):

sudo apt-get install lsyncd

Iniciar el servicio en segundo plano:

lsyncd -delay 1 -rsync /home/<me>/<work folder>/ /var/www/html/<web folder>/

3
¡ sudo -u www-data ...Es una excelente manera de verificar si hay un problema de permisos! Tenga en cuenta que el usuario podría ser www-data, apache o cualquier otra cosa dependiendo de su distribución.
mkasberg

¡Arghh, finalmente! ¡Ya estaba dudando de mis habilidades más básicas!
kalabalik

¡Perdí horas en esto y al final fue encriptación!
myol

15

Tenía un problema similar que no pude resolver durante mucho tiempo en mi nuevo servidor. Además de la respuesta de palacsint, una buena pregunta es: ¿está usando Apache 2.4? En Apache 2.4 hay un mecanismo diferente para configurar los permisos que no funcionan cuando se hace con la configuración anterior, así que utilicé la solución explicada en esta publicación de blog .

Básicamente, lo que tenía que hacer era convertir mi archivo de configuración de:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    allow from all

</Directory>

a:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Observe cómo la orden y las líneas permitidas han sido reemplazadas por Requerir todas las otorgadas


Tenga en cuenta que los comandos Order / Allow / Deny todavía están disponibles en la mayoría de las computadoras. En versiones más nuevas, se implementa en el access_compatmódulo. Si ese módulo está habilitado, no es probable que la primera parte funcione como se esperaba. Si no está allí, entonces intentar iniciar Apache2 debería fallar con errores.
Alexis Wilke

¿Qué configuración? El /etc/httpd/conf/httpd.confno existe en mi sistema y, además, el directorio /etc/httpd/no existe.
Aaron Franke

@AaronFranke ¿Tiene apache instalado? Podría estar aquí: /etc/apache2/httpd.conf /etc/apache2/apache2.conf /etc/httpd/httpd.conf /etc/httpd/conf/httpd.conf
RightHandedMonkey

Sí, tengo Apache instalado y estoy en Ubuntu. /etc/apache2/apache2.confexiste para mi.
Aaron Franke

7

En relación con esta pregunta, acabo de descubrir por qué mi vhost me estaba dando ese 403.

Había probado TODAS las posibilidades en esta pregunta y otras sin suerte. Casi me vuelve loco.

Estoy configurando un servidor con una implementación de versiones similar a la de Capistrano a través de enlaces simbólicos y cuando intenté acceder a la carpeta DocRoot (que ahora es un enlace simbólico a la carpeta de versiones actual) me dio el 403.

Mi vhost es:

DocumentRoot /var/www/site.com/html
<Directory /var/www/site.com/html>
        AllowOverride All
        Options +FollowSymLinks
        Require all granted
</Directory>

y mi archivo httpd.conf principal era (instalación predeterminada de Apache 2.4):

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes -FollowSymLinks -Includes
(...)

Resulta que la definición principal de Opciones tenía prioridad sobre mi campo de vhosts (para mí eso es contrario a la intuición). Así que lo cambié a:

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes +FollowSymLinks -Includes
(...)

y Eureka! (tenga en cuenta el signo más antes de FollowSymLinks en el archivo httpd.conf PRINCIPAL. Espero que esto ayude a alguna otra alma perdida.


En Apache 2.4, su solución invalidará la configuración y httpd no se iniciará, ya que no puede combinar '+' y '-' en una sola línea de Opciones.
deesto

Sí, eso fue todo, aunque había declarado un DocumentRoot "antes" en el archivo, estaba anulando la sección del directorio secundario (¿qué?)
rogerdpack

2

Hay otra forma en que los enlaces simbólicos pueden fallar, como descubrí en mi situación. Si tiene un sistema SELinux como servidor y los enlaces simbólicos apuntan a una carpeta montada en NFS (otros sistemas de archivos pueden producir síntomas similares), es httpdposible que vea los contextos incorrectos y se niegue a servir el contenido de las carpetas de destino.

En mi caso, el contexto de SELinux /var/www/html(con el que puede obtener ls -Z) es unconfined_u:object_r:httpd_sys_content_t:s0. Los enlaces simbólicos en /var/www/htmltendrán el mismo contexto, pero el contexto de su destino, que es una carpeta montada en NFS, sí lo es system_u:object_r:nfs_t:s0.

La solución es añadir fscontext=unconfined_u:object_r:httpd_sys_content_t:s0a las mountopciones (por ejemplo # mount -t nfs -o v3,fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 <IP address>:/<server path> /<mount point>). rootcontextes irrelevante y defcontextNFS lo rechaza. No lo intenté contextsolo.


2

Primero deshabilite selinux (vim / etc / selinux / config)

vim /etc/httpd/conf/httpd.conf edite las siguientes líneas para enlaces simbólicos e indexación de directorios:

documentroot /var/www/html
<directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride None
</directory>

Si el archivo .htaccess, entonces AllowOverride all


¿Qué pasa si no tengo la /etc/httpd/carpeta en mi sistema?
Aaron Franke


1

Además de cambiar los permisos como han indicado las otras respuestas, tuve que reiniciar Apache para que surta efecto:

sudo service apache2 restart

0

Otro error más sutil, en caso de que necesite AllowOverride All:

En algún lugar profundo en el árbol de fs, un viejo .htaccessque tiene

    Options Indexes

en vez de

    Options +Indexes

fue todo lo que se necesitó para deshabilitar despreocupadamente el FollowSymLinksconjunto en la configuración del servidor y provocar un misterioso 403 aquí.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.