Apache2 userdir ativado, mas ainda não tem acesso


9

Estou tentando configurar um servidor apache no meu laptop Kubuntu 13.04. Instalei o pacote apache2 e sudo a2enmod userdir; sudo service apache2 restart, mas ainda quando o visito http://localhost/~user, ele diz algo como isto:

Forbidden

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

Apache/2.2.22 (Ubuntu) Server at localhost Port 80

Resultado de tail /var/log/apache2/access.log

127.0.0.1 - - [02/Aug/2013:16:22:01 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:16:22:02 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:35:30 +0200] "GET /~kaiyin HTTP/1.1" 403 501 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:35:30 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:35:30 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:36:26 +0200] "GET /favicon.ico HTTP/1.1" 404 499 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:17:36:26 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:21:05:17 +0200] "GET /~kaiyin HTTP/1.1" 403 501 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:21:05:17 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
127.0.0.1 - - [02/Aug/2013:21:05:17 +0200] "GET /favicon.ico HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"

Resultado de tail /var/log/apache2/error.log

[Fri Aug 02 21:05:17 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:05:17 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:06:54 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:06:54 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:06:59 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /~kaiyin denied
[Fri Aug 02 21:06:59 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:06:59 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:07:17 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /~kaiyin denied
[Fri Aug 02 21:07:17 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Fri Aug 02 21:07:17 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico

Você tem um public_htmldiretório para o usuário? O usuário que está executando o apache tem permissão para lê-lo?
Jordanm #

@jordanm Sim, eu configurá-lo para 755, também tentou 777.
qed

Respostas:


8

Os public_htmldiretórios precisam ter suas permissões como esta para que o usuário que o Apache está executando como possa acessá-lo:

$ chmod -R 755 ~/public_html

ainda não funciona?

Se você olhar nos logs de erro do Apache, poderá ver uma linha como esta:

[Fri 02 de agosto 21:06:59 2013] [erro] [cliente 127.0.0.1] (13) Permissão negada: acesso a / ~ kaiyin negado

Isso está lhe dizendo que o Apache não tem permissões para navegar para o diretório do usuário (~ kaiyin) neste exemplo.

Como consertar isto?

Você precisa garantir que os bits de leitura + execução estejam definidos para um grupo do qual o Apache é membro ou que os outros bits de leitura + execução estejam definidos no diretório do usuário, para que o Apache possa acessar a public_htmlpasta abaixo.

Exemplo

/home
|-- [drwxr-x---]  /home/sam

/home/sam
|-- [drwxr-xr-x]  /home/sam/public_html

Referências


Eu já fiz isso, mas ainda tenho o 403 proibido.
qed

@CravingSpirit - siga os logs do apache ( /var/log/httpd/access.log) e ( /var/log/httpd/error.log) para ver se há alguma mensagem adicional.
slm

Eu adicionei o log à postagem.
qed

@CravingSpirit - repara no acesso negado no ~ kaiyin`? O usuário do Apache não tem acesso aos diretórios de nível superior dos usuários. Você precisa ler + executar direitos para que ele possa acessá-los.
slm

2
Na verdade, você quase certamente não precisa do 755; 711 ou mesmo 710 www-data do grupo devem funcionar com os pais de public_html; isso também será feito em public_html se você não precisar de listagens de arquivos; caso contrário, o Apache também precisará ler (portanto, 755/750 em vez de 711/710).
um CVn 02/08/19

1
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root

  <Directory /home/*/public_html>
    AllowOverride All
    Options MultiViews Indexes SymLinksIfOwnerMatch
    <Limit GET POST OPTIONS>
      # Apache <= 2.2:
      #Order allow,deny
      #Allow from all

      # Apache >= 2.4:
      Require all granted
    </Limit>
    <LimitExcept GET POST OPTIONS>
      # Apache <= 2.2:
      #Order deny,allow
      #Deny from all

      # Apache >= 2.4:
      Require all denied
    </LimitExcept>
  </Directory>
</IfModule>

Verifique se você possui as configurações corretas /etc/apache2/mods-enabled/userdir.conf. Eu estava obtendo permissão negada após chmodding meu public_html e depois decidi verificar o userdir.conf. Notei que havia configurações para versões anteriores do apache, bem como para as mais recentes. Eu sabia que estava executando o mais recente, habilitei as configurações mais recentes e agora tudo está funcionando bem


0

Além disso, você pode usar o /etc/hostsarquivo para eliminar a necessidade de URL temporário. Se houver referência para o URL completo no tema ou plug-in (se houver), o site não exibirá o conteúdo no formato adequado.

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.