nextcloud
New Bug Report: Manual Uploads & Auto-Upload Hanging / Unusable in Nextcloud iOS 7.1.3
App version: 7.1.3 iOS version: 18.6.1 Device: iPhone 16 Pro Max
Describe the bug
Since updating to v7.1.3, manual uploads often get stuck in the queue (âIn Uploadâ / âWaitingâ) and automatic uploads either donât start or make the app almost unusable while uploading. The UI becomes sluggish, and sometimes there is no visible progress.
Steps to reproduce
Open Nextcloud app
Try uploading one or more files manually
Observe that the transfer stalls, remains in âwaitingâ or âin uploadâ for a long time, almost without network activity
Enable automatic upload of photos/videos and leave app idle/locked / on WiFi (or VPN, if you use that)
Observe whether uploads begin or continue (often: they donât, or take extremely long)
Expected behavior
Uploads (manual and automatic) should proceed reliably, with progress indicators. The app should remain responsive (able to abort uploads, move around menus) while these transfers happen.
Actual behavior
Uploads stuck in queue or never start
UI becomes unresponsive / sluggish
Automatic upload may show toggled on but does nothing
No way to cancel or recover without restarting the app
Environment / setup details
Nextcloud server version (if relevant)
External storage used (SMB, WebDAV, or internal)
Are you behind VPN / reverse proxy / cloudflare etc.?
Upload chunk size setting (if adjustable)
Logs: from app (if possible) + server logs around the time uploads were tried
Can confirm. My library contains over 100gb of images, and over the night it ended up uploading around 36gb before getting stuck.
I've made a small research regarding the sluggish UI. It seems like the app is constantly reading / writing the tableMetadata table, which apparently stores all the metadata for the uploaded files.
The issue is â when uploading large libraries (mine contains over 10000 files), related queries start to take a lot of time:
// NCMainNavigationController.swift, NCMainNavigationController.updateRightBarButtonItems()
/* ... = */ await self.database.getMetadatasAsync(predicate: NSPredicate(format: "status != %i", self.global.metadataStatusNormal))?.count ?? 0
The above getMetadatasAsync function call takes more than a second to complete. To make matters worse â it's called every 1.5 seconds to update the navigation bar buttons (see NCMainTabBarController.timerCheck()). I tried adding limit: 1000 here, but no luck. It still freezes for around the same time.
Obviously, this isn't the only place where tableMetadata table is used. The upload loop (NCNetworkingProcess.runMetadataPipelineAsync()) also queries (and updates) this table, changing the state to "updating" for files that are about to be uploaded:
// NCNetworkingProcess.swift, NCNetworkingProcess.runMetadataPipelineAsync()
await database.setMetadataSessionAsync(ocId: metadata.ocId,
status: global.metadataStatusUploading)
My guess over uploads that are stuck in "waiting" or "in upload" state is that their state is not being reset if something interrupts the uploading process (network reset, app restart, etc). Apparently, this process has a limit for ongoing uploads, and once this limit is exhausted with these "stuck" uploads, the uploading stops once and for all. At least, until something resets the tableMetadata.
I'm not completely sure, because the aforementioned table should reset when auto uploading is restarted. (see clearMetadatasUploadAsync() called from handleAutoUploadChange()). But I tried to restart the auto upload multiple times and had no luck restoring the upload process.
Devs, please help us!
Can confirm. My library contains over 100gb of images, and over the night it ended up uploading around 36gb before getting stuck.
Devs, please help us!
Hi @JakMobius, all database calls are async and background task and therefore do not burden the GUI, what I can notice is that if the upload is done on a local network it is so fast and efficient that just reading, exporting the images from the library and uploading them to be sent even if always in background tasks occupy CPU which will weigh down the system, clearly this does not happen with other systems where the servers are not on the LAN.
Metadata that generate an error (network change, disk full or other errors will be loaded at the end ... if the errors do not persist) the only precaution is the creation of the directories, if that does not happen or generates an error it blocks the loading for obvious reasons but I should have the logs to understand.
If the device overheats (I'll try to patch this) it interrupts the flow of data on the network, but that's another story.
Note. about the NCMainTabBarController.timerCheck we intend to change strategy maybe with the realm.objects observe, even though we've encountered some problems here too, let's see what we can come up with to limit the problems.
Thank you for your response, @marinofaggiana.
all database calls are async and background task and therefore do not burden the GUI
My bad. Indeed, these database operations are async. But the GUI still freezes once every several seconds when uploading huge libraries. That's why I thought to blame timerCheck first. Maybe there is a single tiny synchronous db access somewhere? That would be enough to cause such freezes, since the realm queue thread is overloaded with these long-executing queries.
what I can notice is that if the upload is done on a local network it is so fast and efficient that just reading, exporting the images from the library and uploading them to be sent even if always in background tasks occupy CPU which will weigh down the system
I'm not on LAN with my server currently. In fact, the app only transferred 65 kilobytes, yet it tortured the CPU for several minutes straight. I launched it with auto upload already turned on (and, apparently, hanged)
(Please note that this is my custom build with removed push capability and renamed groups).
but I should have the logs to understand.
I'd be happy to share the logs with you, but I'd rather not do it publicly, since there might be some personal data that I can overlook and leave publicly.
the only precaution is the creation of the directories
The transfers from the screenshot are expected to use Photos/2008/01 as the target directory. It does exist on the server (see the screenshot), yet it hangs "uploading", while actually not emitting any network activity.
The directory might be there after my previous upload, however. I'm not sure whether the app tries to create the folder if it already exists.
Hope this helps!
Same here, the current version (7.1.5.1) is completely unusable to transfer photos đ
In my opinion there are at least two big bugs: one related to live photo and one related to duplicated photos on the iphone (with the same name).
To make test I create a new album with only few photos and I sync this album
- Only two live photos to upload from an album, it has created the target folder but the upload stucks. The files seems to be uploaded but stays in queue.
- It seems related: if I delete the photos from my Explorer on PC, the Windows NextCloud client download it again systematically. I have to delete it from the nextcloud web UI to see it removed from my PC after the sync (a problem on the modification date ?).
- Restarting the upload process completely doesn't improve the situation.
- Restarting the upload process withtout any live photo -> no problem, all the pictures are correctly synced. (and no problem to delete the files from Explorer). However after few other tests sometimes the queue list seems to stuck ("téléversement en cours") while downloads are being made.
So the problem could be related to how NextCloud itself manage live photo. Now Nextcloud web UI only show one file for the live photo (not heic and separated mp4 anymore), that's a nice feature but it probably create a strong relation between each file which make it impossible to delete the files from Explorer with a Windows NextCloud client. And may be it impacts the transfer/upload process too ?
Another big sync bug seems related to duplicated images: long press on a photo on your iphone and select "duplicate", the duplicated file has the same as the original file which seems to crash the transfer too.
Some logs when queue stucks:
2025-09-22 13:33:35 [DEBUG] Upload file 2025-09-03 09.09 8166.heic with taskIdentifier 8
2025-09-22 13:33:35 [DEBUG] Upload file 2025-09-03 10.09 8168.heic with taskIdentifier 9
2025-09-22 13:33:35 [DEBUG] Upload file 2025-09-03 14.09 8169.png with taskIdentifier 10
2025-09-22 13:33:35 [DEBUG] Upload file 2025-09-22 12.09 8275.heic with taskIdentifier 11
2025-09-22 13:33:36 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=0BBED680-4EB8-4603-B7C1-EB8336C8B30B RESPONSE: ERROR
2025-09-22 13:33:36 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=68922FD6-8F3F-4B59-A27C-F01B72BEB643 RESPONSE: ERROR
2025-09-22 13:33:36 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=AB413804-170E-4708-98A3-C23219E899B4 RESPONSE: ERROR
2025-09-22 13:34:19 [SUCCESS] Uploaded file: https://mynextcloud.com/remote.php/dav/files/Schmurtz/Photos/2025/09/2025-09-03 14.09 8169.png, (117834 bytes)
2025-09-22 13:34:20 [SUCCESS] Uploaded file: https://mynextcloud.com/remote.php/dav/files/Schmurtz/Photos/2025/09/2025-09-03 10.09 8168.heic, (1488257 bytes)
2025-09-22 13:34:20 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=68922FD6-8F3F-4B59-A27C-F01B72BEB643 RESPONSE: ERROR
2025-09-22 13:34:20 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=A45D8C5A-94FC-4ED3-A70B-A5FC6BF429B9 RESPONSE: ERROR
2025-09-22 13:34:21 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=0BBED680-4EB8-4603-B7C1-EB8336C8B30B RESPONSE: ERROR
2025-09-22 13:34:21 [SUCCESS] Uploaded file: https://mynextcloud.com/remote.php/dav/files/Schmurtz/Photos/2025/09/2025-09-22 12.09 8275.heic, (1874822 bytes)
2025-09-22 13:34:22 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=AB413804-170E-4708-98A3-C23219E899B4 RESPONSE: ERROR
2025-09-22 13:34:22 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=68922FD6-8F3F-4B59-A27C-F01B72BEB643 RESPONSE: ERROR
2025-09-22 13:34:22 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=0BBED680-4EB8-4603-B7C1-EB8336C8B30B RESPONSE: ERROR
2025-09-22 13:34:22 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=A45D8C5A-94FC-4ED3-A70B-A5FC6BF429B9 RESPONSE: ERROR
2025-09-22 13:34:24 [SUCCESS] Uploaded file: https://mynextcloud.com/remote.php/dav/files/Schmurtz/Photos/2025/09/2025-09-03 09.09 8166.heic, (3097805 bytes)
2025-09-22 13:34:25 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=0BBED680-4EB8-4603-B7C1-EB8336C8B30B RESPONSE: ERROR
2025-09-22 13:34:25 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=A45D8C5A-94FC-4ED3-A70B-A5FC6BF429B9 RESPONSE: ERROR
2025-09-22 13:34:25 [NETWORK] 404 GET https://mynextcloud.com/index.php/core/preview?fileId=&x=1024&y=1024&a=1&mode=cover&forceIcon=0&mimeFallback=0&etag=AB413804-170E-4708-98A3-C23219E899B4 RESPONSE: ERROR
And there could be a bug with folder creation too đ”
