Nextcloud Fails To Upload Files

[apiziali]

⚠️ Before posting ⚠️

• This is a bug, not a question or an enhancement.
• I've searched for similar issues and didn't find a duplicate.
• I've written a clear and descriptive title for this issue, not just "Bug" or "Crash".
• I agree to follow Nextcloud's Code of Conduct.

Steps to reproduce

1. Open the Nextcloud app.
2. Navigate to Documents.
3. Tap the [+] button.
4. Tap “Upload files.”
5. Navigate to Android Downloads folder.
6. Tap the radio button next to one file (ex. 202609-PG.pdf).
7. Tap the [Upload] button.

Expected behaviour

The app should re-display the Documents folder with the selected file (ex. 2020609-PG.pdf) added to the folder.

Actual behaviour

The app re-displays the Documents folder with the same contents.

Android version

16

Device brand and model

Samsung Galaxy S25 Ultra

Stock or custom OS?

Stock

Nextcloud android app version

35.0.0

Nextcloud server version

32.0.2.2

Using a reverse proxy?

No

Android logs

There is no log file in /storage/emulated/0/data.

Server error logs

I have no access to the server log because I am not an administrator.

Additional information

File upload was working about a month ago (August 20, 2026), but now (September 23, 2026) it no longer is.

[PhilLab]

@apiziali any chance you can share device logs with us, e.g. from adb. As per my testing, upload is not universally broken, so it might a specific situation on your device or server.

[brrooke]

I am experiencing the same issue.

Android version

17

Device brand and model

Google Pixel 8

Stock or custom OS?

Custom ROM

Nextcloud android app version

35.0.0

Nextcloud server version

34.0.3

Some additional notes:

• Nextcloud App is F-Droid version.
• Upload file via web browser (same mobile phone) works.
• Creation of empty file via Nextcloud App works.
• Upload file via Nextcloud App does not work.
• Share file from other App to Nextcloud App does not work.
• There is no visual error display. The upload dialog just returns and NOOP.
• This doesn't seem to be an Android permission issue, since I can already select files, and it works on web. Nonetheless I temporarily provided all files access on Android, but not of success.
• I am quite sure, in previous versions it worked on my phone, but cannot remind exact version, since not regularly using it at that time.

@apiziali any chance you can share device logs with us, e.g. from adb.

I yet need to dot this as well. Unfortunately, there is no easy way in F-Droid to revert to v34 or v33 to compare results.

EDIT

Re-installed Nextcloud 34.1.1 works again (with server 34.0.3). Maybe this is of help for bisecting.

[apiziali]

