Copying files larger than 10 MB does not work

[zumlernen-de]

Describe the bug

When attempting to copy files larger than 10MB via the WebUI, the operation fails silently. There is no error message; the user receives a "File copied successfully" notification, but the file is never actually copied.

This is particularly problematic when copying folders that contain such files. The system reports the operation as successful because all other files/folders are copied correctly, but the large files are missing from the destination.

If we download the files locally and upload them manually, everything is transferred correctly. Therefore, the error appears to be specific to the copy/cut function within the WebUI.

Edit: The issue seems to be the client_max_body_size 10M; setting in the nginx reverse proxy settings (opencloud part) as provided on your website. Increasing the size enables copying files via the Web UI. I'm not sure if there's an possibility to overcome this issue without raising the setting / disable the uploadlimit via client_max_body_size 0; to enable large files, as the manual upload of large files works fine even with this setting at 10MB. Nevertheless: The Web UI should show an error, if there's an failed copy attempt.

Steps to reproduce

1. Select a file (e.g., .zip, .docx) larger than 10MB in the WebUI.
2. Copy the file.
3. Paste the file into another location.
4. A successful message appears, but the file is not copied.

Expected behavior

The file should be copied to the destination successfully. If it fails the Web UI should show an error message.

Actual behavior

The file is not copied, despite the success message.

Setup

We use the standard docker-compose setup on version 4.0.1 Stable behind a reverse proxy (also standard installation as described in https://docs.opencloud.eu/docs/admin/getting-started/container/docker-compose/external-proxy/) with the following configuration:

COMPOSE_FILE=docker-compose.yml:weboffice/collabora.yml:external-proxy/opencloud.yml:external-proxy/collabora.yml:idm/external-idp.yml

We use an external Keycloak for authentication, which provisions users stored in the LDAP provided by the predefined LDAP container.

OC_XXX=somevalue
OC_YYY=somevalue
PROXY_XXX=somevalue

Additional context

Relevant error messages:

opencloud-1  | {"level":"error","service":"frontend","host.name":"3b20a4a26a1a","pkg":"rhttp","traceid":"e18c9f59b04bc04a1e4e8f7a0d9023bf","request-id":"3b20a4a26a1a/VkyoiMjuaG-574614","error":"write tcp 127.0.0.1:9140->127.0.0.1:42300: write: connection reset by peer","time":"2026-01-22T09:24:52Z","message":"error writing body after header were set"}
opencloud-1  | {"level":"error","service":"frontend","host.name":"3b20a4a26a1a","pkg":"rhttp","traceid":"e18c9f59b04bc04a1e4e8f7a0d9023bf","request-id":"3b20a4a26a1a/VkyoiMjuaG-574614","content-length":71623875,"transferred-bytes":10417733,"time":"2026-01-22T09:24:52Z","message":"content length vs transferred bytes mismatch"}
opencloud-1  | {"level":"error","service":"storage-users","host.name":"3b20a4a26a1a","pkg":"rhttp","datatx":"spaces","spaceid":"947d4cd2-185c-40bf-8cf4-97732ae5a47e$4f2e7cc1-f766-4063-961e-3771e491ad42!68f708d6-25e3-45c0-a533-86b68245ca64","path":"/","request-id":"3b20a4a26a1a/VkyoiMjuaG-574615","svc":"datatx","handler":"download","error":"write tcp 127.0.0.1:9158->127.0.0.1:52088: write: connection reset by peer","resourceid":{"storage_id":"947d4cd2-185c-40bf-8cf4-97732ae5a47e","opaque_id":"68f708d6-25e3-45c0-a533-86b68245ca64","space_id":"4f2e7cc1-f766-4063-961e-3771e491ad42"},"time":"2026-01-22T09:24:52Z","message":"error copying data to response"}

[micbar]

Which reverse proxy are you using?

I see "content-length":71623875,"transferred-bytes":10417733,"time":"2026-01-22T09:24:52Z","message":"content length vs transferred bytes mismatch" in your log.

That means that the request from the Web Client has been altered before it reaches the OpenCloud Server.

[micbar]

Edit: The issue seems to be the client_max_body_size 10M; setting in the nginx reverse proxy settings (opencloud part) as provided on your website. Increasing the size enables copying files via the Web UI. I'm not sure if there's an possibility to overcome this issue without raising the setting / disable the uploadlimit via client_max_body_size 0;

Now i see. Ignore my comment from before.

This is indeed a shortcoming of the COPY feature. All normal file uplaods are using TUS which allows large files to be uploaded in chunks.

The COPY operation doesn't use TUS, correct me if i am wrong @kulmann @JammingBen

[kulmann]

COPY is not using TUS, that's correct. But also, the COPY operation only triggers a server side COPY (but it might time out because we're waiting for the response).

[micbar]

@dragonchaser @aduffeck I think we need to dig into that.