Rclone PUTs >5GB to WebDAV loop and fail on Kubernetes NGINX ingress

Help and Support
1

STOP and READ USE THIS TEMPLATE NO EXCEPTIONS - By not using this, you waste your time, our time and really hate puppies. Please remove these two lines and that will confirm you have read them.

What is the problem you are having with rclone?

What is the problem you are having with rclone?

I am trying to upload large files (~5GB+) from Azure Blob Storage to a WebDAV server running on Kubernetes behind a dual NGINX ingress setup.
Small files work fine, but large files repeatedly fail: NGINX logs show that the PUT request is buffered to a temporary file, then the client closes the connection (HTTP 499), and rclone retries endlessly. The file never finishes uploading.
Transferring files from WebDAV to Azure Blob works correctly, including large files.

Both ingresses have annotations to disable buffering (proxy-request-buffering: "off") and increase proxy-body-size. Despite this, large uploads are still being buffered and fail.

Run the command 'rclone version' and share the full output of the command.

rclone v1.71.0

  • os/version: Microsoft Windows 11 Enterprise 24H2 24H2 (64 bit)
  • os/kernel: 10.0.26100.4946 (x86_64)
  • os/type: windows
  • os/arch: amd64
  • go/version: go1.24.2
  • go/linking: static
  • go/tags: cmount

Which cloud storage system are you using? (eg Google Drive)

Azure Blob Storage

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone copy azure-so:demo-container/output-large.txt webdav:/

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[azure-so]
type = azureblob
account = XXX
key = XXX

[local]
type = local

[webdav]
type = webdav
url = XXX
vendor = other
user = XXX
pass = XXX

A log from the command that you were trying to run with the -vv flag

$ rclone copy azure-so:demo-container/output-large.txt webdav:/ -vv2025/09/08 14:34:27 DEBUG : Setting --config "C:\Users\chrys\local-exe\rclone\rclone.config" from environment variable RCLONE_CONFIG="C:\Users\chrys\local-exe\rclone\rclone.config"2025/09/08 14:34:27 DEBUG : rclone: Version "v1.69.2" starting with parameters ["C:\Users\chrys\local-exe\rclone\rclone.exe" "copy" "azure-so:demo-container/output-large.txt" "webdav:/" "-vv"]2025/09/08 14:34:27 DEBUG : Creating backend with remote "azure-so:demo-container/output-large.txt"2025/09/08 14:34:27 DEBUG : Using config file from "C:\Users\chrys\local-exe\rclone\rclone.config"2025/09/08 14:35:59 DEBUG : pacer: low level retry 1/10 (error dial tcp 20.150.125.193:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)2025/09/08 14:35:59 DEBUG : pacer: Rate limited, increasing sleep to 10ms2025/09/08 14:37:31 DEBUG : pacer: low level retry 2/10 (error dial tcp 20.150.125.193:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)2025/09/08 14:37:31 DEBUG : pacer: Rate limited, increasing sleep to 20ms2025/09/08 14:39:06 DEBUG : pacer: low level retry 3/10 (error dial tcp 20.150.125.193:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)2025/09/08 14:39:06 DEBUG : pacer: Rate limited, increasing sleep to 40ms
2

welcome to the forum,

should rclone selfupdate and test again.

can you test the webdav server using another webdav client other than rclone?

3

Something is timing out, but exactly what will need more investigation. Rclone default timeout is 5 minutes.

Try increasing --timeout on rclone, that might help.

How long is it taking to timeout - that might give a clue

4

I updated rclone to v1.71.
Yes, I tested the WebDAV server using another client. I port-forwarded the WebDAV service to localhost and then used curl to upload the large dataset. The upload succeeded, so the WebDAV server itself works fine.

This indicates that the problem is with the ingress, because bypassing the ingress allows large files to upload successfully, whereas going through the ingress causes the upload to fail and loop.

5

