You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
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.
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.
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:
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 %.
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.
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:
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 %.
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
@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.
This fix does not work for me. Our Nextcloud server admins claim they set files.chunked_upload.max_size to 104857600, type integer. Yet, using app version 35.0.1 and server version 35.0.1, the "Steps To Reproduce" in the initial post still fail to upload a file.
This fix does not work for me. Our Nextcloud server admins claim they set files.chunked_upload.max_size to 104857600, type integer. Yet, using app version 35.0.1 and server version 35.0.1, the "Steps To Reproduce" in the initial post still fail to upload a file.
I installed app-qa-debug.apk on my Samsung Galaxy S25 Ultra phone, started the app, logged into https://ma.sdf.org/nc, and uploaded three files successfully. Hence, this candidate appears to resolve the issue. If you still need any logs, let me know and precisely how to enable them, create them, and transfer them to you.
Activity
PhilLab commentedon Sep 23, 2026
@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 commentedon Sep 24, 2026
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:
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 commentedon Sep 25, 2026
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 commentedon Sep 30, 2026
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,
UploadFileOperationpasses the server capabilityfiles.chunked_upload.max_sizestraight toChunkedFileUploadRemoteOperation.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: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 finalMOVE …/.filenever happened, so the UI stayed at 0 %.Fix / check for affected users:
Then force-close and reopen the app (so it refetches capabilities) and retry. After this, uploads went through as a single
PUT→201immediately.Note: since Nextcloud 31 the capability comes from the system key
files.chunked_upload.max_size(ChunkedUploadConfig::getMaxChunkSize()); the old app keyocc config:app:get files max_chunk_sizeis 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_SIZEand 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 (
204overwrites, skipped chunk ids), which looks like #17671.alperozturk96 commentedon Sep 30, 2026
Hello,
Thank you for the report. Could you please try with this PR: #17741
Maxren2 commentedon Sep 30, 2026
Tested the QA build from #17741 (
Nextcloud-android/17741) against my server withfiles.chunked_upload.max_sizedeliberately set back to10:MIN_CHUNK_SIZE) and finished withMOVE …/.file → 201in ~17 s.PUT …/000NNN → 201, noMOVE).So the fix works for me. Thanks for the quick turnaround!
apiziali commentedon Sep 30, 2026
@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.
apiziali commentedon Oct 7, 2026
This fix does not work for me. Our Nextcloud server admins claim they set files.chunked_upload.max_size to 104857600, type integer. Yet, using app version 35.0.1 and server version 35.0.1, the "Steps To Reproduce" in the initial post still fail to upload a file.
alperozturk96 commentedon Oct 7, 2026
Hello,
I created a PR for the logs: #17563
Once the QA APK is generated could you please try to upload and then send the logs?
UploadFileOperation,CHUNK_SIZE,ChunkedFileUploadRemoteOperation,UploadRemoteOperation-> I need only these.apiziali commentedon Oct 7, 2026
Let me know when the QA APK is available—and where—and I will re-test with logging enabled.
alperozturk96 commentedon Oct 7, 2026
QA APK is ready: #17563 (comment)
You can test on failed instance and from Settings -> Logs you can filter the logs then export and share.
apiziali commentedon Oct 7, 2026
I installed app-qa-debug.apk on my Samsung Galaxy S25 Ultra phone, started the app, logged into https://ma.sdf.org/nc, and uploaded three files successfully. Hence, this candidate appears to resolve the issue. If you still need any logs, let me know and precisely how to enable them, create them, and transfer them to you.