J'ai configuré Nginx et affiche correctement la page de test. Si j'essaie de changer le chemin racine, j'obtiens une erreur 403 Forbidden, même si toutes les autorisations sont identiques. De plus, l'utilisateur nginx existe.
nginx.conf:
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 1024;
}
http {
index index.html index.htm;
server {
listen 80;
server_name localhost;
root /var/www/html; #changed from the default /usr/share/nginx/html
}
}
namei -om /usr/share/nginx/html/index.html
f: /usr/share/nginx/html/index.html
dr-xr-xr-x root root /
drwxr-xr-x root root usr
drwxr-xr-x root root share
drwxr-xr-x root root nginx
drwxr-xr-x root root html
-rw-r--r-- root root index.html
namei -om /var/www/html/index.html
f: /var/www/html/index.html
dr-xr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwxr-xr-x root root html
-rw-r--r-- root root index.html
journal des erreurs
2014/03/23 12:45:08 [erreur] 5490 # 0: * 13 open () "/var/www/html/index.html" a échoué (13: autorisation refusée), client: XXX.XX.XXX.XXX, serveur: localhost, requête: "GET/index.html HTTP/1.1", hôte: "ec2-XXX-XX-XXX-XXX.compute-1.amazonaws.com"
J'utilisais:
Sudo service nginx start
Si j'utilise:
Sudo nginx
... tout fonctionne bien. Quelqu'un peut-il expliquer la différence entre ces deux?
J'ai rencontré le même problème et c'était dû à SELinux .
Pour vérifier si SELinux est en cours d'exécution:
# getenforce
Pour désactiver SELinux jusqu'au prochain redémarrage:
# setenforce Permissive
Redémarrez Nginx et voyez si le problème persiste. Si vous souhaitez modifier définitivement les paramètres, vous pouvez modifier /etc/sysconfig/selinux
Si SELinux est votre problème, vous pouvez exécuter ce qui suit pour permettre à nginx de servir votre répertoire www (assurez-vous de réactiver SELinux avant de le tester. I.e, # setenforce Enforcing
)
# chcon -Rt httpd_sys_content_t /path/to/www
Si vous rencontrez toujours des problèmes, jetez un coup d'œil aux drapeaux booléens dans getsebool -a
, en particulier, vous devrez peut-être activer httpd_can_network_connect
pour accéder au réseau.
# setsebool -P httpd_can_network_connect on
Pour moi, il suffisait de permettre à http de servir mon répertoire www.
J'ai rencontré le même problème. Si vous utilisez Fedora/RedHat/CentOS, cela pourrait vous aider:
setsebool -P httpd_read_user_content 1
J'espère que cela t'aides.
Tout d’abord, vous devez exécuter la commande suivante pour permettre à nginx d’accéder au système de fichiers.
Sudo setsebool -P httpd_read_user_content 1
Vous pouvez vérifier si les fichiers ou le répertoire avec la commande suivante:
ls -Z
S'il n'est toujours pas accessible, vous pouvez essayer de modifier la propriété SELinux des fichiers et du dossier à l'aide de la commande suivante:
chcon -Rt httpd_sys_content_t /path/to/www
Cependant, la commande ci-dessus ne peut pas s'appliquer aux fichiers sous système Fuse ou NFS.
Pour activer le traitement de fichiers à partir de montages Fuse, vous pouvez utiliser:
setsebool httpd_use_fusefs 1
Pour activer le service de fichiers à partir de montages NFS, vous pouvez utiliser:
setsebool httpd_use_nfs 1
Ceci est un ajout à la réponse de Prowlas mais je n’ai pas assez de réputation pour dire: Si le/chemin/vers/www est un répertoire personnel d’un utilisateur. Tu devrais essayer:
setsebool -P httpd_enable_homedirs=1
Cela a résolu mon problème
Source: http://forums.fedoraforum.org/archive/index.php/t-250779.html
cela semble bien logique, tous les fichiers sont des utilisateurs root. Essayez de le changer en utilisateur nginx, je voulais juste m'assurer que ce n'est pas une autorisation de listage refusée en premier.
Sudo chown -R nginx:nginx /var/www/html
J'ai rencontré le même problème:
Est-ce qu'un redémarrage à partir de la ligne de commande (J'utilisais Webmin depuis tout ce temps) et j'ai remarqué cette erreur:
aed@aed:/var/www/test.local$ Sudo service nginx restart
* Restarting nginx nginx
nginx: [warn] conflicting server name "test.local" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "test.local" on 0.0.0.0:80, ignored
Apparemment, il y avait une définition en double et donc ma tentative d'accès à "test.local" a échoué.
J'ai rencontré ce problème lorsque j'ai ajouté un nouvel utilisateur avec un dossier /home/new_user
en tant que nouvel hôte virtuel. Assurez-vous que ces dossiers (/home
, /home/new_user
, /home/new_user/xxx
...) sont 755
afin que mon problème soit résolu. Enfin, j'ai trouvé que mon problème était correctement conforme au fichier /var/log/nginx/error.log
.
N'oubliez pas que vous devez autoriser les autres utilisateurs à lire l'intégralité du chemin. Rappelez-vous également que Dropbox définira 700 dans son répertoire racine. Donc, chmod 755 ~/Dropbox
a résolu mon problème.
Il y a 2 raisons possibles pour refuser l'accès:
L'accès est refusé par DAC . Vérifiez les autorisations des utilisateurs, des groupes et des fichiers. Assurez-vous que le processus nginx, lorsqu’il est exécuté en tant que l’utilisateur spécifié dans son fichier de configuration, peut accéder au nouveau chemin racine HTML.
L'accès est refusé par MAC . Le plus largement utilisé est SELinux. Pour vérifier si cela a causé le problème, vous pouvez arrêter le processus nginx et exécuter cette commande:
setenforce Permissive
Ensuite, relancez nginx pour voir si l'accès est autorisé.
Alternativement, vous pouvez vérifier le contexte du fichier:
setenforce Enforcing
ls -Zd /usr/share/nginx/html /var/www/html
Si les deux contextes diffèrent, vous devrez peut-être modifier le contexte pour le nouveau chemin racine HTML:
chcon -R -t httpd_sys_content_t /var/www/html
Redémarrez nginx et voyez si cela fonctionne bien. Si oui, vous pouvez rendre le changement permanent:
semanage fcontext -a -t httpd_sys_content_t '/var/www/html(/.*)?'
restorecon -Rv /var/www/html
Certaines de ces commandes doivent être exécutées en tant que root.
Modifiez le fichier nginx.conf, changez le nom d'utilisateur en votre nom de compte et redémarrez nginx.it work!