“Link simbólico não permitido ou destino do link não acessível” / Apache no CentOS 6

29

Eu tenho uma nova instalação do CentOS 6, que tem um link simbólico na raiz do documento para meus arquivos de desenvolvimento:

[root@localhost html]# ls -l
total 4
-rwxrwxrwx. 1 root root  0 Sep 18 20:16 index.html
-rwxrwxrwx. 1 root root 17 Sep 18 20:16 index.php
lrwxrwxrwx. 1 root root 24 Sep 18 20:19 refresh-app -> /home/billy/refresh-app/

Meu httpd.conf tem isso:

<Directory "/">
    Options All
    AllowOverride None
    Order allow,deny
    Allow from all
</directory>

O alvo do link simbólico tem permissões que devem permitir ao apache ler o que quiser:

 [root@localhost billy]# ls -l
total 40 (Some entries were omitted because the list was too long
drwxr-xr-x. 7 billy billy 4096 Sep 18 20:03 refresh-app

Eu também tentei desabilitar o SELinux alterando /etc/selinux/conf :

SELINUX=disabled

No entanto, não importa o que eu faça, quando alguém tentar acessar esse link, http://localhost/refresh-app/ , eu recebo uma página de erro 403 FORBIDDEN e isso está escrito em /var/log/httpd/error_log :

Symbolic link not allowed or link target not accessible

Por que o Apache não consegue acessar o destino do link simbólico?

    
por Billy ONeal 19.09.2011 / 03:43

10 respostas

42

Encontrou o problema. Acontece que o Apache quer acessar não apenas o diretório que estou veiculando, /home/billy/refresh-app/ , mas também todos os diretórios acima, ou seja, /home/billy/ , /home e / . (Eu não tenho idéia do porquê ... dar a alguém acesso a um subdiretório não deveria exigir permissões para tudo acima daquele subdiretório ...)

Eu acho que ele está procurando .htaccess ou algo assim, ou talvez * nix sendo estranho sobre como ele trata as permissões para diretórios transversais.

    
por 24.09.2011 / 07:07
8

Eu tive um problema semelhante no qual tinha a seguinte configuração que costumava funcionar com o Ubuntu 10, mas parei de trabalhar com o Ubuntu 14 (Apache 2.4):

<Directory /var/www/vhosts/example.com/httpdocs>
    Options +FollowSymLinks
</Directory>

Mudar para isso resolveu o problema (mesmo que o usuário do servidor web não tenha conseguido acessar diretamente o symlink)

<Directory /var/www/vhosts/example.com/httpdocs>
    Options +ExecCGI +FollowSymlinks -SymLinksIfOwnerMatch
</Directory>

Pelo que eu posso dizer, é apenas a configuração -SymLinksIfOwnerMatch e tem algo a ver com mudanças no Apache 2.4, mas eu não tentei pesquisar a causa exata.

Também achei que poderia estar abaixo das restrições openbase_dir no PHP, mas não foi isso.

    
por 08.05.2015 / 20:10
6

Esse erro também pode ser causado se você estiver vinculando a uma pasta criptografada.

    
por 28.12.2012 / 01:47
4

Aparece "FollowSymLinks" é a opção que você precisa no httpd.conf. Está detalhado aqui . Parece que você também precisa de uma regra no htdocs ... mas é a opção que você precisa.

    
por 19.09.2011 / 04:12
2

Você também pode querer verificar se o selinux é aplicado ou não. No RedHat / Fedora, execute isto:

getenforce

Se a resposta for "Imposição", talvez você queira executar

setenforce 0

e tente a URL novamente no seu navegador.

Note que não estou dizendo que desabilitar o selinux é a melhor maneira de resolver esse problema, mas pode ajudar a identificar a causa.

    
por 19.02.2014 / 11:45
1
Options +FollowSymLinks

Crie um arquivo .htaccess com este procedimento para mim (coloque-o em um diretório antes do link simbólico).

    
por 25.05.2015 / 00:00
0

que o que resolve o meu problema depois de permitir todas as permissões e permitir followymlink " No caso do FollowSymLinks, especificamente, ele DEVE estar dentro de uma estrutura do Diretório quando estiver dentro de um arquivo .conf. Do manual atual do Apache

The FollowSymLinks and SymLinksIfOwnerMatch Options work only in sections or .htaccess files.

responda daqui

    
por 23.05.2017 / 11:44
0

Minha solução foi criar uma pasta compartilhada para todos os repositórios chamados /home/repo .

Em seguida, crie links simbólicos da minha própria casa como: %código% então ln -s /home/repo ~/Code aponta para ~/Code/www.xxxx.com/public

e também um link para a raiz da web do apache %código% aponta para /home/repo/www.xxxx.com/public

Encontrei aqui: link

Com algumas acrobatas de symlink + grupos de usuários, você pode ter vários usuários / versões implantados.

    
por 31.10.2017 / 23:23
0

@Billey ONeil @ Flion Eu não poderia responder em linha (baixa contagem de repetições)
Aqui estava eu tive que fazer:
( nota: alias ll = 'ls $ LS_OPTIONS -lh')

root@Bellach:/var/www/html# ll lego
lrwxrwxrwx 1 root root 43 Sep 10 21:21 lego -> /home/DATA/Documents/Chris/Synced/web/lego/

Agora olhe para todos os diretórios no link de origem

root@Bellach:/var/www/html# ll -d /home/DATA/Documents/Chris/Synced/web/
drwxr-xr-x 9 chris chris 4.0K Sep 12  2017 /home/DATA/Documents/Chris/Synced/web/
root@Bellach:/var/www/html# ll -d /home/DATA/Documents/Chris/Synced/
drwxr-xr-x 20 chris chris 4.0K Mar 27 18:52 /home/DATA/Documents/Chris/Synced/
root@Bellach:/var/www/html# ll -d /home/DATA/Documents/Chris/
drwxr-xr-x 36 chris chris 4.0K Jun 17 23:31 /home/DATA/Documents/Chris/
root@Bellach:/var/www/html# ll -d /home/DATA/Documents/
drwxr-xr-x 21 chris chris 4.0K Aug  7 18:22 /home/DATA/Documents/
root@Bellach:/var/www/html# ll -d /home/DATA/
drwxrwxr-- 10 root users 4.0K Sep 10 11:17 /home/DATA/
root@Bellach:/var/www/html# ll -d /home/
drwxr-xr-x 5 root root 4.0K Sep 10 10:37 /home/
O diretório

/ home / DATA é o culpado.
Corrigi-lo com isto:

root@Bellach:/var/www/html# chmod +x /home/DATA/
root@Bellach:/var/www/html# ll -d /home/DATA/
drwxrwxr-x 10 root users 4.0K Sep 10 11:17 /home/DATA/

A correção é imediata - não é necessário reiniciar o apache.

    
por 10.09.2018 / 22:59
-1

Você também pode ajustar suas configurações do SELinux, e setenforce pode não estar no seu caminho. Então tente isto:

sudo /usr/sbin/setenforce 0

e para fazer isso persistir entre reinicializações

sudo vi /etc/sysconfig/selinux
    
por 03.10.2014 / 19:44