In the thread of an related issue (“Nextcloud Fails To Upload Files (Issue #17701)”, Philipp Hasper wrote: “The server from your log is now slightly newer than the initial bug report (32.0.2.2, Hub 11). Can you please retest, whether it is still an issue?”

First, let me upload the redacted Android log here … done. No worries about my email address in the log.

Second, to answer your question, yes, this is still an issue with the current server. The sample file I am trying to upload is /storage/emulated/0/Download/202609-PG.pdf.

logcatOutput.txt

[Maxren2]

I hit the same symptom on 35.0.0 (upload stays at 0 %, no error; 34.1.1 works) and found a server-side cause that 35.0.0 now exposes. Posting in case it helps others here.

Cause: since 35.0.0, UploadFileOperation passes the server capability files.chunked_upload.max_size straight to ChunkedFileUploadRemoteOperation.chunkSize() (android-library 2.26.0). Any positive value is used as-is, both as the chunking threshold and as the chunk size. 34.1.1 used fixed 10 MB / 40 MB chunks, so a bad server value had no effect before.

On my server, the system config value was 10, i.e. 10 bytes:

$ occ config:system:get files.chunked_upload.max_size
10

So every file (even a small PDF) was uploaded as 10-byte chunks. The reverse-proxy access log showed an endless stream of PUT /remote.php/dav/uploads/<user>/<md5>/000001 … 082542 → 201 (one session sent 82,771 chunks in ~8 h, i.e. ~800 KB), and the final MOVE …/.file never happened, so the UI stayed at 0 %.

Fix / check for affected users:

occ config:system:get files.chunked_upload.max_size
occ config:system:set files.chunked_upload.max_size --value 104857600 --type integer

Then force-close and reopen the app (so it refetches capabilities) and retry. After this, uploads went through as a single PUT → 201 immediately.

Note: since Nextcloud 31 the capability comes from the system key files.chunked_upload.max_size (ChunkedUploadConfig::getMaxChunkSize()); the old app key occ config:app:get files max_chunk_size is no longer used, so checking that one can be misleading.

Suggestion for the app: clamp the server value to a sane minimum (e.g. ignore values below MIN_CHUNK_SIZE and fall back to the 10 MB / 40 MB defaults), so a misconfigured server can't turn uploads into an endless 10-byte chunk loop.

Side note: the same log also showed two upload workers writing into the same upload folder concurrently (204 overwrites, skipped chunk ids), which looks like #17671.

[alperozturk96]

I hit the same symptom on 35.0.0 (upload stays at 0 %, no error; 34.1.1 works) and found a server-side cause that 35.0.0 now exposes. Posting in case it helps others here.

Cause: since 35.0.0, UploadFileOperation passes the server capability files.chunked_upload.max_size straight to ChunkedFileUploadRemoteOperation.chunkSize() (android-library 2.26.0). Any positive value is used as-is, both as the chunking threshold and as the chunk size. 34.1.1 used fixed 10 MB / 40 MB chunks, so a bad server value had no effect before.

On my server, the system config value was 10, i.e. 10 bytes:

$ occ config:system:get files.chunked_upload.max_size
10

So every file (even a small PDF) was uploaded as 10-byte chunks. The reverse-proxy access log showed an endless stream of PUT /remote.php/dav/uploads/<user>/<md5>/000001 … 082542 → 201 (one session sent 82,771 chunks in ~8 h, i.e. ~800 KB), and the final MOVE …/.file never happened, so the UI stayed at 0 %.

Fix / check for affected users:

occ config:system:get files.chunked_upload.max_size
occ config:system:set files.chunked_upload.max_size --value 104857600 --type integer

Then force-close and reopen the app (so it refetches capabilities) and retry. After this, uploads went through as a single PUT → 201 immediately.

Note: since Nextcloud 31 the capability comes from the system key files.chunked_upload.max_size (ChunkedUploadConfig::getMaxChunkSize()); the old app key occ config:app:get files max_chunk_size is no longer used, so checking that one can be misleading.

Suggestion for the app: clamp the server value to a sane minimum (e.g. ignore values below MIN_CHUNK_SIZE and fall back to the 10 MB / 40 MB defaults), so a misconfigured server can't turn uploads into an endless 10-byte chunk loop.

Side note: the same log also showed two upload workers writing into the same upload folder concurrently (204 overwrites, skipped chunk ids), which looks like #17671.

Hello,

Thank you for the report. Could you please try with this PR: #17741

[Maxren2]

Tested the QA build from #17741 (Nextcloud-android/17741) against my server with files.chunked_upload.max_size deliberately set back to 10:

• Same ~700 MB file: QA build uploaded it in 69 chunks (≈10 MB each, i.e. clamped to MIN_CHUNK_SIZE) and finished with MOVE …/.file → 201 in ~17 s.
• At the same time, 35.0.0 with the same server setting went back into the 10-byte chunk loop (hundreds of PUT …/000NNN → 201, no MOVE).
• For reference, 35.0.0 with a correct server value (100 MiB) uploaded the same file in 7 chunks.

So the fix works for me. Thanks for the quick turnaround!

[apiziali]

@alperozturk96 , thank you for your prompt and clear diagnosis, suggested workaround, and suggested app fix. I passed along the server configuration change to my admins.