Apache: accesso negato perché mancano le autorizzazioni di ricerca

75

So che questa domanda viene posta molto, ma le soluzioni che ho visto non hanno funzionato per me.

Ho solo un host virtuale abilitato e sto provando ad abilitare l'accesso a una cartella che non è nella radice del 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>

Ho impostato /etc/apache2/envvarscome segue

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=public

Mi sono assicurato che / home / username / Videos / e le sue sottocartelle siano di proprietà di username:public, ho impostato le autorizzazioni su 777 (dopo che 775 non ha funzionato) e mi sono assicurato che l'utente www-dataappartenesse al gruppo public.

Ora, quando cerco di http://localhost/moviesottenere

[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

Ma quando ho impostato /etc/apache2/envvarsper eseguire Apache sotto username(il mio nome utente) tutto funziona bene. Il problema è legato alle autorizzazioni, ma non vedo come nel mio caso; soprattutto quando imposto le autorizzazioni su 777. Qualche idea?

PS La versione Ubuntu è 14.04, Apache è 2.4.7 e non ho modificato altri file di configurazione.

permissions apache2

— Yotam
fonte

1

possibile duplicato di Come posso fornire all'utente www-data a una cartella nella mia cartella home?

— NGRhodes,

Ho fatto tutto quello che mi hanno suggerito laggiù, come ho scritto, e non aiuta

— Yotam

Qualche possibilità che hai montato /homecon ACL abilitato? (c'è un segno "+" alla fine dei bit di autorizzazione se è il caso (verificare con ls -l))

— Polosson

No, non l'ho fatto. In questo momento sto eseguendo Apache con il mio utente, quindi funziona, ma mi piacerebbe eseguirlo con un altro utente per motivi di sicurezza.

— Yotam,

Sto usando Linux per la prima volta. Ho scaricato Ubuntu 14.04 versione LTE. Sto affrontando lo stesso problema. Qualcuno può aiutare, per favore?

— Imdad,

95

Esegui una chmod +xdirectory utente e riavvia apache. 755 autorizzazioni dovrebbero funzionare. Ho avuto problemi con 644 .

— Peter
fonte

6

Infatti, e per ricontrollare i permessi di file e directory, se disponibili, puoi usare namei -m /home/youruser/public_html/yourfile.exto provare people.apache.org/~igalic/hacks/parsepath

— Junior M

2

per chiarire, qualsiasi directory che si desidera che Apache legga, deve essere leggibile per l'utente Apache. Molto probabilmente la cartella home dell'utente non è di proprietà dell'utente e del gruppo, pertanto è necessario impostare 755 autorizzazioni /home/usernameper accedervi con apace.

— Ruuter,

Ho avuto questo problema su OSX Mac OS High Sierra e questa soluzione ha funzionato per me. Non è stato nemmeno necessario riavviare Apache.

— andato il

Dopo ore di ricerche risulta che le autorizzazioni dovrebbero essere corrette anche per le directory principali di DocumentRoot. Grazie mille . A proposito, non è necessario riavviare Apache

— Accountant م

27

Se nel caso di selinux sia il problema, piuttosto che disabilitarlo, questa pagina e questa pagina danno il comando per concedere l'accesso:

chcon -R -t httpd_sys_content_t ~/public_html/

— jozxyqk
fonte

1

Ero sicuro che fosse il mio problema. Accidenti CentOS! Grazie per il comando, funziona perfettamente.

— Balmipour,

2

grazie, ~/public_html/ho dovuto semplicemente sostituire la parte con la directory principale del contenuto che stavo cercando di pubblicare.

— trpt4him,

chcon -R -t httpd_sys_content_t /var/www/html/phpmyadmin/(nella mia situazione)

— cssyphus,

Selinux scoperto non può gestire semplici homedir e solo una di quelle funzionalità era richiesta mentre l'altra era facoltativa. Grazie per il promemoria per la correzione: dopo il periodo di re-test obbligatorio con ogni nuova versione, e delusione, di solito lo faccio solo nel kickstart. Ora per systemd.

— user2066657

17

Potresti avere selinux abilitato. Provare

getenforce

Se mostra "Enforcing", prova

setenforce 0

e prova se questo risolve il tuo problema.

— Soprano
fonte

4

Non solo disabilitare SELinux come soluzione. Risolvi i problemi di SELinux riassegnando le porte o impostando valori booleani.

— siride,

1

Questa risposta aiuta a identificare che il problema è legato a SELinux. Ma disabilitarlo non è raccomandato.

— Rajkumar R,

15

Ho riscontrato lo stesso problema, dopo ore di tentativi, ho trovato una soluzione che risolve esattamente il problema:

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

Fondamentalmente, il server Apache non richiede solo le autorizzazioni di lettura di tutti i file che serve, ma l'autorizzazione di esecuzione di tutte le directory nel percorso del tuo host virtuale.

Il nome dell'utilità può essere utilizzato per aiutare a trovare i problemi di autorizzazione elencando le autorizzazioni lungo ciascun componente del percorso:

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

Nel mio caso, una directory nel mio percorso ha l'autorizzazione 700, causa il problema. Dopo averlo modificato in 701, il problema è stato risolto.

— Lu Sun
fonte

1

Il link qui è utile perché spiega il problema: in uno dei nodi nel percorso della directory mancano le autorizzazioni di ricerca. Usa il comando "namei" per trovare questo e poi "chmod" a 755.

— user3751385

Spiega la vera ragione e la soluzione. grazie

— Emdadul Sawon il

1

Stavo riscontrando questo problema quando stavo cercando di eseguire apache in un contenitore docker su un host Ubuntu 16.04 che utilizzava il kernel 4.4 anziché 4.10.

Una volta eseguito questo comando sull'host e ri-distribuito, stavo bene:

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

— Programster
fonte

Mi sono imbattuto in questo problema, ma con lo strano effetto che posso chmodo chownall'interno del contenitore, e sopprime gli errori Apache 403 per un po ', solo per tornare più tardi. Non vi è alcun riavvio del contenitore o altri cambiamenti sostanziali che potrebbero essere la causa di ciò, per quanto ne so. Dato che sto effettivamente eseguendo la 16.04, ho provato a installare questo binario, e per ora i miei 403 sono rimasti a bada. Lo terrò d'occhio, e grazie!

— halfer