web-dev-qa-db-fra.com

NGINX - Aucun fichier d'entrée spécifié. - php Fast/CGI

Bonjour, j'ai besoin d'aide pour configurer config pour nginx. Je suis nouveau sur NGINX et rencontre quelques problèmes.

Dans mon sites-available il y a un fichier default

Il contient ci-dessous le code

server {
    server_name www.test.com test.com;
    access_log /sites/test/logs/access.log;
    error_log /sites/test/logs/error.log;
    root /sites/test;

 location ~ / {

index index.php
    include /etc/nginx/fastcgi_params;
    fastcgi_pass  127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Le code ci-dessus fonctionne parfaitement lorsque j'écris une URL 

www.test.com/service/public/

quand j'écris

www.test.com/service/public/testservice (testservice est un dossier public), il est écrit No input file specified.

Comment le réparer. Merci d'avance.

J'ai essayé ci-dessous, mais pas de chance

http://nginxlibrary.com/resolving-no-input-file-specified-error/
http://blog.martinfjordvald.com/2011/01/no-input-file-specified-with-php-and-nginx/
nginx
13
Poonam Bhatt

Vous devez ajouter "include fastcgi.conf" dans 

location ~ \.$php{
  #......
  include fastcgi.conf;
}
20
ang yao

Résolution de l'erreur "Aucun fichier d'entrée spécifié"

Si vous utilisez nginx avec php-cgi et avez suivi la procédure standard pour le configurer, vous risquez souvent d'obtenir l'erreur «Aucun fichier d'entrée spécifié». Cette erreur se produit généralement lorsque le démon php-cgi ne peut pas trouver un fichier .php à exécuter à l'aide du paramètre SCRIPT_FILENAME qui lui a été fourni. Je discuterai des causes communes de l’erreur et de ses solutions . Un mauvais chemin est envoyé au démon php-cgi

Le plus souvent, un chemin incorrect (SCRIPT_FILENAME) est envoyé au démon fastCGI. Dans de nombreux cas, cela est dû à une mauvaise configuration. Certaines des configurations que j'ai vues sont configurées comme ceci:

server {
    listen   [::]:80;
    server_name  example.com www.example.com;
    access_log  /var/www/logs/example.com.access.log;  

    location / {
        root   /var/www/example.com;
        index  index.html index.htm index.pl;
    }

    location /images {
        autoindex on;
    }

    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/www/example.com$fastcgi_script_name;
        include fastcgi_params;
    }
}

Maintenant, il y a beaucoup de problèmes avec cette configuration. La directive racine dans l’emplacement/le bloc est un problème évident et criant. Lorsque la racine est définie à l'intérieur du bloc d'emplacement, elle est disponible/définie pour ce bloc uniquement. Ici, le bloc location/images ne correspondra à aucune requête car il n’a pas de $ document _root défini et nous devrons redéfinir redéfinir root pour cela. De toute évidence, la directive racine doit être déplacée hors de l’emplacement/du bloc et définie dans le bloc du serveur. De cette façon, les blocs d'emplacement hériteront de la valeur définie dans le bloc du serveur parental. Bien sûr, si vous souhaitez définir un autre $ document_root pour un emplacement, vous pouvez placer une directive racine dans un bloc d’emplacement.

Un autre problème est que la valeur du paramètre fastCGI SCRIPT_FILENAME est codée en dur. Si nous changeons la valeur de la directive racine et déplaçons nos fichiers ailleurs dans la chaîne de répertoires, php-cgi renverra une erreur «Aucun fichier d'entrée spécifié» car il ne sera pas en mesure de trouver le fichier à l'emplacement codé en dur qui ne change pas lorsque $ document_root a été changé. Nous devrions donc définir SCRIPT_FILENAME comme ci-dessous:

fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;

Nous devons garder à l’esprit que la directive root doit figurer dans le bloc serveur, sinon, seul le $ fastcgi_script_name sera transmis en tant que SCRIPT_FILENAME et nous obtiendrons l’erreur «Aucun fichier d’entrée spécifié».

source (erreur "Aucun fichier d'entrée spécifié")

14
evergreen

Redémarrer simplement mon php-fpm a résolu le problème. Si je comprends bien, c’est surtout un problème php-fpm que nginx.

5
Sam Najian

Même problème.

Cause : Ma racine n'a pas été spécifiée dans open_basedir.
Correction : Ajout du répertoire racine de mon site dans:

/etc/php5/fpm/pool.d/mysite.conf<br>

en ajoutant cette directive:

php_value[open_basedir] = /my/root/site/dir:/other/directory/allowed
2
Simon Ouellet
server {
    server_name www.test.com test.com;
    access_log /sites/test/logs/access.log;
    error_log /sites/test/logs/error.log;
    root /sites/test;

 location ~ / {

index index.php
    include /etc/nginx/fastcgi_params;
    fastcgi_pass  127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME `$document_root/service/public$fastcgi_script_name`;
}
1
Poonam Bhatt

Je l'ai résolu en remplaçant

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

$ document_root avec C:\MyWebSite\www \

fastcgi_param SCRIPT_FILENAME C:\MyWebSite\www\$fastcgi_script_name;
1
Fresco

J'ai essayé tous les paramètres ci-dessus, mais cela a résolu mon problème ... Vous devez définir nginx pour vérifier si le fichier php existe réellement à cet emplacement J'ai trouvé try_files $uri = 404; résoudre ce problème.

location ~ \.php$ {
        try_files  $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php5-fpm.sock; 
        include fastcgi_params;
        fastcgi_index index.php;
}
0
Rudra Pratap Sinha

J'ai eu la même erreur et mon problème était que j'avais mon fichier php dans mon répertoire personnel crypté. Et je lance mon fpm avec l'utilisateur www-data et cet utilisateur ne peut pas lire les fichiers php même si les permissions sur le fichier étaient correctes. La solution était que je lance fpm avec l'utilisateur qui possède le répertoire personnel. Ceci peut être changé dans le fichier suivant:

/etc/php5/fpm/pool.d/www.conf

j'espère que ceci vous aidera :)

0
FireGnome

Mon cas: SELinux a été activé et a empêché php-fpm d'exécuter mes scripts.

Diagnostic: Désactiver temporairement SELinux et voir si le problème disparaît.

$ Sudo setenforce permissive
### see if PHP scripts work ###
$ Sudo setenforce enforcing

Solution: Placez le répertoire PHP dans le contexte httpd_sys_content_t. Vous pouvez utiliser chcon ou rendre le changement persistant via semanage:

$ Sudo semanage fcontext -a -t httpd_sys_content_t "/srv/myapp(/.*)?"
$ Sudo restorecon -R -F /srv/myapp

Vous pouvez utiliser le contexte httpd_sys_rw_content_t où des autorisations d'écriture sont nécessaires.

0
sffc

Cela est probablement dû au fait que, avec la barre oblique de fin, NGinx tente de trouver le fichier d'index par défaut, probablement index.html, sans configuration. Sans la barre oblique finale, il tente de faire correspondre le service de test file qu'il ne peut pas trouver. Cela et/ou vous n'avez aucun fichier d'index par défaut dans le dossier testservice.

Essayez d’ajouter cette ligne à votre configuration server:

index  index.php index.html index.htm; // Or in the correct priority order for you

J'espère que cela t'aides!

Modifier 

Ma réponse n'est pas très claire, voir cet exemple pour comprendre ce que je veux dire

listen 80;

    server_name glo4000.mydomain.com www.glo4000.mydomain.com;


    access_log  /var/log/nginx/glo-4000.access.log;
    error_log /var/log/nginx/glo-4000.error_log;

    location / {
        root   /home/ul/glo-4000/;
        index  index.php index.html index.htm;
    }

    location ~ \.php$ {

        include fastcgi_params;
        fastcgi_pass   unix:/tmp/php5-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME /home/ul/glo-4000/$fastcgi_script_name;
    }
}
0
Johnride

Même problème.

Reason old open_basedir paramètres copiés avec un fichier utilisateur.ini non autorisé dans une sauvegarde

Solution supprimer

0
aexl