"File not found."

[BurnyLlama]

I don't know if this has to do with pico or not, but whenever I try to visit my site running pico the only thing I see is a message saying "File not found."

Output of php -v:

PHP 8.0.8 (cli) (built: Jun 29 2021 18:53:53) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.8, Copyright (c) Zend Technologies

Output of php -m:

[PHP Modules]
Core
ctype
curl
date
dom
fileinfo
filter
hash
json
libxml
mbstring
mysqlnd
openssl
pcntl
pcre
PDO
Phar
posix
readline
Reflection
session
SimpleXML
SPL
standard
tokenizer
xml
xmlreader
xmlwriter
zip
zlib

[Zend Modules]

My nginx config file for the site:

server {
    server_name blog.my-site.tld;

    listen 443 ssl http2;
    include /etc/nginx/ssl.conf;

    root /srv/http/pico;
    index index.php;

    location ~ ^/((config|content|vendor|composer\.(json|lock|phar))(/|$)|(.+/)?\.(?!well-known(/|$))) {
        try_files /index.php$is_args$args =404;
    }

    location ~ \.php$ {
        try_files $uri =404;

        fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;

        # Let Pico know about available URL rewriting
        fastcgi_param PICO_URL_REWRITING 1;
    }

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }
}

I installed pico using composer. I am also running Artix Linux - if that matters.

Do anyone know anything about this and/or how to fix this?

Thanks in advance! :)

[mayamcdougall]

Hello.

@PhrozenByte will probably be able to help you with this issue in the next couple days, but he's away at the moment. I just wanted to reply in the meantime so you weren't left hanging.

As far as I know, Pico shouldn't ever display a "File not found" error, so this is likely being thrown by either Nginx or PHP.

Any advice I give here is going to be a "shot in the dark", but who knows, we might stumble upon something.

I'd probably start by checking your file permissions and directory structure and make sure everything looks right. Make sure index.php is where you expect it to be, etc. I usually install Pico via the pre-bundled release instead of composer, and you could always try that if something looks off.

AFAIK, the current release of Pico is not yet compatible with PHP 8, but it would be throwing an exception (or a blank page with errors turned off) if it were getting that far. This might also be a non-issue with a composer install anyway, since I believe it's dependency related. If you did want to try a pre-bundled release, there's a pre-release version that mainly just features updated dependencies for PHP 8.

You might also try an older PHP version (the AUR should have all the older major versions available) and see if that makes a difference.

I do think that this is probably just a configuration / setup issue though, so maybe wait for the expert to weigh in before making any big changes to your server. 😅

Sorry I can't be of more help. 😔

If you don't figure it out in the next couple days, I'm sure @PhrozenByte will be able to get you sorted out once he's available again.

[BurnyLlama]

Hello.

@PhrozenByte will probably be able to help you with this issue in the next couple days, but he's away at the moment. I just wanted to reply in the meantime so you weren't left hanging.

As far as I know, Pico shouldn't ever display a "File not found" error, so this is likely being thrown by either Nginx or PHP.

Any advice I give here is going to be a "shot in the dark", but who knows, we might stumble upon something.

I'd probably start by checking your file permissions and directory structure and make sure everything looks right. Make sure index.php is where you expect it to be, etc. I usually install Pico via the pre-bundled release instead of composer, and you could always try that if something looks off.

AFAIK, the current release of Pico is not yet compatible with PHP 8, but it would be throwing an exception (or a blank page with errors turned off) if it were getting that far. This might also be a non-issue with a composer install anyway, since I believe it's dependency related. If you did want to try a pre-bundled release, there's a pre-release version that mainly just features updated dependencies for PHP 8.

You might also try an older PHP version (the AUR should have all the older major versions available) and see if that makes a difference.

I do think that this is probably just a configuration / setup issue though, so maybe wait for the expert to weigh in before making any big changes to your server. 😅

Sorry I can't be of more help. 😔

If you don't figure it out in the next couple days, I'm sure @PhrozenByte will be able to get you sorted out once he's available again.

Thanks!

I'll probably try downgrading my PHP and see if that would work. :)

[PhrozenByte]

@mayamcdougall pretty much summed up everything. You could also try to create a info.php with just <?php phpinfo(); in it. If this file also yields a File not found error, there's definitely some issue with your webserver resp. PHP setup.

We can try to track this down a little bit more: Is this an error of nginx, or just a plain "File not found" string with nothing else around (usually shown in a monospace font in your browser)? If it's the latter, there's something wrong with your PHP setup, likely you misconfigured PHP-FPM's base path. If it's nginx's "404 File not found" error, I'd rather assume some file permissions error (e.g. an invalid file owner).

[BurnyLlama]

I've forgot to look into it more, but the error does not seem to come from nginx as it doesn't say nginx anywhere.

