Apache2 userdir abilitato, ma non ha ancora accesso


9

Sto cercando di configurare un server Apache sul mio laptop Kubuntu 13.04. Ho installato il pacchetto apache2 e sudo a2enmod userdir; sudo service apache2 restart, ma ancora quando visito http://localhost/~user, dice qualcosa del genere:

Forbidden

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

Apache/2.2.22 (Ubuntu) Server at localhost Port 80

Risultato di 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"

Risultato di 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

Hai una public_htmldirectory per l'utente? L'utente che esegue apache ha il permesso di leggerlo?
Giordania,

@jordanm Sì, ho impostato a 755, anche provato 777.
qed

Risposte:


8

Le public_htmldirectory devono avere le loro autorizzazioni in questo modo in modo che l'utente che Apache sta eseguendo possa accedervi:

$ chmod -R 755 ~/public_html

non funziona ancora?

Se guardi nei log degli errori di Apache potresti vedere una riga come questa:

[Ven 02 ago 21:06:59 2013] [errore] [client 127.0.0.1] (13) Autorizzazione negata: accesso a / ~ kaiyin negato

Questo ti sta dicendo che Apache non ha i permessi per navigare nella directory del tuo utente (~ kaiyin) in questo esempio.

Come risolvere questo?

Devi assicurarti che i bit read + execute siano impostati per un gruppo di cui Apache è membro o che gli altri bit read + execute siano impostati anche nella directory dell'utente in modo che Apache possa accedere alla public_htmlcartella in basso.

Esempio

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

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

Riferimenti


L'ho già fatto, ma ho ancora un 403 proibito.
qed

@CravingSpirit: modifica i registri di Apache ( /var/log/httpd/access.log) e ( /var/log/httpd/error.log) per vedere se ci sono messaggi aggiuntivi.
slm

Ho aggiunto il registro al post.
qed

@CravingSpirit - noti l'accesso negato su ~ kaiyin`? L'utente di Apache non ha accesso alle directory di livello superiore degli utenti. È necessario leggere + eseguire i diritti in modo che possa accedervi.
slm

2
In realtà, quasi sicuramente non hai bisogno di 755; 711 o anche 710 dati www di gruppo dovrebbero fare sui genitori di public_html; lo farà anche su public_html se non hai bisogno di elenchi di file, altrimenti anche Apache dovrà leggere (quindi 755/750 anziché 711/710).
un CVn il

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>

Assicurati di avere le impostazioni corrette in /etc/apache2/mods-enabled/userdir.conf. Mi è stato negato il permesso dopo aver ricevuto il mio public_html e poi ho deciso di controllare userdir.conf. Ho notato che c'erano impostazioni per le versioni precedenti di Apache e anche per quelle più recenti. Sapevo che stavo eseguendo le ultime, quindi ho abilitato le impostazioni più recenti e ora tutto funziona bene


0

Inoltre è possibile utilizzare il /etc/hostsfile per eliminare la necessità di URL temporaneo. Se è presente un riferimento per l'URL completo nel tema o nel plug-in (se ne hai), il sito non mostrerà i contenuti nel formato corretto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.