Apache: acesso negado porque faltam permissões de pesquisa


75

Sei que essa pergunta é muito solicitada, mas as soluções que vi não funcionaram para mim.

Eu tenho apenas um host virtual ativado e estou tentando habilitar o acesso a uma pasta que não está na raiz do documento

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

Alias /movies /home/username/Videos/Movies

<Directory /home/username/Videos/Movies/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Eu defino da /etc/apache2/envvarsseguinte forma

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=public

Certifiquei-me de que / home / nome de usuário / vídeos / e suas subpastas pertencem username:public, defina as permissões para 777 (depois que o 775 não funcionou) e verifiquei se o usuário www-datapertence ao grupo public.

Agora, quando eu navego para http://localhost/movieseu recebo

[Mon Apr 21 11:28:14.971844 2014] [core:error] [pid 1385:tid 140067725104896] (13)Permission denied: [client 127.0.0.1:46603] AH00035: access to /movies/ denied (filesystem path '/home/username/Videos') because search permissions are missing on a component of the path

Mas quando eu configuro /etc/apache2/envvarsexecutar o Apache em username(meu próprio nome de usuário) tudo funciona bem. O problema está relacionado à permissão, mas não vejo como no meu caso; especialmente quando eu defino as permissões para 777. Alguma ideia?

A versão PS Ubuntu é 14.04, o Apache é 2.4.7 e não editei outros arquivos de configuração.



Fiz tudo o que eles sugeriram para lá, como eu escrevi, e isso não ajuda
Yotam

Alguma chance de você montar o seu /homecom a ACL ativada? (há um sinal "+" no final dos bits de permissão se for o caso (consulte o ls -l))
Polosson

Não, eu não fiz isso. No momento, estou executando o Apache no meu usuário, por isso está funcionando, mas eu gostaria de executá-lo em outro usuário por motivos de segurança.
Yotam

Estou usando o Linux pela primeira vez. Eu baixei a versão Ubuntu 14.04 LTE. Estou enfrentando o mesmo problema. Alguém pode ajudar por favor?
23414 Imdad #

Respostas:


95

Faça um chmod +xno diretório do usuário e reinicie o apache. Permissões 755 devem funcionar. Eu tive problemas com o 644 .


6
Na verdade, e que verifique as permissões de arquivo e diretório, se estiver disponível, você pode usar namei -m /home/youruser/public_html/yourfile.extou tentar people.apache.org/~igalic/hacks/parsepath
Junior M

2
para esclarecer, qualquer diretório que você queira que o Apache leia, deve ser legível para o usuário do Apache. Provavelmente, sua pasta inicial do usuário não pertence ao seu usuário e grupo, portanto, você deve definir 755 permissões /home/usernamepara acessá-la rapidamente.
ruuter 01/09/2015

Eu tive esse problema no OSX Mac OS High Sierra e esta solução funcionou para mim. Nem precisava reiniciar o Apache.
foi

Após horas de pesquisa, as permissões também devem estar corretas para os diretórios pai do DocumentRoot. Muito obrigado . BTW, isso não precisa reiniciar o Apache
contador

27

Se, no caso de o selinux ser o problema, em vez de apenas desativá-lo, esta página e esta página fornecem o comando para conceder acesso:

chcon -R -t httpd_sys_content_t ~/public_html/

1
Eu tinha certeza de que era o meu problema. Maldito CentOS! Thx para o comando, funciona perfeitamente.
Balmipour

2
obrigado, só tive que substituir a ~/public_html/parte pelo diretório raiz do conteúdo que eu estava tentando veicular.
trpt4him

chcon -R -t httpd_sys_content_t /var/www/html/phpmyadmin/(na minha situação)
cssyphus 28/02

O selinux descoberto não pode lidar com homedirs simples, e apenas um desses recursos era necessário enquanto o outro era opcional. Obrigado pelo lembrete sobre a correção - após o período obrigatório de re-teste com cada novo lançamento e decepção, eu geralmente apenas explico isso no kickstart. Agora para systemd.
user2066657 13/03

17

Você pode ter o selinux ativado. Experimentar

getenforce

Se aparecer "Executando", tente

setenforce 0

e tente se isso resolver seu problema.


4
Não basta desativar o SELinux como uma correção. Corrija os problemas do SELinux reatribuindo portas ou configurando booleanos.
siride

1
Esta resposta ajuda a identificar que o problema está relacionado ao SELinux. Mas desabilitar isso não é recomendado.
Rajkumar R

15

Encontrei o mesmo problema, depois de horas tentando, encontrei uma solução que resolve exatamente o problema:

https://wiki.apache.org/httpd/13PermissionDenied

Basicamente, o servidor Apache não requer apenas permissões de leitura de todos os arquivos que ele serve, mas também a permissão de execução de todos os diretórios no caminho do seu host virtual.

O utilitário namei pode ser usado para ajudar a encontrar problemas de permissões, listando as permissões ao longo de cada componente do caminho:

namei --modes /usr/local/apache2/htdocs/foo/bar.html

No meu caso, um diretório no meu caminho tem a permissão 700, causa o problema. Depois de alterá-lo para 701, o problema foi resolvido.


1
O link aqui é útil porque explica o problema: Um dos nós no caminho do diretório está sem permissões de pesquisa. Use o comando "namei" para encontrar isso e, em seguida, "chmod" para 755.
user3751385

Explica a verdadeira razão, bem como a solução. Obrigado
Emdadul Sawon

1

Eu estava enfrentando esse problema quando estava tentando executar o apache em um contêiner de docker em um host Ubuntu 16.04 que usava o kernel 4.4 em vez da 4.10.

Depois de executar este comando no host e reimplantá-lo, fiquei bem:

sudo apt-get install --install-recommends linux-generic-hwe-16.04 

Eu me deparei com esse problema, mas com o efeito estranho que posso chmodou chowndentro do contêiner, e suprime os erros do Apache 403 por um tempo, apenas para reverter algum tempo depois. Não há reinicialização de contêineres interveniente ou outra alteração substantiva que possa ser a causa disso, pelo que sei. Desde que estou realmente executando o 16.04, tentei instalar esse binário e meus 403s estão paralisados ​​por enquanto. Vou ficar de olho nele, e obrigado!
halfer
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.