Nginx returning 404 on new installation

Question

On Linux Mint 20.3 I had working setup for my local development of website:

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

This is a Laravel application located in /home/gacek/html/cbp directory, and the index.php entrypoint is located in /public subfolder.

After fresh installation of Linux Mint 21.1 the same nginx configuration gives me 404 not found:

404 Not Found nginx/1.18.0 (Ubuntu)

I tried:

• adjusting the ownership of directory: sudo chown -R gacek:www-data /home/gacek/html/cbp

• widening the permissions: sudo chmod -R 776 /home/gacek/html/cbp

• creating a symlink and adjusting nginx config file sudo ln -s /home/gacek/html/cbp /var/www/

The last one I tried because following config works perfectly fine:

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

Why this nginx site config is not working? Where is the difference between the two?

EDIT

I have changed the configuration using guide in Laravel docs:

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

After this change the error displayed on the page changed to:

File not found.

And now I get following errors in nginx's error log:

Answer 1

Looks to me like you're most of the way there - you've set up a specific directory to host the content and applied appropriate permissions to the directory, although you haven't confirmed what user nginx is running as, and whether that user is a member of the www-data group on the host.

I would suggest adding the user that nginx is running as to the www-data group and making sure that group has appropriate permissions

I would actually recommend that you don't make the content directory writeable by default as you have done unless you have a specific reason to do so - and if you do have a specific reason to do so, I'd probably create a dedicated subdirectory which is writeable whilst the root is not.

So in summary, probably:

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

You could actually go one step further to harden the directory permissions in only applying the above to directories/subdirectories, and applying chmod 644 to all files.

Edit: having searched online on your behalf elsewhere, this seems like a good candidate for the potential problem: you may have ProtectHome=true in the systemd init file for php-fpm.service.

1. Set ProtectHome=false in /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

Ironically, I did personally note that it was odd that you'd put the code in a home folder initially rather than, e.g. /var/www/html/ but decided to keep that to myself - turns out it was relevant!