My php/nginx is prolly misconfigured somewhere. (Wouldn't surprise me .)

[JoshuaPettus]

I had the same problem with the nginx directions given in the picocms documentation. But then I found this guide https://www.howtoforge.com/how-to-install-pico-cms-on-debian-10/

Granted not all of it was applicable to me, but the take a look at the suggested configuration for the picocms locations in the nginx config. This got it working nicely. Obviously edit the php-fpm sock line for the version of php you are using

[EDIT] There was an older guide I was confusing it with sorry about that

[PhrozenByte]

Off Topic:

@mayamcdougall Do you still use nginx? Even tough I'm not so sure whether you ever really used it :smile: According to https://www.howtoforge.com/how-to-install-pico-cms-on-debian-10/ the location ~ \.php$ { … } section is placed after the location / { … } section. Since I still don't use nginx (and basically gave up trying to understand nginx's config) I've no idea which one is right, but might this be our issue with https://picocms.org/in-depth/nginx/ all this time? A lot of people have problems with setting nginx up...

[mayamcdougall]

When I first did the Nginx Documentation, I was fresh off of a deep dive into Nginx. I did use it, and technically still do, however, I run just about everything through Docker these days. I've had the same Nginx config files for years now, and I pretty much just copy and paste when I need to roll out a new site / subdomain. Having it in a pre-configured container takes care of a lot of the setup and hassle.

I've been so far removed from doing Nginx config that I haven't really felt qualified to do anything around it, but I guess maybe you're not in the best shape either. 😅

Some very brief googling (so, this could be wrong) suggests that it doesn't matter what order they are in. A regex match will always be picked if it matches, and if it doesn't then Nginx falls back on whatever static location matched.

The biggest problem with Nginx when I used it was configuring php-fpm. Since unlike Apache, it's not built-in, I remember being able to run into a fair number of headaches getting them working together. Where I'm using it at the moment is actually in a combination Nginx/php-fpm container to make it easier.

I've actually been doing a little stuff with Caddy lately. Its built-in SSL is really handy. Caddy has become my reverse-proxy of choice (previously used an Nginx based container, but again, configuring the container was very removed from actually configuring Nginx). Learning how to get Caddy set up with php-fpm has been on my todo list. I figured if I got that working I could probably add a section to the Pico docs for it. (Can't be that hard. 😉)

When I have some time for that, I'll see if I can't also test out our Nginx docs and see if something needs to be revised.

[mayamcdougall]

@BurnyLlama I'm out of time right now, but I'm going to investigate php-fpm under Arch when I get a minute (I tried to search the wiki really quick, but I couldn't find an answer).

Can you check that your php-fpm socket is at /var/run/php-fpm/php-fpm.sock;? I think you should just be able to ls and see if it's there.

Also, you could try changing that line to fastcgi_pass 127.0.0.1:9000; instead if php-fpm is running on port 9000.

These all might be options you can configure. The Arch wiki page for PHP doesn't mention php-fpm, and I can't seem to find a page specifically for it right now. There should be one though... 🤔

It was just a sudden thought that maybe PHP isn't listening where you think it is... (inspired by the conversation above about getting Nginx and php-fpm to talk to each other being annoying, lol).

Got to go, but might be worth looking in to. I'll check later if I have time.

[JoshuaPettus]

I use Ubuntu so maybe it's different, by my php-fpm.sock was at

/var/run/php/php8.0-fpm.sock;`

(the php version is part of the filename)

I think the key difference that is missing in picocms's documentation is the line:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

In fact, when I did some quick google fu on the "File not found" error for NGINX, a few threads mentioned that that almost always had to do with fastcgi_param SCRIPT_FILENAME was not pointing to the correct place (didn't know what that meant but then I found this guide)

[mayamcdougall]

@JoshuaPettus SCRIPT_FILENAME should be provided by include fastcgi_params;.

It's possible that this might vary from system to system though, so I'm not saying that it couldn't be the problem.

Specifically, the information I found in the Nginx docs said that this was provided on Debian-based distros at /etc/nginx/fastcgi_params. I also ran Arch on my server (iirc) when I worked on the our Nginx example, so it is likely provided on other distros too, but might not be guaranteed.

(Edit: I just checked and at least Arch and Fedora do also ship this file.)

Mostly just taking note of it for myself later and sharing it for reference. 😅

[mayamcdougall]

Alright, so, I wrote this comment after being kind of "stuck" on the idea that Nginx and PHP weren't talking, when that's really probably not the case since it's likely what's throwing the "File Not Found" error, and if they weren't talking it would probably be a "Connection Refused" type of error. I'm posting this anyway just as extra information, but you can probably disregard it.

You should probably give @JoshuaPettus's idea a try. Although this parameter should be provided by include fastcgi_params;, googling does reveal an awful lot of claims that it fixed similar issues, even when users already had include fastcgi_params; in their config. I really don't know why it would make a difference, since it should be redundant, but I'd be interested in knowing if it fixes things.

---

Original comment: @BurnyLlama Okay, so I took a look at Arch's default php-fpm config. In /etc/php/php-fpm.d/www.conf I found that by default it's set to listen at /run/php-fpm/php-fpm.sock, so try removing the /var at the start of your fastcgi_pass line and see if that makes a difference for you.

Also, like I suggested in a previous comment, maybe try navigating to that location on your filesystem and see if you can see the .sock file. Another thing to check is that you've actually got php-fpm running (it should be its own service to enable/start with systemctl). I know that last one's a bit of a "duh" tip, but I feel like if I didn't mention it, it would somehow end up being the problem.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1: