Large uploads via public share link fail at the end behind Cloudflare: assembly (MOVE) aborted, then web uploader DELETEs the chunks

Apophenia_Post-produ · October 11, 2026, 3:33pm

Support intro

Sorry to hear you’re facing problems.

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

Official documentation (searchable and regularly updated)
How to topics and FAQs
Forum search

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can.

The Basics

Nextcloud Server version (e.g., 29.x.x):
- 35.0.1 (also seen on 34.0.x)
- Operating system and version (e.g., Ubuntu 24.04):
  - Debian 12 (bookworm), TurnKey Linux Nextcloud appliance 18.1, in a Proxmox VE 9 LXC container (4 vCPU, 8 GB RAM)
- Web server and version (e.g, Apache 2.4.25):
  - Apache 2.4.67 (Debian), mod_php
- Reverse proxy and version _(e.g. nginx 1.27.2)
  - Cloudflare Tunnel, cloudflared 2026.10.0, running in the same container, origin https://localhost:443
- PHP version (e.g, 8.3):
  - 8.4.20
- Is this the first time you’ve seen this error? (Yes / No):
  - No
- When did this problem seem to first start?
  - Noticed mid-September 2026 on 34.0.x; reproduced on 35.0.1 (October 2026)
- Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
  - Bare metal / archive (TurnKey appliance, Nextcloud updated with updater.phar)
- Are you using CloudfIare, mod_security, or similar? (Yes / No)
  - Yes. Cloudflare (Free plan) via Cloudflare Tunnel: fixed 100 s origin response timeout (HTTP 524), 100 MB request body limit. No mod_security. mod_evasive is loaded.

Summary of the issue you are facing:

Uploading a large file (~43 GB) through a public share link (file drop) with the web uploader fails at the very end. All chunk PUTs succeed (201). But the final MOVE …/.file (chunk assembly) takes much longer than Cloudflare’s 100 s timeout. On our storage, assembly runs at about 45 MB/s, so 43 GB takes about 17 minutes. Files up to about 4–5 GB work. Larger ones are lost.

Two behaviours destroy the upload:

apps/dav/appinfo/v2/publicremote.php does not call ignore_user_abort(true), unlike remote.php, direct.php and v1/webdav.php. When the proxy closes the connection, PHP aborts the assembly half-way (with the default ignore_user_abort = Off).
After the MOVE fails (524), the web uploader sends DELETE on the web-file-upload-<id> folder. The server may still be assembling. With ignore_user_abort = On set globally, the assembly keeps running, but this DELETE removes the chunks underneath it. It then fails with Could not open file: web-file-upload-<id>/75 … file doesn't seem to exist.

Workaround that works for us:

ignore_user_abort = On in Apache’s PHP config.
Block the uploader’s DELETE on public upload folders. OCA\DAV\BackgroundJob\UploadCleanup cleans up abandoned chunks after 24 h:
```
RewriteEngine On
RewriteCond %{REQUEST_METHOD} =DELETE
RewriteRule ^/public\.php/dav/uploads/ - [F]
```
With both in place, the 43 GB file landed complete about 17 min after the MOVE started. The filecache size equals the size on disk. The browser still shows an error at the end, so the sender thinks it failed.

Suggestions:

publicremote.php should call ignore_user_abort(true), like remote.php.
The web uploader should not delete the upload folder after a gateway timeout (502/504/524) on MOVE, since the server may still be assembling. It could poll or retry instead.
Ideally, an asynchronous assembly mode (respond 202 Accepted and let the client poll), so assembly does not depend on proxy timeouts.
Minor: public-share uploads used 100 MiB chunks although occ config:app:set files max_chunk_size --value 20971520 is set, so a smaller chunk size cannot be enforced for public uploads.

Steps to replicate it (hint: details matter!)

Put Nextcloud behind a reverse proxy with a ~100 s response timeout (Cloudflare Tunnel, Free plan). Use local/NFS storage where assembling the target file takes longer than 100 s.
Create a public share with upload permission (file drop) and open it in a browser (Chrome, Windows).
Upload a large file (here ~43 GB).
All chunks upload (201). At the end the browser gets 524 on MOVE …/.file, then the uploader sends DELETE …/web-file-upload-<id>. The file never appears.

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

(tokens, IDs and IP redacted; trace shortened)
```
{"reqId":"<id>","level":3,"time":"2026-10-10T02:21:17+00:00","remoteAddr":"<redacted>","user":"--","app":"webdav","method":"MOVE","url":"/public.php/dav/uploads/<token>/web-file-upload-<id>/.file","scriptName":"/public.php","message":"Could not open file: web-file-upload-<id>/75 (47369), file doesn't seem to exist","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36","version":"35.0.1.1","exception":{"Exception":"Sabre\\DAV\\Exception\\ServiceUnavailable","Message":"Could not open file: web-file-upload-<id>/75 (47369), file doesn't seem to exist","Code":0,"Trace":[{"file":"/var/www/nextcloud/apps/dav/lib/Upload/AssemblyStream.php","line":291,"function":"get","class":"OCA\\DAV\\Connector\\Sabre\\File","type":"->"},{"file":"/var/www/nextcloud/apps/dav/lib/Upload/AssemblyStream.php","line":157,"function":"getStream","class":"OCA\\DAV\\Upload\\AssemblyStream","type":"->"},{"function":"stream_read","class":"OCA\\DAV\\Upload\\AssemblyStream","type":"->"},{"file":"/var/www/nextcloud/3rdparty/icewind/streams/src/Wrapper.php","line":54,"function":"fread"}, …]}}
```
Earlier attempt, without `ignore_user_abort`: same message for chunk `/69` on the browser's retried MOVE, right after the first MOVE was cut at 100 s.