I don’t think it’s a timeout. I tested with rclone against the WebDAV server directly by port-forwarding and bypassing the ingress, and the upload of the large file worked fine without setting any --timeout flag. The problem only appears when going through the ingress, so it looks like the ingress itself is causing the issue rather than a timeout in rclone.

6

I would look at Nginx's proxy_send_timeout directive.
Also consider setting proxy_buffering to off.

7

Thank you for the suggestion. I have already set proxy_buffering to off, but Nginx still seems to be buffering.

Ingress log:
[warn] 64#64: *2107 a client request body is buffered to a temporary file /tmp/nginx/client-body/0000000002

Rclone log:

rclone copy output.txt webdav:/ -vv --progress --stats 1 --ignore-size
2025/09/09 09:13:10 DEBUG : Setting --config "C:\\Users\\user\\local-exe\\rclone\\rclone.config" from environment variable RCLONE_CONFIG="C:\\Users\\user\\local-exe\\rclone\\rclone.config"
2025/09/09 09:13:10 DEBUG : rclone: Version "v1.71.0" starting with parameters ["C:\\Users\\user\\local-exe\\rclone\\rclone.exe" "copy" "output.txt" "webdav:/" "-vv" "--progress" "--stats" "1" "--ignore-size"]
2025/09/09 09:13:10 DEBUG : Creating backend with remote "output.txt"
2025/09/09 09:13:10 DEBUG : Using config file from "C:\\Users\\user\\local-exe\\rclone\\rclone.config"
2025/09/09 09:13:10 DEBUG : fs cache: renaming child cache item "output.txt" to be canonical for parent "//?/C:/Users/t10000a/Downloads"
2025/09/09 09:13:10 DEBUG : Creating backend with remote "webdav:/"
2025/09/09 09:13:10 DEBUG : found headers:
2025/09/09 09:13:10 DEBUG : fs cache: renaming cache item "webdav:/" to be canonical "webdav:"
2025/09/09 09:13:10 DEBUG : output.txt: Need to transfer - File not found at Destination
2025/09/09 09:13:10 DEBUG : output.txt: Update will use the normal upload strategy (no chunks)
2025/09/09 09:14:11 DEBUG : pacer: low level retry 1/1 (error Put "https://webdav-poc.stonebranch.qs.datev.de/output.txt": unexpected EOF)
2025/09/09 09:14:11 DEBUG : pacer: Rate limited, increasing sleep to 20ms
2025/09/09 09:14:12 DEBUG : pacer: Reducing sleep to 15ms
2025/09/09 09:14:12 DEBUG : output.txt: Received error: unchunked simple update failed: Put "https://xxx": unexpected EOF - low level retry 0/10
2025/09/09 09:14:12 DEBUG : output.txt: Update will use the normal upload strategy (no chunks)
2025/09/09 09:15:16 DEBUG : pacer: low level retry 1/1 (error Put "https://xxx": unexpected EOF)
2025/09/09 09:15:16 DEBUG : pacer: Rate limited, increasing sleep to 30ms
2025/09/09 09:15:17 DEBUG : pacer: Reducing sleep to 22.5ms
2025/09/09 09:15:17 DEBUG : output.txt: Received error: unchunked simple update failed: Put "https://xxx": unexpected EOF - low level retry 1/10
2025/09/09 09:15:17 DEBUG : output.txt: Update will use the normal upload strategy (no chunks)
Transferred:       14.524 GiB / 15 GiB, 97%, 90.391 MiB/s, ETA 5s
Transferred:            0 / 1, 0%
Elapsed time:      2m57.9s

It seems like buffering might not be the root cause of the issue. Looking at the rclone behavior, it restarts the transfer after completing 5GB.

Could this indicate a different issue, such as a limitation on the WebDAV server or a timeout in the connection? Do you have any thoughts or suggestions on what else I might need to check?

8

The central ingress had ModSecurity enabled. After disabling it, the transfer was successful. Thank you very much for your help!