"Link simbolico non consentito o link target non accessibile" / Apache su CentOS 6

Ho una nuovissima installazione di CentOS 6, che ha un link simbolico nella radice del documento ai miei file di sviluppo:

[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/

Il mio httpd.conf ha questo:

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

La destinazione del collegamento simbolico ha autorizzazioni che dovrebbero consentire ad apache di leggere tutto ciò che vuole:

 [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

Ho anche provato a disabilitare SELinux modificando /etc/selinux/conf:

SELINUX=disabled

Eppure, qualunque cosa io faccia, quando qualcuno tenta di http://localhost/refresh-app/accedere a quel link, ricevo una pagina di errore 403 FORBIDDEN e questo è scritto nel /var/log/httpd/error_log:

Symbolic link not allowed or link target not accessible

Perché Apache non può accedere alla destinazione del collegamento simbolico?

Trovato il problema. Risulta, Apache vuole accedere non solo alla directory che sto servendo, /home/billy/refresh-app/ma anche ogni directory superiore a quella, cioè /home/billy/, /homee /. (Non ho idea del perché ... dare a qualcuno l'accesso a una sottodirectory non dovrebbe richiedere la concessione di autorizzazioni a tutto ciò che si trova sopra quella sottodirectory ....)

Immagino che .htaccessstia cercando o qualcosa del genere, o forse * nix è strano su come tratta le autorizzazioni per la directory trasversale.

Ho avuto un problema simile in cui avevo la seguente configurazione che funzionava con Ubuntu 10, ma ha smesso di funzionare con Ubuntu 14 (Apache 2.4):

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

Passando a questo, il problema è stato risolto (anche se l'utente del web server non è stato in grado di accedere direttamente al collegamento simbolico)

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

Da quello che posso dire è solo l' -SymLinksIfOwnerMatchimpostazione e ha qualcosa a che fare con i cambiamenti in Apache 2.4 ma non ho provato a ricercare la causa esatta.

Ho anche pensato che potesse dipendere dalle openbase_dirrestrizioni in PHP, ma non era così.

Questo errore può anche essere causato se si collega a una cartella crittografata.

Sembra che "FollowSymLinks" sia l'opzione necessaria in httpd.conf. È dettagliato qui . Sembra che potresti aver bisogno di una regola anche in htdocs ... ma è l'opzione che ti serve.

Potresti anche voler verificare se selinux è applicato o meno. Su RedHat / Fedora, eseguire questo:

getenforce

Se la risposta è 'Enforcing', potresti voler eseguire

setenforce 0

e prova di nuovo l'URL nel tuo browser.

Nota che non sto dicendo che disabilitare Selinux sia il modo migliore per risolvere questo problema, ma potrebbe aiutare a identificare la causa.

Options +FollowSymLinks

Creare un file .htaccess con questo ha fatto il trucco per me (mettilo in una directory prima del collegamento simbolico).

che ciò che risolve il mio problema dopo consenti tutte le autorizzazioni e consenti followymlink "Nel caso specifico di FollowSymLinks DEVE trovarsi all'interno di una struttura Directory all'interno di un file .conf. Dal manuale attuale di Apache

Le opzioni FollowSymLinks e SymLinksIfOwnerMatch funzionano solo in sezioni o file .htaccess.

risposta da qui

La mia soluzione era quella di creare una cartella condivisa per tutti i repository denominati /home/repo.

Quindi symlink da casa mia come: ln -s /home/repo ~/Code così ~/Code/www.xxxx.com/public indica /home/repo/www.xxxx.com/public

e anche un collegamento in apache web root /var/www/html punta a /home/repo/www.xxxx.com/public

Trovato qui: https://github.com/alghanmi/ubuntu-desktop_setup/wiki/Git-Local-Repository-Setup-Guide

Con alcuni symlink + gruppi di utenti di acrobazia è possibile distribuire più utenti / versioni.

@Billey ONeil @Flion Non ho potuto rispondere in linea (basso numero di ripetizioni)
Ecco cosa dovevo fare:
( 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/

Ora guarda tutte le directory nel link sorgente

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/

La directory / home / DATA è il colpevole.
Risolvilo con questo:

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/

La correzione è immediata: non è necessario riavviare apache.

Potresti anche regolare le tue impostazioni SELinux e setenforce potrebbe non essere sul tuo percorso. Quindi prova questo:

sudo /usr/sbin/setenforce 0

e per rendere questo persistere tra i riavvii

sudo vi /etc/sysconfig/selinux