Web Browser

If the problem is related to the Web interface, open your browser inspector Console and Network tabs while refreshing (reloading) and reproducing the problem. Provide any relevant output/errors here that appear.

```
MOVE …/web-file-upload-<id>/.file   -> 524 (Cloudflare "A timeout occurred") after ~100 s
DELETE …/web-file-upload-<id>       -> sent by the uploader right after

Web server / Reverse Proxy

The output of your Apache/nginx/system log in /var/log/____:

Apache access log `/var/log/apache2/other_vhosts_access.log` (all requests come from cloudflared on 127.0.0.1; timestamps are request start):
```
[10/Oct/2026:02:18:13 +0000] "PUT /public.php/dav/uploads/<token>/web-file-upload-<id>/438 HTTP/1.1" 201 554
[10/Oct/2026:02:18:30 +0000] "MOVE /public.php/dav/uploads/<token>/web-file-upload-<id>/.file HTTP/1.1" 503 767
[10/Oct/2026:02:20:35 +0000] "DELETE /public.php/dav/uploads/<token>/web-file-upload-<id> HTTP/1.1" 204 2368
```
cloudflared:
```
2026-10-10T02:20:35Z ERR  error="Incoming request ended abruptly: context canceled" connIndex=0 event=1 ingressRule=0 originService=https://localhost:443
2026-10-10T02:20:35Z ERR failed to serve incoming request error="Failed to proxy HTTP: Incoming request ended abruptly: context canceled"
```
Successful run with the workaround: `MOVE` started 07:30:27 and logged 201. The uploader's `DELETE` at 07:32:32 got **403** (blocked). The file was complete on disk at 07:47:12.

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

`occ config:list system` (sensitive values removed):
```json
{
    "system": {
        "passwordsalt": "***REMOVED***",
        "secret": "***REMOVED***",
        "trusted_domains": ["localhost", "192.168.0.9", "<host>"],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "35.0.1.1",
        "overwrite.cli.url": "https://<host>",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED***",
        "dbpassword": "***REMOVED***",
        "installed": true,
        "instanceid": "***REMOVED***",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 0, "timeout": 0 },
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "log_type": "file",
        "logfile": "/var/www/nextcloud-data/nextcloud.log",
        "loglevel": 3,
        "overwriteprotocol": "https",
        "maintenance": false,
        "default_phone_region": "MK",
        "maintenance_window_start": 2,
        "check_data_directory_permissions": false,
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "ssl",
        "mail_smtpauth": true,
        "mail_smtpport": "465",
        "mail_sendmailmode": "smtp",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "forwarded_for_headers": ["HTTP_CF_CONNECTING_IP"],
        "tempdirectory": "/var/nextcloud-tmp"
    }
}
```
Other relevant settings: `files max_chunk_size = 20971520`; PHP `memory_limit = 512M`, `max_execution_time = 30`; `/var/nextcloud-tmp`, `data/<user>/files` and `data/<user>/uploads` are NFS mounts.

Apps

The output of occ app:list (if possible).

occ app:list --enabled:

activity 8.0.0, app_api 35.0.0, appstore 2.0.0-dev.0, bruteforcesettings 8.0.0, circles 35.0.0,
cloud_federation_api 2.0.0-dev.0, comments 2.0.0-dev.0, contactsinteraction 2.0.0-dev.0,
dashboard 8.0.0-dev.0, dav 2.0.0-dev.1, deliver 0.8.2, federatedfilesharing 2.0.0-dev.1,
federation 2.0.0-dev.0, files 3.0.0-dev.0, files_downloadlimit 5.3.0, files_external 2.0.0-dev.0,
files_lock 35.0.0, files_pdfviewer 8.0.0, files_reminders 2.0.0-dev.0, files_sharing 2.0.0-dev.1,
files_trashbin 2.0.0-dev.0, files_versions 2.0.0-dev.0, firstrunwizard 8.0.0, logreader 8.0.0,
lookup_server_connector 2.0.0-dev.0, nextcloud_announcements 7.0.0, notifications 8.0.0,
oauth2 2.0.0-dev.0, office 1.1.0, password_policy 7.0.0, photos 8.0.0, privacy 7.0.0,
profile 2.0.0-dev.0, provisioning_api 2.0.0-dev.0, recommendations 8.0.0, related_resources 6.0.0,
serverinfo 7.0.0, settings 2.0.0-dev.0, sharebymail 2.0.0-dev.0, sharing 1.0.4, support 7.0.0,
survey_client 7.0.0, systemtags 2.0.0-dev.0, text 9.0.0, theming 3.0.0-dev.0,
twofactor_backupcodes 2.0.0-dev.0, twofactor_totp 17.1.0, updatenotification 2.0.0-dev.0,
user_status 2.0.0-dev.0, viewer 8.0.0, weather_status 2.0.0-dev.0, webhook_listeners 2.0.0-dev.0,
workflowengine 3.0.0-dev.0

Tips for increasing the likelihood of a response

Use the preformatted text formatting option in the editor for all log entries and configuration output.
If screenshots are useful, feel free to include them.
- If possible, also include key error output in text form so it can be searched for.
Try to edit log output only minimally (if at all) so that it can be ran through analyzers / formatters by those trying to help you.

mritzmann · October 11, 2026, 5:22pm

Welcome to the forum

To me, your post doesn’t read like a support question (and entirely written by AI?), but more like a bug report or feature request. Probably a better place for something like that: