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

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?

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

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>/

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

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.

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.

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

Para cualquiera que tenga problemas después de actualizar a 14.04 /ubuntu/452042/why-is-my-apache-not-working-after-upgrading-to-ubuntu-14-04 ya que la raíz cambió antes de la actualización = / var / www después de la actualización = / var / www / html

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

sudo service apache2 restart

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í.