Apache não segue links simbólicos (403 Proibido)

Estou tendo problemas para configurar o Apache no Ubuntu. Tenho seguido este guia .

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

Meu diretório público, / var / www, pode servir e executar com sucesso as páginas PHP colocadas nele. No entanto, quero criar um link simbólico em / var / www que aponte para um diretório em minha pasta pessoal e veicule páginas lá.

[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

Quando tento acessar / sobre no navegador, recebo

Forbidden

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

Pelo que sei, concedi privilégios suficientes para os arquivos que desejo 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

Estou ciente da opção FollowSymLinks e acredito que esteja definida em meu arquivo / 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>

Alguma ideia do que posso estar perdendo?

Verifique se o Apache possui direitos de execução para /root, /root/sitee /root/site/about.

Corre:

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

O erro 403 também pode ser causado por um sistema de arquivos criptografado, por exemplo, um link simbólico para uma pasta pessoal criptografada .

Se o seu link simbólico aponta para a pasta criptografada, o usuário apache (por exemplo, www-data) não pode acessar o conteúdo, mesmo se as permissões do apache e do arquivo / pasta estiverem definidas corretamente. O acesso do usuário www-data pode ser testado com tal chamada:

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

Existem alternativas / soluções para isso, por exemplo, adicionar o usuário www-data ao seu grupo privado (expõe os dados criptografados ao usuário da web) ou configurando uma pasta rsynced não criptografada (provavelmente bastante segura). Eu provavelmente irei para uma solução rsync durante o desenvolvimento.

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

Uma ferramenta conveniente para meus objetivos é o lsyncd . Isso me permite trabalhar diretamente na minha pasta de início criptografada e ser capaz de ver as alterações quase que instantaneamente na página da web do apache. A sincronização é acionada por mudanças no sistema de arquivos, chamando um rsync. Como estou trabalhando apenas em páginas e scripts pequenos da web, a sincronização é muito rápida. Decidi usar um pequeno atraso de 1 segundo antes do rsync ser iniciado, embora seja possível definir um atraso de 0 segundos .

Instalando lsyncd (no Ubuntu):

sudo apt-get install lsyncd

Iniciando o serviço de segundo plano:

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

Eu estava tendo um problema semelhante que não conseguia resolver por muito tempo no meu novo servidor. Além da resposta do palacsint, uma boa pergunta é: você está usando o Apache 2.4? No Apache 2.4 há um mecanismo diferente para definir as permissões que não funcionam quando feito usando a configuração acima, então usei a solução explicada nesta postagem do blog .

Basicamente, o que eu precisava fazer era converter meu arquivo de configuração de:

Alias /demo /usr/demo/html

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

</Directory>

para:

Alias /demo /usr/demo/html

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

Observe como as linhas de pedido e permissão foram substituídas por Exigir todos concedidos

Relacionado a esta questão, acabei de descobrir por que meu vhost estava me dando aquele 403.

Eu testei TODAS as possibilidades nesta questão e em outras sem sorte. Quase me enlouquece.

Estou configurando um servidor com implantação de lançamentos semelhante ao Capistrano através de links simbólicos e quando tentei acessar a pasta DocRoot (que agora é um link simbólico para a pasta de lançamento atual) me deu o 403.

Meu vhost é:

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

e meu arquivo httpd.conf principal era (instalação padrão do Apache 2.4):

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

Acontece que a principal definição de Opções estava tendo precedência sobre meu fiel vhosts (para mim isso é contra intuitivo). Então eu mudei para:

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

e Eureka! (observe o sinal de mais antes de FollowSymLinks no arquivo httpd.conf PRINCIPAL. Espero que isso ajude alguma outra alma perdida.

Há outra maneira de os links simbólicos falharem, como descobri em minha situação. Se você tiver um sistema SELinux como servidor e os links simbólicos apontam para uma pasta montada em NFS (outros sistemas de arquivos podem produzir sintomas semelhantes),httpd pode ver os contextos errados e se recusar a servir o conteúdo das pastas de destino.

No meu caso, o contexto SELinux de /var/www/html(que você pode obter com ls -Z) é unconfined_u:object_r:httpd_sys_content_t:s0. Os links simbólicos em/var/www/html terão o mesmo contexto, mas o contexto de seu destino, sendo uma pasta montada em NFS, sãosystem_u:object_r:nfs_t:s0 .

A solução é adicionar fscontext=unconfined_u:object_r:httpd_sys_content_t:s0às mountopções (por exemplo # mount -t nfs -o v3,fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 <IP address>:/<server path> /<mount point>). rootcontexté irrelevante e defcontexté rejeitado pelo NFS. Eu não tentei contextpor conta própria.

Primeiro desative o selinux (vim / etc / selinux / config)

vim /etc/httpd/conf/httpd.conf edite as seguintes linhas para links simbólicos e indexação de diretório:

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

Se o arquivo .htaccess, então AllowOverride todos

Para qualquer um que tenha problemas após atualizar para 14.04 /ubuntu/452042/why-is-my-apache-not-working-after-upgrading-to-ubuntu-14-04 como root alterado antes da atualização = / var / www após atualização = / var / www / html

Além de alterar as permissões conforme as outras respostas indicaram, tive que reiniciar o apache para que ele tivesse efeito:

sudo service apache2 restart

Mais uma armadilha sutil, caso você precise AllowOverride All:

Em algum lugar no fundo da árvore de fs, um velho .htaccesstendo

    Options Indexes

ao invés de

    Options +Indexes

foi o suficiente para desabilitar indiferentemente o FollowSymLinksconjunto na configuração do servidor, e causar um misterioso 403 aqui.