Nginx devuelve 404 en una nueva instalación

Question

En Linux Mint 20.3 tenía una configuración funcional para el desarrollo local de mi sitio web:

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;
        }
}

Esta es una aplicación Laravel ubicada en /home/gacek/html/cbpel directorio y el index.phppunto de entrada se encuentra en /publicla subcarpeta.

Después de una nueva instalación de Linux Mint 21.1, la misma configuración de nginx me da 404 no encontrado:

404 No encontrado nginx/1.18.0 (Ubuntu)

Lo intenté:

• ajustando la propiedad del directorio: sudo chown -R gacek:www-data /home/gacek/html/cbp

• ampliando los permisos:sudo chmod -R 776 /home/gacek/html/cbp

• creando un enlace simbólico y ajustando el archivo de configuración de nginxsudo ln -s /home/gacek/html/cbp /var/www/

El último que probé porque la siguiente configuración funciona perfectamente bien:

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;
    }
}

¿Por qué esta configuración del sitio nginx no funciona? ¿Dónde está la diferencia entre los dos?

EDITAR

He cambiado la configuración usandoguía en documentos de Laravel:

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;
    }
}

Después de este cambio, el error mostrado en la página cambió a:

File not found.

Y ahora recibo los siguientes errores en el registro de errores de nginx:

Answer 1

Me parece que ya ha recorrido la mayor parte del camino: configuró un directorio específico para alojar el contenido y aplicó los permisos apropiados al directorio, aunque no ha confirmado con qué usuario se está ejecutando nginx y si ese usuario es miembro del www-datagrupo en el host.

Sugeriría agregar al usuario que nginx está ejecutando como www-datagrupo y asegurarse de que ese grupo tenga los permisos adecuados.

De hecho, recomendaría que no permita que se pueda escribir en el directorio de contenido de forma predeterminada, como lo ha hecho, a menos que tenga una razón específica para hacerlo, y si tiene una razón específica para hacerlo, probablemente crearía un subdirectorio dedicado. que se puede escribir mientras que la raíz no.

Entonces, en resumen, probablemente:

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

De hecho, podría ir un paso más allá para reforzar los permisos del directorio aplicando lo anterior solo a directorios/subdirectorios y aplicándolo chmod 644a todos los archivos.

Editar:haber buscado en línea en su nombreen otra parte, esto parece un buen candidato para el problema potencial: es posible que tenga ProtectHome=trueen el archivo de inicio systemd para php-fpm.service.

1. Establecer ProtectHome=falseen/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

Irónicamente, personalmente noté que era extraño que inicialmente pusieras el código en una carpeta de inicio en lugar de, por ejemplo, /var/www/html/pero decidí guardármelo para mí: ¡resulta que era relevante!