Nginx retornando 404 em nova instalação

Question

No Linux Mint 20.3 eu tinha uma configuração funcional para o desenvolvimento local do meu site:

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

Este é um aplicativo Laravel localizado no /home/gacek/html/cbpdiretório e o index.phpponto de entrada está localizado na /publicsubpasta.

Após a nova instalação do Linux Mint 21.1, a mesma configuração do nginx me dá 404 não encontrado:

404 Não encontrado nginx/1.18.0 (Ubuntu)

Tentei:

• ajustando a propriedade do diretório: sudo chown -R gacek:www-data /home/gacek/html/cbp

• ampliando as permissões:sudo chmod -R 776 /home/gacek/html/cbp

• criando um link simbólico e ajustando o arquivo de configuração nginxsudo ln -s /home/gacek/html/cbp /var/www/

O último que tentei porque a seguinte configuração funciona perfeitamente:

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 que esta configuração do site nginx não está funcionando? Onde está a diferença entre os dois?

EDITAR

Eu mudei a configuração usandoguia em documentos do 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;
    }
}

Após esta alteração o erro exibido na página mudou para:

File not found.

E agora recebo os seguintes erros no log de erros do nginx:

Answer 1

Parece-me que você já chegou lá - você configurou um diretório específico para hospedar o conteúdo e aplicou as permissões apropriadas ao diretório, embora não tenha confirmado qual usuário o nginx está executando e se esse usuário é um membro do www-datagrupo no host.

Eu sugeriria adicionar o usuário que o nginx está executando ao www-datagrupo e garantir que esse grupo tenha as permissões apropriadas

Na verdade, eu recomendaria que você não tornasse o diretório de conteúdo gravável por padrão, como fez, a menos que tenha um motivo específico para fazer isso - e se você tiver um motivo específico para fazer isso, provavelmente criaria um subdiretório dedicado que é gravável, enquanto a raiz não é.

Então, em resumo, provavelmente:

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

Na verdade, você poderia dar um passo adiante para proteger as permissões do diretório aplicando apenas o acima aos diretórios/subdiretórios e aplicando chmod 644a todos os arquivos.

Editar:tendo pesquisado on-line em seu nomeem outro lugar, este parece ser um bom candidato para o problema potencial: você pode ter ProtectHome=trueno arquivo init do systemd para php-fpm.service.

1. DefinirProtectHome=false​/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

Ironicamente, eu pessoalmente observei que era estranho você ter colocado o código inicialmente em uma pasta pessoal, em vez de, por exemplo, /var/www/html/mas decidi guardar isso para mim - descobri que era relevante!