☰

Nginx gibt bei Neuinstallation 404 zurück

tag-icon • tag-icon nginx php php-fpm laravel linuxmint
Nginx gibt bei Neuinstallation 404 zurück

Unter Linux Mint 20.3 hatte ich ein funktionierendes Setup für meine lokale Website-Entwicklung:

server {
    listen 80;
    listen [::]:80;

    server_name cbp.local;

    root /home/gacek/html/cbp/public;

    index           index.php;

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

    if (!-d $request_filename) {
            rewrite     ^/(.+)/$ /$1 permanent;
    }

    location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        }
}

Dies ist eine Laravel-Anwendung im /home/gacek/html/cbpVerzeichnis und der index.phpEinstiegspunkt befindet sich in /publiceinem Unterordner.

Nach der Neuinstallation von Linux Mint 21.1 gibt mir die gleiche Nginx-Konfiguration die Fehlermeldung „404 nicht gefunden“:

404 Nicht gefunden nginx/1.18.0 (Ubuntu)

Ich habe es versucht:

  • Anpassen der Eigentümerschaft des Verzeichnisses: sudo chown -R gacek:www-data /home/gacek/html/cbp

  • Erweiterung der Berechtigungen:sudo chmod -R 776 /home/gacek/html/cbp

  • Erstellen eines Symlinks und Anpassen der Nginx-Konfigurationsdateisudo ln -s /home/gacek/html/cbp /var/www/

Das letzte habe ich probiert, da die folgende Konfiguration einwandfrei funktioniert:

server {
    listen 80;
    listen [::]:80;

    server_name example.local;

    root /var/www/test;
    index index.php;

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

    location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    }
}

Warum funktioniert diese Nginx-Site-Konfiguration nicht? Wo ist der Unterschied zwischen den beiden?

BEARBEITEN

Ich habe die Konfiguration geändert mitAnleitung in Laravel-Dokumenten:

server {
    listen 80;
    listen [::]:80;
    server_name cbp.local;
    root /home/gacek/html/cbp/public;
 
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";
 
    index index.php;
 
    charset utf-8;
 
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
 
    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }
 
    error_page 404 /index.php;
 
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME /home/gacek/html/cbp/public$fastcgi_script_name;
    }
 
    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Nach dieser Änderung änderte sich der auf der Seite angezeigte Fehler wie folgt:

File not found.

Und jetzt erhalte ich folgende Fehler im Fehlerprotokoll von Nginx:

Bildbeschreibung hier eingeben

Antwort1

Für mich sieht es so aus, als hätten Sie das Ziel fast erreicht: Sie haben ein spezielles Verzeichnis zum Hosten des Inhalts eingerichtet und dem Verzeichnis die entsprechenden Berechtigungen zugewiesen, allerdings haben Sie noch nicht bestätigt, als welcher Benutzer nginx ausgeführt wird und ob dieser Benutzer Mitglied der www-dataGruppe auf dem Host ist.

Ich würde vorschlagen, den Benutzer, unter dem nginx ausgeführt wird, zur www-dataGruppe hinzuzufügen und sicherzustellen, dass die Gruppe über die entsprechenden Berechtigungen verfügt

Ich würde Ihnen eigentlich empfehlen, das Inhaltsverzeichnis nicht standardmäßig beschreibbar zu machen, wie Sie es getan haben, es sei denn, Sie haben einen bestimmten Grund dafür. Und wenn Sie einen bestimmten Grund dafür haben, würde ich wahrscheinlich ein dediziertes Unterverzeichnis erstellen, das beschreibbar ist, während das Stammverzeichnis beschreibbar ist.

Zusammenfassend lässt sich also wahrscheinlich sagen:

usermod -aG nginx www-data
chmod -R 755 /home/gacek/html/cbp

Sie könnten sogar noch einen Schritt weiter gehen und die Verzeichnisberechtigungen verschärfen, indem Sie die oben genannten Berechtigungen nur auf Verzeichnisse/Unterverzeichnisse und dann chmod 644auf alle Dateien anwenden.

Bearbeiten:nachdem ich in Ihrem Namen online gesucht habeanderswo, dies scheint ein guter Kandidat für das potenzielle Problem zu sein: Möglicherweise haben Sie ProtectHome=truein der systemd-Init-Datei für php-fpm.service.

  1. Eingesetzt ProtectHome=falsein/etc/systemd/system/multi-user.target.wants/php-fpm.service
  2. systemctl daemon-reload
  3. systemctl restart nginx.service
  4. systemctl restart php-fpm.service

Ironischerweise fand ich es persönlich merkwürdig, dass Sie den Code zunächst in einem Home-Ordner und nicht beispielsweise abgelegt hatten, /var/www/html/aber ich beschloss, das für mich zu behalten – es stellte sich heraus, dass es relevant war!

verwandte Informationen