Images with zero bytes are in my Nextcloud after uploading from iPhone
Expected behaviour
Nextcloud iOS uploads all new photos from my camera roll to my Nextcloud instance.
All the images have a size > 0 bytes.
Actual behaviour
Nextcloud iOS uploads all new photos from my camera roll to my Nextcloud instance.
Approximately every 5. to 10. images is uploaded with zero bytes size and therefore not usable.
This happens since approx. 1-2 month.
Please also see the communication.log exported from iOS.
Maybe this is unrelated, but I also get a lot of errors in my upload list, practically during every upload. See screenshot of this in this other ticket.
Steps to reproduce
- Take a bunch of photos with your camera or a screenshot
- Wait until uploaded
- Look into the web interface of Nextcloud, inspect the folder where the images are stored to. Sort by size ascending.
In my case, several zero-byte-sized images are not on top of the list.
Here is an example of what it looks like for me:

Reasoning or why should it be changed/implemented?
As of now, this behaviour basically trashes the core use case for me (uploading my taken photos to my Nextcloud instance).
iOS version
13.6.1
App version
3.0.5.8
Server configuration
Operating system:
Ubuntu (Linux 5.3.0-1032-aws x86_64)
Web server:
I'm using Snappy.
Database:
MySQL 5.7.31, I'm using Snappy.
PHP version:
7.3.21, I'm using Snappy.
Nextcloud version: (see Nextcloud admin page)
19.0.1, installed via Snappy
I just stumbled over this things while researching an issue. Same ios and app and main server version, I have no other information about the server as I dont have access to it, its rented as SAAS from a provider.
Please let me know if there is anything i can do to help debug or solve this issue. (unfortunately I have no ios programming skills, but interested to get started with that).
For know what happens I need a test ambient with this issue ... otherwise for me it's impossible.
@marinofaggiana I can provide you with a user on my instance if you like.
Thanks but I have look your communication.log and I don't have find an error ...
@marinofaggiana Any idea if I can provide any coding/debugging on my side to solve this issue?
Try to look the syslog in your FS server use the date on upload image for search some problem (nextcloud log / apache log)
Note. In your communication.log I don't find the upload ... re-send here the communication.log after the upload with 0 len
OK, will try. Thanks for your kind replies!
One thing I did not mention until now, but may be relevant to know:
I have all my file storage in an Amazon AWS Simple Storage Service ("S3") container as described here in the Nextcloud documentation.
I believe my provider is also using S3 for storage on the server. I will try to verify this. They are collaborating with me to solve the issue.
Also, it's possible that it's a server issue - there have been cases like that in the past, see
- https://github.com/nextcloud/server/issues/15489
- https://github.com/nextcloud/server/issues/3056
- https://help.nextcloud.com/t/files-become-zero-bytes/7214/57
Because using the client on iOS to sync my photos makes 99.9% of my usage, I cannot say for sure if it's really the iOS client or the server.
I mainly started to realize the problem, because my two desktop clients began to give me errors when syncing, as the nextcloud server seems to have a problem with syncing 0byte files.
What is strange is that today when the error occured, I actually have two images on the server with 0kb, but there must have happened a successful sync activity because on my Linux client I have the proper image in full size. But on the iOS device the images are 0kb, just as on the server. It's still unclear if it's the server breaking the images, or if it is the iOS client that first uploads them successfully, and then somehow destroy them to 0kb, and syncs the change to the server, which takes it, and from then on has problems syncing to other devices due to it's own 0kb syncing bug (https://github.com/nextcloud/server/issues/22029).
I will try to throw some photos in the folder on another client(I can test Linux and Mac) and see if this triggers the error as well.
Please keep me updated here, @henning, so will I do.
Now I do again have two zero-byte files:

