web-dev-qa-db-fra.com

Pourquoi Nginx renvoie-t-il un 403 alors que toutes les autorisations sont correctement définies?

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"

nginxinstallationhttp-status-code-403
39
Adam Pearlman

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?

2
Adam Pearlman

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.

149
Kurt

J'ai rencontré le même problème. Si vous utilisez Fedora/RedHat/CentOS, cela pourrait vous aider:

  • Selon SELinux: setsebool -P httpd_read_user_content 1

J'espère que cela t'aides.

6
Bryan Macías

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
4
Terry Lam

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

2
rassi

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
2
Mohammad AbuShady

J'ai rencontré le même problème: 

  • Vérifié nginx.conf pour vérifier l'utilisateur
  • Les autorisations ont été définies correctement
  • Assurez-vous que "x" est bien défini pour tout le chemin

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é.

1
dougB

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.

1
loszer

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.

1
Michael Ma

Il y a 2 raisons possibles pour refuser l'accès:

  1. 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.

  2. 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.

1
Cyker

Modifiez le fichier nginx.conf, changez le nom d'utilisateur en votre nom de compte et redémarrez nginx.it work!

0
zhuoming