[bug] Files larger than 2Gb fail to upload using Web browser [Nextcloud 28]

ℹ️ Support
, ,
1

Nextcloud version: 28.0.2
Operating system and version: Debian 12
Apache or nginx version: Nginx reverse proxy, Apache on the backend
PHP version: php-fpm 8.2

It’s impossible to upload any file larger than 2Gb in the latest NC 28 using the web browser UI. The setup is done as per instruction here Nextcloud Installationsanleitung - Carsten Rieger IT-Services.

The file is being chunked, and upon receiving the last chunks an unexpected error shows up, leaving undeleted profile subfolder like %username%/uploads/web-file-upload-add6d25a9969d801/.

The NC desktop app syncs the same file without any issue. Nothing wrong is left in the Nginx backend or reverse proxy logs, so it looks like pure webclient bug. The only error is being thrown into nextcloud log upon the transaction failure:

   "Exception": "Sabre\\DAV\\Exception\\NotFound",
    "Message": "File with name //web-file-upload-add6d25a9969d801 could not be located",

Full exception is attached in JSON here { "reqId": "8hdAtOvzauecp1vDwrGC", "level": 0, "time": "17.02.2024., 15 - Pastebin.com

What could be the cause of this?

2

It’s impossible to upload any file larger than 2Gb in the latest NC 28 using the web browser UI. The setup is done as per instruction here Nextcloud Installationsanleitung - Carsten Rieger IT-Services.

That error suggests the path is getting lost somewhere. That’s really weird.

I can’t reproduce this (tested uploading a 6 GiB file in chunked mode w/o any problem with v28.0.2 FPM/Nginx).

Can you reproduce it with the official Nginx config example in the Admin Manual[1]?

The Nginx configs in (and linked from) that tutorial have an oddly flattened formatting. That’s weird and I have no idea why. Unrelated, but it does make analyzing much more challenging.

[1] https://docs.nextcloud.com

3

the Admin Manual Nginx config actually was a starting point, and after I noticed the problem, I made it in line with Nextcloud Installationsanleitung - Carsten Rieger IT-Services. Pretty standard config for vhost: upstream php-handler { server unix:/run/php/php-fpm.sock;}# Set the ` - Pastebin.com

Upd: things are even worse, the issue exist even with apache2 backend. Chunks uploading just drops. I’m not sure this could be TMP proxy size issue, since this is a 10mb chunks transfers…

image
image1196×354 32.9 KB

4

I suggest maybe stepping back and eliminating some variables.

the Admin Manual Nginx config actually was a starting point

Okay can you try it as-is to reproduce this?

Your provided config differs in some important ways. Most notably:

  • line 51 (the , is already included in $asset_immutable when it’s defined so this line doesn’t get the result you’re likely expecting)
  • line 52 (remove it)
  • 55-57 don’t look right

I don’t see any of these issues in any of my test environments, let alone production.

I tested latest v28.0.2 via Nginx as I said. And I all my lab ones are already Apache based.

I’m not sure this could be TMP proxy size issue

So there’s a reverse proxy in front of all this too? You didn’t mention that before. :slight_smile:

5

Yes, Nginx reverse proxy for HTTPS, but I see nothing wrong with its config https://pastebin.com/y6jUphB8. No glues in the proxy config, it just passthrough the chunks without any errors. I don’t understand why the desktop client transfers just fine on the same configuration.

I’ve stepped back to an old Apache backend config until the issue is understood, it certainly worked some time ago with the same proxy.

6

Did another test on the proxy, it looks like an attempt to remove the transfer folder to finish the uploading happens before it’s finished

ML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0"
192.168.1.1 - - [18/Feb/2024:14:23:20 +0300] "PUT /remote.php/dav/uploads/admin/web-file-upload-32c4b1b65aaf6326/199 HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0"
192.168.1.1 - - [18/Feb/2024:14:23:21 +0300] "PUT /remote.php/dav/uploads/admin/web-file-upload-32c4b1b65aaf6326/200 HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0"
192.168.1.1 - - [18/Feb/2024:14:23:21 +0300] "PUT /remote.php/dav/uploads/admin/web-file-upload-32c4b1b65aaf6326/201 HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0"
192.168.1.1 - - [18/Feb/2024:14:23:21 +0300] "PUT /remote.php/dav/uploads/admin/web-file-upload-32c4b1b65aaf6326/202 HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0"
192.168.1.1 - - [18/Feb/2024:14:23:22 +0300] "PUT /remote.php/dav/uploads/admin/web-file-upload-32c4b1b65aaf6326/203 HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0"
192.168.1.1 - - [18/Feb/2024:14:23:22 +0300] "PUT /remote.php/dav/uploads/admin/web-file-upload-32c4b1b65aaf6326/204 HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0"

192.168.1.1 - - [18/Feb/2024:14:23:22 +0300] "DELETE /remote.php/dav/uploads/admin/web-file-upload-32c4b1b65aaf6326 HTTP/2.0" 403 158 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0"

192.168.1.1 - - [18/Feb/2024:14:23:28 +0300] "PUT /remote.php/dav/uploads/admin/web-file-upload-32c4b1b65aaf6326/277 HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0"
7

Nothing wrong with a reverse proxy - Nextcloud sync client pass it’s chunks with no problems, CyberDuck transfers of 2Gb+ files are fine.

If I disable the chunking at all via occ --value 0, the upload simply doesn’t start at all.

8

this is a bug