Uploads fail when migrating to v5

The CMS Questions
1

Hi. I’m trying to migrate from Kirby v4 to v5. The issue I’m having is that file uploads no longer work.

The Kirby versions don’t matter and I can swap back and forth using Composer. Any v4 works and any v5 fails.

The error returned is A tmp file upload with the same filename and upload id already exists: xxxx-filename.ext. This is a NEW file upload so no file already exists. If I look at the network requests in Firefox’s developer tools I see 2 requests related to the uploads.

  • The first is a POST 200 with the response of “status: ok”.
  • The second is a POST 400 with the response “status: error, message: A tmp file upload with the same filename and upload id already exists: xxxx-filename.ext”.

The requests themselves look identical. I’m not sure why it’s sending 2 POST requests in quick succession.

Checking the server itself, sure enough, there is a 0KB file in the “site/cache/.uploads” directory. There are no errors in either the Nginx or PHP error logs.

I assume it’s an issue with the chunked upload feature but any file, be it 2GB or 90B fails. I’m not sure where else to look for any configuration issues as v4 has worked perfectly for years.

Edit: Running Nginx v1.29.5, PHP-FPM v8.4.18 both via Docker containers. I’ve also created brand new installations and tried to upload a simple avatar with the same results.

2

What does your nginx config look like? Something seems to be causing these duplicate post requests.

Do you also get the duplicate request on Kirby 4?

3

There’s no duplicate request on v4. I’m at a loss as to where the second request is coming from. The other thing is the file doesn’t appear to be uploaded at all with v5, even with the first request. There’s just a 0KB file in the .uploads directory.

I think the Nginx config is pretty standard:

server {
    listen      80;
    listen      [::]:80;
    server_name xxx.xxx.xxx;

    root /xxx/xxx/xxx;
    index index.html index.htm index.php;

    default_type text/plain;

    set_real_ip_from x.x.x.x;
    real_ip_header X-Forwarded-For;

    # Block access to Kirby specific folders.
    rewrite ^/(kirby|site)/(.*)$ /error last;

    # Block access to (dot) files and folders.
    rewrite ^/\.(?!well-known/) /error last;

    # Block access to Markdown content files.
    rewrite ^/content/(.*)\.md /error last;

    # Block other files in the site root.
    rewrite ^/(?!app\.webmanifest)[^/]+$ /index.php last;

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

    location ~* \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass   nginx-php:9000;
        fastcgi_index  index.php;
        include        fastcgi_params;
        fastcgi_param  PATH_INFO $fastcgi_path_info;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_param  REMOTE_ADDR $http_x_forwarded_for;
    }
}

The only other line that differs from the default nginx.conf is adding client_max_body_size 3096m; but I tested without that with no change. PHP config is default except the following:

memory_limit = 4096M
post_max_size = 0
upload_max_filesize = 3096M
max_file_uploads = 100

The fact I haven’t been able to find anybody else having the same issue tells me it must be something to do with my setup but I’m at a loss of where to look.

4

Maybe try and change the post_max_size to something else.

Needless to say that I haven’t run into such an issue myself yet.

5

I swear I tried different values for all of those settings but I must not have applied them (probably restarted Nginx instead of PHP).

Anyway, changing the post_max_size does indeed fix the issue. I also found the corresponding bug in Kirby and reported it. Setting to 0 initially was probably to fix some other issue I was having years ago and I never set it back, unlike the other values.

Thank you for your help though. I knew it’d be something simple.