The communication.log now spans the whole date range but still I don't even see the files/file names.
Is it possible that the communication log doesn't include file names at all?
Hello,
i am the Provider (more the Support) of @henning . Yes, we use our own S3-Storage.
As far as i can recall, issues like this startet only a month ago with one customer, now at 3. The rest of our nextclouds are running fine or they didnt reached to us out yet.
We also saw the Issue-Post about 0kB files and the Sync Error, but don't know why its corrupting the files to 0kB.
Last of the logs regarding this problem: ` "reqId": "XuKc7MCUOHCvaF0OIzPm", "level": 3, "time": "2020-08-25T13:13:10+00:00", "remoteAddr": "xxx", "user": "xx", "app": "PHP", "method": "GET", "url": "/index.php/apps/files/ajax/download.php?dir=%2FPhotos%2F2020%2F08&files=%5B%2220-08-25%2010-33-17%209243.jpg%22%2C%2220-08-25%2010-43-34%209251.jpg%22%5D&downloadStartSecret=xxx", "message": "fopen(): failed to open stream: HTTP request failed! HTTP/1.1 416 Requested Range Not Satisfiable\r\n at /var/www/nextcloud/lib/private/Files/ObjectStore/S3ObjectTrait.php#73", "userAgent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0", "version": "19.0.1.1" } { "reqId": "XuKc7MCUOHCvaF0OIzPm", "level": 3, "time": "2020-08-25T13:13:10+00:00", "remoteAddr": "xxx", "user": "xxx", "app": "PHP", "method": "GET", "url": "/index.php/apps/files/ajax/download.php?dir=%2FPhotos%2F2020%2F08&files=%5B%2220-08-25%2010-33-17%209243.jpg%22%2C%2220-08-25%2010-43-34%209251.jpg%22%5D&downloadStartSecret=xxx", "message": "fopen(httpseek://): failed to open stream: "OC\Files\Stream\SeekableHttpStream::stream_open" call failed at /var/www/nextcloud/lib/private/Files/Stream/SeekableHttpStream.php#67", "userAgent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0", "version": "19.0.1.1" } { "reqId": "XuKc7MCUOHCvaF0OIzPm", "level": 3, "time": "2020-08-25T13:13:10+00:00", "remoteAddr": "xxx", "user": "xx", "app": "PHP", "method": "GET", "url": "/index.php/apps/files/ajax/download.php?dir=%2FPhotos%2F2020%2F08&files=%5B%2220-08-25%2010-33-17%209243.jpg%22%2C%2220-08-25%2010-43-34%209251.jpg%22%5D&downloadStartSecret=xxxx", "message": "fclose() expects parameter 1 to be resource, bool given at /var/www/nextcloud/lib/private/legacy/OC_Files.php#196", "userAgent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0", "version": "19.0.1.1" } { "reqId": "XuKc7MCUOHCvaF0OIzPm", "level": 3, "time": "2020-08-25T13:13:11+00:00", "remoteAddr": "x.x.x.x "user": "xxx", "app": "PHP", "method": "GET", "url": "/index.php/apps/files/ajax/download.php?dir=%2FPhotos%2F2020%2F08&files=%5B%2220-08-25%2010-33-17%209243.jpg%22%2C%2220-08-25%2010-43-34%209251.jpg%22%5D&downloadStartSecret=xxx", "message": "fopen(xxx): failed to open stream: HTTP request failed! HTTP/1.1 416 Requested Range Not Satisfiable\r\n at /var/www/nextcloud/lib/private/Files/ObjectStore/S3ObjectTrait.php#73", "userAgent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0", "version": "19.0.1.1" } { "reqId": "XuKc7MCUOHCvaF0OIzPm", "level": 3, "time": "2020-08-25T13:13:11+00:00", "remoteAddr": "xxx", "user": "xxx", "app": "PHP", "method": "GET", "url": "/index.php/apps/files/ajax/download.php?dir=%2FPhotos%2F2020%2F08&files=%5B%2220-08-25%2010-33-17%209243.jpg%22%2C%2220-08-25%2010-43-34%209251.jpg%22%5D&downloadStartSecret=xxx", "message": "fopen(httpseek://): failed to open stream: "OC\Files\Stream\SeekableHttpStream::stream_open" call failed at /var/www/nextcloud/lib/private/Files/Stream/SeekableHttpStream.php#67", "userAgent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0", "version": "19.0.1.1"
`
"reqId": "XuKc7MCUOHCvaF0OIzPm", "level": 3, "time": "2020-08-25T13:13:11+00:00", "remoteAddr": "xxxx", "user": "xxx", "app": "PHP", "method": "GET", "url": "/index.php/apps/files/ajax/download.php?dir=%2FPhotos%2F2020%2F08&files=%5B%2220-08-25%2010-33-17%209243.jpg%22%2C%2220-08-25%2010-43-34%209251.jpg%22%5D&downloadStartSecret=xxx", "message": "fclose() expects parameter 1 to be resource, bool given at /var/www/nextcloud/lib/private/legacy/OC_Files.php#196", "userAgent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0", "version": "19.0.1.1" ` This one is interesting, because some of the output is different to normal errors(e.g. last bit). Will investigate more.
I also get Errors about bool Values being wrong, (latest logs of said user)
"reqId": "Tewls8ywicvtMOSre4V1", "level": 3, "time": "2020-08-26T09:18:22+00:00", "remoteAddr": "xx", "user": "xxx", "app": "PHP", "method": "REPORT", "url": "/remote.php/caldav/calendars/$USER/xxxx/", "message": "Trying to access array offset on value of type bool at /var/www/nextcloud/apps/dav/lib/CalDAV/CalDavBackend.php#1320", "userAgent": "Evolution/3.36.4", "version": "19.0.1.1"
Going to check if this is affecting the Server connection and may be responsible for corrupting the files
If you want more information, config-file etc im doing my best to provide.
hi @Corinari you must open an issue on Nextcloud server, not here.
@marinofaggiana i think he posted that to help debug this issue, and as long as it is not clear if the client or the server or both it might be a good idea to have an issue in both projects.
As I said I want to help with debugging. Could you please give me a hint which parts of the code are responsible for the uploads? Are there automated tests in the codebase that verify the proper behaviour of the actions that could be related to this issue?
Has anybody the same error with other data, like files? Or is it just about pictures on your side?
@gcommit Having iOS, until now I discovered PNG, JPEG and MP4 files to have zero bytes size from time to time.
Should be solved, try the version in TestFlight
Working successfully for several days with the TestFlight version, I now have zero byte sized images again 😢:

Yesterday, Nextcloud also updated itself to 19.0.3snap1:

Please verify in log iOS if the upload of images has 0 Len or not
Thank you. From a quick look, I found no zero lengths.
I've just increased the log level to max. and will inspect the next time a new zero byte size upload is happening.
Update:
I actually did found some zero byte sizes:
2020-09-15 08:03:38 Upload complete
https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg, result: success(0 bytes)
and
2020-09-15 08:05:14 Upload complete
https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-37 8836.jpg, result: success(0 bytes)
So yes, these are the files of my above screenshot.
ok, now verify if, for example, before:
2020-09-15 08:03:38 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg, result: success(0 bytes)
exists another upload of https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg
Yes, it seems so (again an excerpt from above attached uploaded log):
2020-09-15 08:03:18 Auto upload, no new assets found 2020-09-15 08:03:24 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg 2020-09-15 08:03:30 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg 2020-09-15 08:03:31 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg 2020-09-15 08:03:31 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-37 8836.jpg 2020-09-15 08:03:38 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg, result: success(2275118 bytes) 2020-09-15 08:03:38 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg 2020-09-15 08:03:38 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-34 8834.jpg, result: success(2440141 bytes) 2020-09-15 08:03:38 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-34 8834.jpg 2020-09-15 08:03:38 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg, result: success(0 bytes) 2020-09-15 08:03:38 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg 2020-09-15 08:03:38 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-37 8836.jpg, result: success(2278295 bytes) 2020-09-15 08:03:38 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-37 8836.jpg 2020-09-15 08:03:38 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg, result: success(0 bytes) 2020-09-15 08:03:38 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-15 07-33-36 8835.jpg 2020-09-15 08:03:38 PROCESS-AUTO-UPLOAD find 2 items 2020-09-15 08:03:38 End 20 sec. perform Fetch With Completion Handler
So to me it seems that it first uploaded successfully, then again with zero bytes size.
mmm this is the issue .... ok, thanks for now.
I also have this issue. I'm storing code projects in my nextcloud, and I found that filenames that exist multiple times in my storage, like files named "init.py" or files in .git folders, are more likely to encounter this issue. I'm also using a "S3 bucket" as storage but it's from digital ocean (called "space"). Otherwise I'm using a snap install and desktop and iOS client.
Still got this with the latest (or was it the previous-latest?) Test Flight version again:

Excerpt from the communication.log:
2020-09-21 15:00:55 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 14-29-06 9108.jpg
2020-09-21 15:00:55 PROCESS-AUTO-UPLOAD find 5 items
2020-09-21 15:00:55 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-21-13 9110.jpg
2020-09-21 15:00:56 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-51-57 9111.jpg
2020-09-21 15:00:56 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-51-57 9111.jpg
2020-09-21 15:00:56 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-51-57 9111.jpg
2020-09-21 15:00:56 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 13-02-18 9112.jpg
2020-09-21 15:00:59 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-21-13 9110.jpg, result: success(131656 bytes)
2020-09-21 15:00:59 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-21-13 9110.jpg
2020-09-21 15:00:59 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-51-57 9111.jpg, result: success(90759 bytes)
2020-09-21 15:00:59 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-51-57 9111.jpg
2020-09-21 15:00:59 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-51-57 9111.jpg, result: success(0 bytes)
2020-09-21 15:00:59 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-51-57 9111.jpg
2020-09-21 15:00:59 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-51-57 9111.jpg, result: success(0 bytes)
2020-09-21 15:00:59 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 12-51-57 9111.jpg
2020-09-21 15:01:00 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-21 13-02-18 9112.jpg, result: success(366871 bytes)
2020-09-21 15:01:00 Network completed
BTW: After sending me the communication.log (maximum verbosity) from my iPhone to my PC it seems that the line breaks are broken. There was no line break at all before a new log entry (i.e. before each "2020-09-21...").
Still happening with yesterday's Test Flight version 3.0.7 (18):

Excerpt from the communication log:
2020-09-22 12:29:43 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-23 9129.jpg
2020-09-22 12:29:49 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-23 9129.jpg
2020-09-22 12:29:49 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-23 9129.jpg
2020-09-22 12:29:49 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-27 9130.jpg
2020-09-22 12:29:55 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-27 9130.jpg, result: success(0 bytes)
2020-09-22 12:29:55 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-27 9130.jpg
2020-09-22 12:29:55 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-23 9129.jpg, result: success(0 bytes)
2020-09-22 12:29:55 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-23 9129.jpg
2020-09-22 12:29:56 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-23 9129.jpg with error code 423 and error description 423: WebDAV gesperrt: Zugriffsversuch auf eine gesperrte Ressource
2020-09-22 12:29:57 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-23 9129.jpg, result: success(0 bytes)
2020-09-22 12:29:57 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-23 9129.jpg
2020-09-22 12:29:58 End 20 sec. perform Fetch With Completion Handler
2020-09-22 12:29:59 Start handle Events For Background URLSession: com.nextcloud.session.upload.background
2020-09-22 12:29:59 Upload complete
...
2020-09-22 12:31:40 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-22 11-54-23 9129.jpg
@UweKeim I have added new information LOG in the next Build 19, if re-happen can you share the LOG, thanks
Don't know whether this is the right place to report the Test Flight version 3.0.7 (20):
It keeps uploading files:
- See 17 notifications at the Nextcloud app icon on my home screen
- Open Nextcloud app
- Go to transfers list
- Wait until the lists is being uploaded and finally empty
Now after some time (minutes? hours?) the above steps repeat (without having taken photos since then). The number is not always 17, sometimes it is e.g. 13 or something like this.
This is interesting:

The Image ("...9177.jpg") was first being zero bytes.
But after some time, it now has the correct size.
Following is the log excerpt that deals with this "...9177.jpg" image. "..." means omitted, unrelated lines.
2020-09-24 08:08:53 AutoUpload Photo Library added file 20-09-24 06-35-11 9177.jpg with Identifier FFFA3B33-599C-414F-8200-4F778B8CB5CA/L0/001
2020-09-24 08:08:53 AutoUpload Photo Library added file 20-09-24 06-35-11 9177.jpg with Identifier FFFA3B33-599C-414F-8200-4F778B8CB5CA/L0/001
2020-09-24 08:08:53 AutoUpload Photo Library added file 20-09-24 06-35-11 9177.jpg with Identifier FFFA3B33-599C-414F-8200-4F778B8CB5CA/L0/001
...
2020-09-24 08:14:35 PROCESS-AUTO-UPLOAD find 5 items
2020-09-24 08:14:35 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
2020-09-24 08:14:35 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
2020-09-24 08:14:35 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 17-00-09 9166.jpg
2020-09-24 08:14:36 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 15-16-04 9165.jpg
2020-09-24 08:14:36 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 18-14-22 9168.jpg
2020-09-24 08:14:37 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg with error code 423 and error description 423: WebDAV gesperrt: Zugriffsversuch auf eine gesperrte Ressource
2020-09-24 08:14:37 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg, result: success(0 bytes)
2020-09-24 08:14:37 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
...
2020-09-24 10:44:42 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
2020-09-24 10:50:35 Start handle Events For Background URLSession: com.nextcloud.session.upload.background
2020-09-24 10:50:35 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 11-27-25 9151.jpg, result: success(2377298 bytes)
2020-09-24 10:50:35 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 11-27-25 9151.jpg
2020-09-24 10:50:35 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg, result: success(338423 bytes)
2020-09-24 10:50:35 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
...
2020-09-24 08:08:53 AutoUpload Photo Library added file 20-09-24 06-35-11 9177.jpg with Identifier FFFA3B33-599C-414F-8200-4F778B8CB5CA/L0/001
2020-09-24 08:08:53 AutoUpload Photo Library added file 20-09-24 06-35-11 9177.jpg with Identifier FFFA3B33-599C-414F-8200-4F778B8CB5CA/L0/001
2020-09-24 08:08:53 AutoUpload Photo Library added file 20-09-24 06-35-11 9177.jpg with Identifier FFFA3B33-599C-414F-8200-4F778B8CB5CA/L0/001
...
2020-09-24 08:14:35 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
2020-09-24 08:14:35 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
2020-09-24 08:14:35 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 17-00-09 9166.jpg
2020-09-24 08:14:36 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 15-16-04 9165.jpg
2020-09-24 08:14:36 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 18-14-22 9168.jpg
2020-09-24 08:14:37 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg with error code 423 and error description 423: WebDAV gesperrt: Zugriffsversuch auf eine gesperrte Ressource
2020-09-24 08:14:37 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg, result: success(0 bytes)
2020-09-24 08:14:37 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
...
2020-09-24 10:44:42 Network start upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
2020-09-24 10:50:35 Start handle Events For Background URLSession: com.nextcloud.session.upload.background
2020-09-24 10:50:35 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 11-27-25 9151.jpg, result: success(2377298 bytes)
2020-09-24 10:50:35 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-23 11-27-25 9151.jpg
2020-09-24 10:50:35 Upload complete https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg, result: success(338423 bytes)
2020-09-24 10:50:35 Network completed upload file: https://cloud.uwe.co/remote.php/webdav/Photos/2020/09/20-09-24 06-35-11 9177.jpg
Maybe this is because of the recent behaviour, that the files get uploaded multiple times now (see above comment).
I haven't been able to find any logs for this happening either, but maybe my configuration can help narrow the search scope?
I run my own Nextcloud server on my own hardware and all file storage is backed by local disks (so S3 isn't the cause in my case).
Server: Nextcloud Server 19.0.3 Client: Nextcloud Coherence for iOS 3.0.6.8
It's also been happening on my setup for a few months now, although I didn't notice exactly when it started happening. It does seem like it only happens on auto upload, though. I've never had a problem manually uploading the failed files later, but then of course I need to keep track of them and rename them manually.
The problem seems hard to replicate. For example I tried doing 2 rounds of testing where I took 25 pictures and waited for the photos to be uploaded. But in both rounds none of the pictures were empty on upload. I had my last failed upload 13 hours ago, so I don't think anything has changed.
I have "Most Compatible" mode enabled to convert from HEIC to JPEG. Don't know if that's relevant. I also have "Live Photo" enabled. Don't know if that's relevant either since I can't remember when that feature arrived or if it at all coincides with the upload issue.
@Pectojin try subscribing to the Test Flight Version. Solved it in my case.