Enfin trouvé un correctif. J'ai exécuté ces 2 fonctions pour classer de manière récursive les autorisations de dossier et de fichier de www et dans.
find /var/www -type d -exec chmod 755 {} \;
find /var/www -type f -exec chmod 644 {} \;
J'ai lu cette page ici:https://wiki.apache.org/httpd/13PermissionDeniedet elle expliquait essentiellement et me rappelait que les autorisations sont héritées, "faites de même pour le répertoire et chaque répertoire parent". J'ai donc exécuté ces 2 et tout fonctionne à nouveau.
Habituellement, l'autorisation d'exécution pour un chemin n'est pas définie, comme c'était le cas dans cette question. Le moyen le plus simple de résoudre ce problème est la commande suivante :
chmod a+rX -R /var/www
Mais en utilisant CentOS7 ou RHEL7, vous pourriez rencontrer des problèmes avec SELinux. Si les autorisations de fichier sont correctes et que vous obtenez toujours l'erreur, consultez le journal suivant :
tail -f /var/log/audit/audit.log
Si vous recevez un message comme celui-ci :
type=AVC msg=audit(1464350432.916:8222): avc: denied { getattr } for pid=17526 comm="httpd" path="/var/www/app/index.html" dev="sda1" ino=42021595 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file
type=SYSCALL msg=audit(1464350432.916:8222): arch=c000003e syscall=4 success=no exit=-13 a0=7fde4e450d40 a1=7ffd05e79640 a2=7ffd05e79640 a3=7fde42e43792 items=0 ppid=17524 pid=17526 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
Cela signifie :SELinux bloque l'accès à la racine de votre document. Vous pouvez essayer une commande comme celle-ci (récursive et détaillée sur l'option -Rv ):
chcon --user system_u --type httpd_sys_content_t -Rv /var/www/app/public
Pour trouver les bons paramètres, regardez dans un répertoire de travail comme /var/www/html avec ceci :
ls -laZ /var/www/
Cela devrait ressembler à :
drwxr-xr-x. server server system_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_t:s0 ..
drwxr-xr-x. server server system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. server server system_u:object_r:httpd_sys_content_t:s0 html
drwxrwxr-x. server server unconfined_u:object_r:var_t:s0 app
Pour les personnes qui ont peut-être essayé ce qui précède et qui rencontrent toujours des problèmes, assurez-vous qu'aucun des répertoires du chemin n'a une ACL qui empêche l'accès à apache.
Vous pouvez utiliser :
getfacl <directoryname>
pour obtenir les autorisations sur le répertoire qui ont pu être définies à l'aide des ACL. Vous verrez quelque chose comme ça après qui dit en gros que l'utilisateur a toutes les permissions et que le groupe a lu et exécuté (ou recherché) mais pas écrit :
# file: <directoryname>
# owner: username
# group: username
user::rwx
user:1000:rwx
group::---
group:username:r-x
mask::rwx
other::rwx
Pour donner à apache ou à un groupe l'accès à l'utilisation des ACL, utilisez ce qui suit :
setfacl -m g:<groupname>:rx <directoryname>
assurez-vous simplement que les répertoires parents ont le même. Vous pouvez utiliser le commutateur -R pour effectuer la modification de manière récursive sur le répertoire supérieur.
J'ai rencontré le même problème d'autorisations apache et je me suis cogné la tête en essayant de comprendre pourquoi chmod et chown n'avaient aucun effet avant de me souvenir que j'avais défini des ACL sur le répertoire lors de l'utilisation de Samba il y a quelque temps.