☰

Unerwartete 404-Antwort von php-fpm, wenn die Datei vorhanden und lesbar ist

tag-icon • tag-icon nginx php-fpm arch-linux
Unerwartete 404-Antwort von php-fpm, wenn die Datei vorhanden und lesbar ist

Ich betreibe eine einfache PHP-basierte Site mit nginx. Nach einem kürzlichen Update einiger Systemkomponenten funktionierte die Site nicht mehr. Wenn ich versuche, auf die Site zuzugreifen, erhalte ich eine leere Seite mit dem Text „Datei nicht gefunden“. Die Serverprotokolle sagen mir, dass

FastCGI hat beim Lesen des Antwortheaders vom Upstream in stderr Folgendes gesendet: „Primäres Skript unbekannt“

und das PHP-Log enthält

- - 25/Jan/2020:17:18:50 +0100 "GET /index.php" 404 - 0.151 2048 0.00%

Die Nginx-Konfiguration ist wie folgt.

# configuration file /etc/nginx/nginx.conf:

user http http;
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    types_hash_max_size 2048;
    types_hash_bucket_size 128;

    sendfile        on;

    keepalive_timeout  65;

    # some server blocks elided

    include /home/myuser/www/com.mydomain.conf;
}

# configuration file /etc/nginx/mime.types:
types {
application/A2L                    a2l;
# lots of types elided so as not to exceed post size limit
}

# configuration file /etc/nginx/fastcgi.conf:

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;
fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;


# configuration file /home/myuser/www/com.mydomain.conf:
server {
  listen 80;
  server_name mydomain.com;
  # enforce https
  return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name mydomain.com;

    client_max_body_size 16m;

    root /home/myuser/www/com.mydomain;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        try_files $uri $fastcgi_script_name =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_index index.php;
        fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
   }
}

nginx und php-fpm werden als Benutzer ausgeführt httpund index.phpdieser Benutzer kann auf die Datei zugreifen:

-rwxrwxr-x 1 http http 1,7K  8. Nov 10:40 /home/myuser/www/com.mydomain/index.php

Ich habe dies festgestellt $document_rootund $fastcgi_script_nameliege mit der Weitergabe der Prüfung richtig SCRIPT_NAME.

Was mache ich falsch?

Bearbeiten:Das sieht tatsächlich nach einem Berechtigungsproblem aus, aber ich verstehe es immer noch nicht. Wenn ich den Inhalt der Site zu /usr/share/webapps/Testzwecken verschiebe, funktioniert es. Leider ist das keine Option für den Produktionseinsatz. Mit den Dateien an ihrem vorgesehenen (ursprünglichen) Speicherort kann ich Dinge wie ausführen sudo -u http php /home/myuser/www/com.mydomain/test.phpund das erwartete Ergebnis erhalten. Was könnte php-fpm (oder den Socket) daran hindern, auf diese Dateien zuzugreifen? open_basedirist nicht festgelegt.

Antwort1

Abgesehen von all den Dingen, die bei der Interaktion zwischen nginx und php-fpm schiefgehen können (die in mehreren Fragen auf dieser Site diskutiert werden), birgt systemd noch eine weitere Falle, die sich in diesem Fall als Ursache herausstellte.

Die Unit-Datei php-fpm.service enthielt die ProtectHome=trueDirektive. Ich konnte dies beheben, indem ich Folgendes ausführte systemctl edit php-fpm.serviceund angab:

[Service]
ProtectHome=false

verwandte Informationen