Score:1

Nginx returning 404 on new installation

ua flag

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:

enter image description here

Richard Smith avatar
jp flag
That configuration does not contain a statement which generates "404 not found". Check the access and error logs for more details. Use `nginx -T` to view the entire configuration across all included files.
Gacek avatar
ua flag
@RichardSmith - I have edited my question, added some logs from error log
Score:0
us flag

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!

Gacek avatar
ua flag
Thanks @BE77Y, I have already done that - without change. Nginx is running as www-data
us flag
OK - how about the php-fpm socket you configured, `/var/run/php/php8.2-fpm.sock` - is that also owned by www-data?
Gacek avatar
ua flag
yes - www-data:www-data
us flag
This answer appears to be relating to the same issue (reviewing the error screenshot again it looks like an issue passing paths to php-fpm to me): [link](https://serverfault.com/questions/948898/nginx-and-php-fpm-primary-script-unknown-while-reading-response-header-from-u)
us flag
Actually scratch that - I think I've found the issue here - see my edit in the post @Gacek.
Gacek avatar
ua flag
gacek:~ $ systemctl restart php-fpm.service Failed to restart php-fpm.service: Unit php-fpm.service not found.
Gacek avatar
ua flag
Yeah, it was important to keep it in home folder, but I gave up. Just moved it to /var/www/cbp and it works. Thanks
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.