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
I don't know how to reproduce.
Sometimes you make a photo and it simply doesn't appear on the server.
Sometimes it shows up in 'paused uploads' but there is no indication when it blocks or pauses or just stops trying.
Expected behaviour
When I add a photo to a synchronized gallery it should always always always and I mean always upload. Always. Reliably. Always.
Not 'mostly'. Not '80% of the time'. Always.
When I take a photo and I am on wifi, I want to see that photo on the server in 5 seconds.
Perhaps it should try to scan for photos and upload them agressively. Like with real aggression. Not when the wind is fair it may probably be allright but we will not check - but rather: Can I find ANYTHING to upload and better upload twice than none at all.
Actual behaviour
It uploads photos about 80% of the time. No indication when it doesn't.
Whenever I take a photo with my phone that I really, really need it on my synchronized laptop - it does not work.
Sometimes a restart on 'paused downloads' helps but this should not be a manual action.
I'm facing the exact same issue.
My Setup:
Device: Google Pixel 7 Pro
OS: Android 16
App Version: Nextcloud 34.0.0 (from F-Droid)
For some unknown reason, a handful of pictures always get left behind and won't upload. The strange thing is: there is no error message, and the files don't even show up in the upload queue. They are simply ignored, which obviously means they don't get deleted locally either.
This is a very annoying issue, especially since the auto-upload used to work flawlessly for a long time before. Importantly, downgrading to version 33.1.1 fixes the issue, and the photo upload works completely fine there.
Standard workarounds like setting the battery usage to "Unrestricted" or clearing the app cache didn't help. Does anyone know what might be causing this, or which log entries could help troubleshoot this?
I am also dealing with this/a similar issue. And, it is recent. Pixel 8 with GrapheneOS.
Interestingly, I noticed that particularly the photos I took while abroad for a week did not get uploaded; not a single one. Before, and after, no issues. And, even more bizarrely, some folders did get uploaded, e.g. those saved from chat apps during the same time frame.
The issue does not seem to be related to being connected to my home wifi, recent pictures taken outside the house got uploaded once I got home (I have the option to upload on unmetered wifi turned on).
I have even tried changing the destination folder for camera pictures, hoping that everything would get re-uploaded, including the missing files. That did not do anything, although new pictures taken since have been uploaded to the new folder. This is unsettling - I need this thing to be bulletproof (and while we're talking about it, a lot faster - sometimes it takes forever for uploads to start).
I have not yet tried installing a previous version (33.x). Is there any way to do that without having to reconfigure the whole thing?
I'm having the same issues - sometimes photos upload, sometimes they do not, and I don't know when everything went well and when it didn't.
I'm having a lot of difficulty to setup Auto upload. I configured some folders, but then I reorganized my Nextcloud instance and pointed the target to new folders. I have the option to "Also upload existing files" set. I imagined that Nextcloud would upload all the photos again to the new folders but... no. Nothing happened, and I did not find a way to manually force it to re-sync.
I cannot seem to be able to delete the folders for custom setup either. In the end I uninstalled and reinstalled the Nextcloud app (I'm using the F-Droid release) and reinstalled it to begin fresh and setup everything manually again. For this one time it's ok, but if everytime that a configuration is changed a similar procedure has to be adopted it quickly becomes a hassle.
Happen to me today:
I took a picture in the morning, connected on wifi, it has been sent (completed in upload screen).
Later, took 2 pictures while being out of my home, came back, connected to Wifi at home.
Took another picture a while after, being still on wifi, that one has been uploaded directly (also completed in upload screen).
So far the two other pictures seems to be forgotten by nextcloud sync and will never be uploaded automatically (absent of upload screen)...
Nextcloud android app : 34.1.1 (beta channel of play store)
Nextcloud server : 34.0.3 (stable channel of docker official image)
So this does not look like the server being offline, the destination folder being inaccessible, or the server rejecting an attempted upload. The Android client can contact the server, but in the failed case the actual photo upload request never reaches it.
That seems consistent with what several people in this issue are describing: a photo can be silently forgotten before it ever reaches the upload stage.
This may help narrow the investigation toward the Android-side media detection / auto-upload queue / WorkManager trigger rather than the WebDAV upload itself.
I deliberately removed my hostname, username, LAN addresses, and filenames from the log excerpts above, but I can provide additional sanitized server-side logging if there is a particular request sequence that would be useful.
Hi @alperozturk96, I'd be happy to test the QA APK against the auto-upload issue I described above, including server-side logging. However, the latest app-qa-debug.apk artifact from PR #17401 has expired (August 19), so GitHub will no longer download it. Could you please regenerate/re-run the QA build so I can test the current fix? Thanks!
Interestingly, I noticed that particularly the photos I took while abroad for a week did not get uploaded; not a single one. Before, and after, no issues
I was away on a mountain hut with having flight mode on for most of a week, and now none of the photos from those days (except one single video from the last day of the trip, when on the way back I started to disable flight mode for longer periods) are uploaded. They do not show up at all in the list of photos when I go to upload settings in the nextcloud android client app. Just as if they don't exist for the app. They are there in the configured folder, I can transfer them to my PC via cable, the phone how has had a full day of home WiFi connectivity, still no upload at all of the photos from this week.
@codeling Thanks for the additional details. Just to clarify our testing: our reports are based on both the publicly released Nextcloud Android app and the newer QA build from PR #17401.
On the public release, we reproduced the behavior where a photo can be missed before it ever reaches the actual upload stage. On the QA build, interrupted uploads recovered much better, but we still reproduced a separate case where a newly added file shortly after reboot could sit pending until a later file event caused another scan.
Were the results you described from the publicly released app, or were you testing the QA build from PR #17401? That distinction would be really helpful for comparing your experience with ours.
Could you please try to reproduce the issue described in the first message using 35.0.0 RC2 and let us know whether the issue has been resolved?
If the issue is resolved, please share your feedback with us.
If the issue is still present, please provide the relevant logs and any additional details that might help us investigate.
To help us keep things organized and make sure we can track each issue properly, please keep this discussion focused on the issue described in the original report.
If you notice a different issue, have a separate feature request, or would like to discuss another improvement, please create a separate issue for it. This will help us investigate and track each topic individually.
I was about to try out 35.0.0 RC2 when I noticed I am already on the public 35.0.0 release.
The problem is still passively present.
I moved a file into the auto-upload folder and Nextcloud reacted correctly, which is what would happen 80% of the time.
However, absolutely nothing, nothing is done about the files already present in the local autoupload folder that should be sync'ed, that have been missed previously
I have seen repeated calls for a "force sync" button, that were all ignored. I remember the rationale being that it's better to fix the underlying root cause. I disagree with this reasoning. The root cause might have been fixed in 35.0.0 but as you can see this is not enough.
Either a proper self-heal recovery mechanism is made able to pick up these inconsistencies and missing files, and re-sync them properly, or this button should be implemented to be user-available.
I believe attempts at this self-heal implementation were """""present""""" last year when I spent a couple months trying to debug and contribute to this (still, to this day) broken feature. One year later this mechanism is still failing to the point of irrelevance.
Either there is an obvious "oops" in the mechanism that should re-check folders that can be fixed in the very next 35.0.1 release, or maybe it's too expensive to do this on a regular basis for big folders, or you don't immediately know why it's not reliably re-detecting previously unsync'ed files, in both cases we need this button now.
One theory I have is that one of your previously broken implementation over the last year may have set inconsistent or plain wrong state to some of these files (plain wrong in the sense erroneously marked them as not to be uploaded, in blatant misalignment with manifested user intent), and they are now forever skipped because we do not have an option to tell it "look at local folder, look at remote folder, see a delta? RECONCILE IT NOW."
This should be flagged as a potential critical dataloss issue, as it should have been for the last year.
People are struggling with storage, even more so since November 2025. It's a legitimate and commonplace workflow to attempt sync'ing stuff out of the device to clear up space. People WILL lose data in the confusion of Nextcloud android being unable to give the confidence that a file whose preview is in the auto-upload folder config view is even being considered for auto-upload, think it's safe to delete it/them and lose potentially critical data.
[I am aware of the "delete uploaded files" button, there is no way in hell I ever suggest anyone rely on it given the current state of how files are tracked atm.]
My entire family has been on the verge of losing pictures of our baby to this, a dozen times, in the last year, nobody trusts Nextcloud for this. Think of people doing this with medical data, payment info, life-altering one-shot-in-a-lifetime administrative stuff. This is not cosmetic, it's data corruption with a different face.
If all else fails, absolutely look at the implementation Immich uses and no not hesitate to ditch 100% of your current implementation to start over adhering to their design, because they have been achieving from day one what you have been failing to provide for years now.
Not sure if its exactly related to this bug, but with 35.0.0 installed since a few days, I today got a massive amount of "file conflict on upload" notifications, though if I click on any of them it just says "No uploads available"... I even got a login screen despite these messages of conflict. I tried deleting the cache - and thought I was stuck in a login loop; right after successfully finishing the login procedure, and seeing the files for like 1-2 seconds, I was back to the login screen. After second login now the app seems to have "settled down", I see the files now and no more login screens or conflict notifications. Keeping fingers crossed it all works now; just wanted to let you know of this a bit rough update experience ;)
Activity
Glenn-Dandy commentedon Jun 22, 2026
Hi everyone,
I'm facing the exact same issue.
My Setup:
Device: Google Pixel 7 Pro
OS: Android 16
App Version: Nextcloud 34.0.0 (from F-Droid)
For some unknown reason, a handful of pictures always get left behind and won't upload. The strange thing is: there is no error message, and the files don't even show up in the upload queue. They are simply ignored, which obviously means they don't get deleted locally either.
This is a very annoying issue, especially since the auto-upload used to work flawlessly for a long time before. Importantly, downgrading to version 33.1.1 fixes the issue, and the photo upload works completely fine there.
Standard workarounds like setting the battery usage to "Unrestricted" or clearing the app cache didn't help. Does anyone know what might be causing this, or which log entries could help troubleshoot this?
geez0x1 commentedon Jun 22, 2026
I am also dealing with this/a similar issue. And, it is recent. Pixel 8 with GrapheneOS.
Interestingly, I noticed that particularly the photos I took while abroad for a week did not get uploaded; not a single one. Before, and after, no issues. And, even more bizarrely, some folders did get uploaded, e.g. those saved from chat apps during the same time frame.
The issue does not seem to be related to being connected to my home wifi, recent pictures taken outside the house got uploaded once I got home (I have the option to upload on unmetered wifi turned on).
I have even tried changing the destination folder for camera pictures, hoping that everything would get re-uploaded, including the missing files. That did not do anything, although new pictures taken since have been uploaded to the new folder. This is unsettling - I need this thing to be bulletproof (and while we're talking about it, a lot faster - sometimes it takes forever for uploads to start).
I have not yet tried installing a previous version (33.x). Is there any way to do that without having to reconfigure the whole thing?
pmmontanari commentedon Jun 24, 2026
I'm having the same issues - sometimes photos upload, sometimes they do not, and I don't know when everything went well and when it didn't.
I'm having a lot of difficulty to setup Auto upload. I configured some folders, but then I reorganized my Nextcloud instance and pointed the target to new folders. I have the option to "Also upload existing files" set. I imagined that Nextcloud would upload all the photos again to the new folders but... no. Nothing happened, and I did not find a way to manually force it to re-sync.
I cannot seem to be able to delete the folders for custom setup either. In the end I uninstalled and reinstalled the Nextcloud app (I'm using the F-Droid release) and reinstalled it to begin fresh and setup everything manually again. For this one time it's ok, but if everytime that a configuration is changed a similar procedure has to be adopted it quickly becomes a hassle.
Android version
13
Device brand and model
Xiaomi Redmi Note 10 Pro
Stock or custom OS?
Stock
Nextcloud android app version
34.0.0
Nextcloud server version
32.0.9
Using a reverse proxy?
I don't know
Android logs
No response
Server error logs
No response
Additional information
No response
alperozturk96 commentedon Aug 4, 2026
Hey,
Thank you for the report.
Could you please also test via latest QA APK and share your feedback?
#17401
sprshp commentedon Aug 30, 2026
Hello,
Happen to me today:
I took a picture in the morning, connected on wifi, it has been sent (completed in upload screen).
Later, took 2 pictures while being out of my home, came back, connected to Wifi at home.
Took another picture a while after, being still on wifi, that one has been uploaded directly (also completed in upload screen).
So far the two other pictures seems to be forgotten by nextcloud sync and will never be uploaded automatically (absent of upload screen)...
Nextcloud android app : 34.1.1 (beta channel of play store)
Nextcloud server : 34.0.3 (stable channel of docker official image)
JDubbedN commentedon Sep 1, 2026
I can reproduce this problem as well, and I did some server-side logging during a controlled test that may help narrow down where the failure occurs.
Environment
I created a dedicated destination folder specifically for testing Android auto-upload so that the requests would be easy to isolate.
The important observation is that when auto-upload fails, the server does not appear to receive an attempted upload for the missed photo at all.
During the captured reproduction window, the Android client was definitely communicating with the server:
However, there was no corresponding WebDAV
PUTfor the photo that should have been auto-uploaded in that captured window.I also independently checked the destination folder through WebDAV. The folder was reachable and existing test photos could be queried successfully:
So this does not look like the server being offline, the destination folder being inaccessible, or the server rejecting an attempted upload. The Android client can contact the server, but in the failed case the actual photo upload request never reaches it.
That seems consistent with what several people in this issue are describing: a photo can be silently forgotten before it ever reaches the upload stage.
This may help narrow the investigation toward the Android-side media detection / auto-upload queue / WorkManager trigger rather than the WebDAV upload itself.
I deliberately removed my hostname, username, LAN addresses, and filenames from the log excerpts above, but I can provide additional sanitized server-side logging if there is a particular request sequence that would be useful.
JDubbedN commentedon Sep 1, 2026
Hi @alperozturk96, I'd be happy to test the QA APK against the auto-upload issue I described above, including server-side logging. However, the latest
app-qa-debug.apkartifact from PR #17401 has expired (August 19), so GitHub will no longer download it. Could you please regenerate/re-run the QA build so I can test the current fix? Thanks!codeling commentedon Sep 6, 2026
Exact same issue here:
I was away on a mountain hut with having flight mode on for most of a week, and now none of the photos from those days (except one single video from the last day of the trip, when on the way back I started to disable flight mode for longer periods) are uploaded. They do not show up at all in the list of photos when I go to upload settings in the nextcloud android client app. Just as if they don't exist for the app. They are there in the configured folder, I can transfer them to my PC via cable, the phone how has had a full day of home WiFi connectivity, still no upload at all of the photos from this week.
JDubbedN commentedon Sep 7, 2026
@codeling Thanks for the additional details. Just to clarify our testing: our reports are based on both the publicly released Nextcloud Android app and the newer QA build from PR #17401.
On the public release, we reproduced the behavior where a photo can be missed before it ever reaches the actual upload stage. On the QA build, interrupted uploads recovered much better, but we still reproduced a separate case where a newly added file shortly after reboot could sit pending until a later file event caused another scan.
Were the results you described from the publicly released app, or were you testing the QA build from PR #17401? That distinction would be really helpful for comparing your experience with ours.
codeling commentedon Sep 7, 2026
@JDubbedN I was using 34.1.0 from f-droid on a Fairphone 4.
alperozturk96 commentedon Sep 14, 2026
Hey,
Could you please try to reproduce the issue described in the first message using 35.0.0 RC2 and let us know whether the issue has been resolved?
To help us keep things organized and make sure we can track each issue properly, please keep this discussion focused on the issue described in the original report.
If you notice a different issue, have a separate feature request, or would like to discuss another improvement, please create a separate issue for it. This will help us investigate and track each topic individually.
Thank you for your help and feedback! 🙌
koolfy commentedon Sep 22, 2026
I was about to try out 35.0.0 RC2 when I noticed I am already on the public 35.0.0 release.
The problem is still passively present.
I moved a file into the auto-upload folder and Nextcloud reacted correctly, which is what would happen 80% of the time.
However, absolutely nothing, nothing is done about the files already present in the local autoupload folder that should be sync'ed, that have been missed previously
I have seen repeated calls for a "force sync" button, that were all ignored. I remember the rationale being that it's better to fix the underlying root cause. I disagree with this reasoning. The root cause might have been fixed in 35.0.0 but as you can see this is not enough.
Either a proper self-heal recovery mechanism is made able to pick up these inconsistencies and missing files, and re-sync them properly, or this button should be implemented to be user-available.
I believe attempts at this self-heal implementation were """""present""""" last year when I spent a couple months trying to debug and contribute to this (still, to this day) broken feature. One year later this mechanism is still failing to the point of irrelevance.
Either there is an obvious "oops" in the mechanism that should re-check folders that can be fixed in the very next 35.0.1 release, or maybe it's too expensive to do this on a regular basis for big folders, or you don't immediately know why it's not reliably re-detecting previously unsync'ed files, in both cases we need this button now.
One theory I have is that one of your previously broken implementation over the last year may have set inconsistent or plain wrong state to some of these files (plain wrong in the sense erroneously marked them as not to be uploaded, in blatant misalignment with manifested user intent), and they are now forever skipped because we do not have an option to tell it "look at local folder, look at remote folder, see a delta? RECONCILE IT NOW."
This should be flagged as a potential critical dataloss issue, as it should have been for the last year.
People are struggling with storage, even more so since November 2025. It's a legitimate and commonplace workflow to attempt sync'ing stuff out of the device to clear up space. People WILL lose data in the confusion of Nextcloud android being unable to give the confidence that a file whose preview is in the auto-upload folder config view is even being considered for auto-upload, think it's safe to delete it/them and lose potentially critical data.
[I am aware of the "delete uploaded files" button, there is no way in hell I ever suggest anyone rely on it given the current state of how files are tracked atm.]
My entire family has been on the verge of losing pictures of our baby to this, a dozen times, in the last year, nobody trusts Nextcloud for this. Think of people doing this with medical data, payment info, life-altering one-shot-in-a-lifetime administrative stuff. This is not cosmetic, it's data corruption with a different face.
If all else fails, absolutely look at the implementation Immich uses and no not hesitate to ditch 100% of your current implementation to start over adhering to their design, because they have been achieving from day one what you have been failing to provide for years now.
codeling commentedon Sep 27, 2026
Not sure if its exactly related to this bug, but with 35.0.0 installed since a few days, I today got a massive amount of "file conflict on upload" notifications, though if I click on any of them it just says "No uploads available"... I even got a login screen despite these messages of conflict. I tried deleting the cache - and thought I was stuck in a login loop; right after successfully finishing the login procedure, and seeing the files for like 1-2 seconds, I was back to the login screen. After second login now the app seems to have "settled down", I see the files now and no more login screens or conflict notifications. Keeping fingers crossed it all works now; just wanted to let you know of this a bit rough update experience ;)