App reports "Server not available" on new install (java.lang.ClassCastException in WebdavEntry.kt for EXTENDED_PROPERTY_METADATA_PHOTOS_SIZE`)

[Ziris85]

⚠️ 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

Scan QR code to attach client to nextcloud server
Files section appears

Expected behaviour

Files list should be populated with all files present.

Actual behaviour

No files are listed, and there's a message at the top stating "Server not available"

Android version

13

Device brand and model

Samsung Galazy Z Flip3

Stock or custom OS?

Stock

Nextcloud android app version

3.27.0

Nextcloud server version

28.0.1.1

Using a reverse proxy?

Yes

Android logs

01-16 11:40:40.551 18923 21422 D RefreshFolderOperation: Checking changes in me@nextcloud.lan/
01-16 11:40:40.552 18923 21422 D OwnCloudClient #1: REQUEST PROPFIND /remote.php/dav/files/me/
01-16 11:40:40.665 18923 21422 I RefreshFolderOperation: Checked me@nextcloud.lan/ : changed
01-16 11:40:40.666 18923 21422 D OwnCloudClient #1: REQUEST PROPFIND /remote.php/dav/files/me/
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: Synchronized /: Unexpected exception
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: java.lang.ClassCastException: org.apache.harmony.xml.dom.ElementImpl cannot be cast to java.util.ArrayList
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: 	at com.owncloud.android.lib.common.network.WebdavEntry.<init>(WebdavEntry.kt:453)
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: 	at com.owncloud.android.lib.resources.files.ReadFolderRemoteOperation.readData(ReadFolderRemoteOperation.java:151)
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: 	at com.owncloud.android.lib.resources.files.ReadFolderRemoteOperation.run(ReadFolderRemoteOperation.java:88)
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: 	at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:205)
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: 	at com.owncloud.android.operations.RefreshFolderOperation.fetchAndSyncRemoteFolder(RefreshFolderOperation.java:405)
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: 	at com.owncloud.android.operations.RefreshFolderOperation.run(RefreshFolderOperation.java:239)
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: 	at com.owncloud.android.lib.common.operations.RemoteOperation.run(RemoteOperation.java:399)
01-16 11:40:41.410 18923 21422 E ReadFolderRemoteOperation: 	at java.lang.Thread.run(Thread.java:1012)

Server error logs

None

Additional information

I was a little nervous about opening this report since there are now a couple that are sort-of similar, but mine felt unique enough that it was worthy of a separate report. I actually encountered this in the process of migrating from one nextcloud installation to another, so my client is currently connected to both destinations - the old/current one works fine, and the new one does not. The old install is using the snap install and is on v27.1.4, and the new install is in my microk8s cluster. There are of course some environmental differences as a result - nginx ingress (reverse proxy), different hostname...I'm also using an SSL certificate signed by my own custom CA. There are no errors in the ingress logs nor in the Nextcloud logs.

Some of the similar errors seem to suggest that downgrading the client fixes the issue, which I haven't tried quite yet. The web browser access works fine, as do both the Linux and Windows Nextcloud desktop clients. This seems particularly isolated to the Android app (I don't have an iphone around, so can't test with that). I also have an android tablet on the same version with the same problem, so it doesn't appear to be related to the device.

Let me know if I can provide any more details! Appreciate your help!

[joshtrichards]

Scan QR code to attach client to nextcloud server

Is the problem limited to when you use the QR code? (i.e. does it work if you don't use QR setup mode?)

[Ziris85]

Thanks for the reply! I had actually started with logging in with my credentials when I noticed the issue, but quickly switched to using the app pw/QR code since I figured that's probably what I should've been doing in the first place. Same issue both ways.

[rybat1]

Hello, I am seeing the same issue also. It started for me on 12/13/2023 and I haven't had time to investigate.
I notice the message when I go to my photos folder and at the same time thumbnails stopped getting created. My files do still upload and everything works fine on the desktop version

I am also getting a new error today saying error creating conflict dialog when I was getting messages about what to do with duplicate files.

I installed nextcloud over the summer with no issues.

I just upgraded to Server Version 28.0.1 to see if that helps
Android Version is 3.27

[Ziris85]

I spent some time poking around the edges of this, trying to get an idea of what specifically might not be working. To the best of my ability, it seems that the "All files" part of the Nextcloud app is the only thing that isn't working. Other parts, like Favorites and Media, populate successfully with content. Interestingly, the file I made a "favorite" for testing caused it and its parent directory to appear in the "All files" list, but it is the only entry currently.

Also of note is that other connected apps that I use - Notes, Cookbook, News - are all unaffected as well. They auth to my account through the main Nextcloud app, and show my files/content normally.

I then tried uploading a new file from the web UI, and that new file ALSO appears just fine in my nextcloud app, though the "Server not available" message persists. If it's of any help, I used the Windows desktop client to perform the migration of my files - I just attached the client to my new instance (it was already logged in any syncing my old instance), copied the files over to the new directory, and let the client push them to the server. I did have to iron out some nginx configs in my ingress along the way since the upload kept getting interrupted due to various timeouts and buffer limits, but eventually got it flowing smoothly.

With that in mind I tried doing a full rescan of the user:

su - www-data -s /bin/bash -c "/var/www/html/occ files:scan --all"

The scan finished without error:

+---------+-------+-----+---------+---------+--------+--------------+
| Folders | Files | New | Updated | Removed | Errors | Elapsed time |
+---------+-------+-----+---------+---------+--------+--------------+
| 1793    | 15952 | 0   | 23      | 0       | 0      | 00:16:50     |
+---------+-------+-----+---------+---------+--------+--------------+

...though there was no change to the android app.

[Ziris85]

Tried a couple more file operations that didn't change anything either:

# su - www-data -s /bin/bash -c "/var/www/html/occ files:scan-app-data"
Scanning AppData for files

+---------+-------+--------------+
| Folders | Files | Elapsed time |
+---------+-------+--------------+
| 1069    | 268   | 00:01:38     |
+---------+-------+--------------+

# su - www-data -s /bin/bash -c "/var/www/html/occ files:repair-tree"
Found 0 file entries with an invalid path

[joshtrichards]

While I can't reproduce the behavior currently against any of my NC28 instances, this appears related to the changes made to accommodate both the older and the newer metadata API concurrently in nextcloud/android-library#1242.

Cc: @alperozturk96

[Ziris85]

Any other data or testing I can do to help confirm if that might be the case? I'm still relying on my current nextcloud server for now as a result of this, so I can monkey around with the new one for debugging purposes.

[Ziris85]

(editing message since I was mixing up my old and new NC servers, so testing was flawed)

OK, so in a fascinating twist, I think I've identified the source of the problem - one very specific jpg file. I started by emptying my nextcloud dir entirely, which I found got rid of the "Server not available" message. I then proceeded to copy things back into it in small chunks, verifying that it continued working after each copy, eventually happening upon this one file. I copy the file into nextcloud, it breaks - I remove it, it works fine again. This same image also works fine in my old nextcloud v27 server.

This one file isn't particularly interesting as far as I can tell - it's a jpg from an old phone about 2 years ago, about 1.3MB in size...it opens fine in image viewers (windows photos, gwenview, okular) and editors (gimp) without warnings. Perhaps the only thing that is notable is that, when opening in gimp, it informs me that it contains Exif orientation metadata, and asks me if I want to rotate the image. I've tried exporting the image both rotated and unrotated (saving the Exif data each time), and in both cases the saved image DOES break Nextcloud. I've also tried saving the image without exif data entirely, and the exported image still breaks Nextcloud, so the Exif data appears to be out as a culprit. At this point, the only "properties" this image has is its name and its dimensions.

[Ziris85]

A little more testing, and I AM finally able to manipulate it in a way that doesn't break Nextcloud. Interestingly, exporting the image in Gimp and stripping out all possible metadata (unchecking all the boxes) doesn't produce a usable image. But if I use Windows to Remove Properties and Personal Information, and then choose "Create a copy with all possible properties removed", that produces a version of the image that doesn't break Nextcloud. In fact, this is the only way I've found so far to produce a working copy of the image.

[mquin2003]

Thank you @Ziris85 as I've been experiencing this issue as well. On the android device, I'm running NextCloud version 3.27.0, and also experience the same issue on 3.29.0 Alpha1. I'm also running Nextcloud 28.0.1.1. The android device is a Samsung Galaxy Z Fold 5 running Android 14, stock and using a reverse proxy. I experience identical behavior and found an identical log output in Logcat:

Synchronized /Phone/DemoDocs/: Unexpected exception
                                                                                                    java.lang.ClassCastException: org.apache.harmony.xml.dom.ElementImpl cannot be cast to java.util.ArrayList
                                                                                                    	at com.owncloud.android.lib.common.network.WebdavEntry.<init>(WebdavEntry.kt:453)
                                                                                                    	at com.owncloud.android.lib.resources.files.ReadFolderRemoteOperation.readData(ReadFolderRemoteOperation.java:151)
                                                                                                    	at com.owncloud.android.lib.resources.files.ReadFolderRemoteOperation.run(ReadFolderRemoteOperation.java:88)
                                                                                                    	at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:205)
                                                                                                    	at com.owncloud.android.operations.RefreshFolderOperation.fetchAndSyncRemoteFolder(RefreshFolderOperation.java:410)
                                                                                                    	at com.owncloud.android.operations.RefreshFolderOperation.run(RefreshFolderOperation.java:244)
                                                                                                    	at com.owncloud.android.lib.common.operations.RemoteOperation.run(RemoteOperation.java:399)
                                                                                                    	at java.lang.Thread.run(Thread.java:1012)

Looking at com.owncloud.android.lib.common.network.WebdavEntry.<init>(WebdavEntry.kt:453) at the specified line brings us here:

// NC metadata gps property <nc:file-metadata-gps>
            prop = propSet[EXTENDED_PROPERTY_METADATA_PHOTOS_GPS, ncNamespace]
            geoLocation =
                if (prop == null) {
                    prop = propSet[EXTENDED_PROPERTY_METADATA_GPS, ncNamespace]
                    gson.fromDavProperty<GeoLocation>(prop)
                } else {
                    val xmlData = prop.value as ArrayList<*> // <- Line 453 from the Logcat in WebdavEntry.kt
                    var latitude = 0.0
                    var longitude = 0.0
                    xmlData.forEach {
                        val element = it as Element
                        if (element.tagName == "latitude") {
                            latitude = element.firstChild.textContent.toDouble()
                        } else if (element.tagName == "longitude") {
                            longitude = element.firstChild.textContent.toDouble()
                        }
                    }

                    GeoLocation(latitude, longitude)
                }

As @Ziris85 has suggested, the issue seems to be related to how the metadata is being handled by the app, in particular, the GPS metadata. I'm searching for the offending photo(s) as I'm interested in what differs in their metadata from the rest that causes this issue.

If there's any other testing you'd like me to do, I'd be happy to do so. I hope this helps! :)

[mquin2003]

After some experimenting, I discovered that the unique property of the offending photo was that it was missing some, but not all of its GPS location tags (The photo contains the GPS Longitude Reference and GPS Latitude Reference values North and West respectively, while missing the actual GPS Longitude and Latitude coordinate values).

A photo stripped of all of its GPS tags, or the photo being given the missing GPS tags does not exhibit this issue when uploaded to NextCloud.

To test this, I uploaded three images. One was the original photo with partially missing GPS exif values, another was the same photo stripped of all of its GPS values, and the third was also the same photo, but was given some arbitrary value for its GPS Longitude and Latitude tags.

The first and third photos worked just fine, with either photo having none or all of their GPS tags not causing any issues when viewing folders in the nextcloud app in which those photos were present. The second photo, missing its GPS Latitude and Longitude tags while still retaining the reference values, did cause the issue once again, regardless of which directory the photo was placed in.

Here's some data from ExifTool:

The original, 'problematic' photo:

GPS Version ID                  : 2.2.0.0
GPS Latitude Ref                : North
GPS Longitude Ref               : West
GPS Altitude Ref                : Below Sea Level
GPS Altitude                    : 1.6 m
GPS Time Stamp                  : 17:24:47
GPS Img Direction Ref           : Magnetic North
GPS Img Direction               : 283
GPS Date Stamp                  : 2023:10:06

The 'corrected' photo given some arbitrary values for its GPS coordinate tags:

GPS Version ID                  : 2.2.0.0
GPS Latitude Ref                : North
GPS Latitude                    : 0 deg 0' 0.00"
GPS Longitude Ref               : West
GPS Longitude                   : 0 deg 0' 0.00"
GPS Altitude Ref                : Below Sea Level
GPS Altitude                    : 1.6 m
GPS Time Stamp                  : 17:24:47
GPS Img Direction Ref           : Magnetic North
GPS Img Direction               : 283
GPS Date Stamp                  : 2023:10:06

I wrote a quick fix for it within the WebdavEntry.kt file to try and not stumble over odd image files like that, and can confirm that I no longer encounter this issue.

[Ziris85]

@mquin2003 , thanks for the reply! I tried your approach with exiftool, analyzing the problematic picture (I've actually stumbled upon a few more since opening this). I found 2 GPS-related tags on it:

 exiftool 20210922_135325.jpg 
ExifTool Version Number         : 12.70
...
GPS Altitude Ref                : Above Sea Level
GPS Altitude                    : 0 m Above Sea Level
...

I'm not too familiar with exiftool, but the help docs said that this arg would strip all GPS-related tags, which it appears to have done:

 exiftool -gps:all= 20210922_135325.jpg 
Warning: [minor] Entries in IFD0 were out of sequence. Fixed. - 20210922_135325.jpg
    1 image files updated

 exiftool 20210922_135325.jpg|grep -c "^GPS"
0

After the updated image synced, I tried again, but the "Server not available" message persists. Maybe there's more to it that you did? I tried using exiftool to delete all tags from the broken version to align with the working version, and I've gotten it down to only these differences (excluding file size, name, and access times):

  Padding                         : (Binary data 268 bytes, use -b option to extract)           |  ---------------------------------------------------------------------------------------------
  Thumbnail Image                 : (Binary data 10150 bytes, use -b option to extract)         |  Thumbnail Image                 : (Binary data 9694 bytes, use -b option to extract)         
  Thumbnail Length                : 10150                                                       |  Thumbnail Length                : 9694                                                       
  Thumbnail Offset                : 6936                                                        |  Thumbnail Offset                : 6370                                                       

~/working                                                                     41,83          All ~/notworking                                                                 41,41          All

Unless there's more to interacting with exif tags that I'm missing, and unless the issue isn't with one of these readonly (or so exiftool tells me) tags, then something else must be amiss with my specific images.

[mquin2003]

Hi @Ziris85! Do you mind uploading the original image so that I can test it on my setup? I'd be interested in seeing how this particular image's tags may also differ from my problematic photo, as well as the 'fixed' ones.

I'd also like to make sure that the patch that I wrote in the above PR handles your problematic photo fine as well. This issue most likely seems to be related to the GPS tags in particular, as once I implemented the fix on my local version of the Nextcloud app with the fix, I no longer have the "Server not available" message and the directory syncs properly.

[Ziris85]

Sure! As an extremely interesting twist, I've found another way to "fix" a broken image. If I rename the image file on local storage to, say, image.jpg_orig, copy the file into nextcloud, and then remove the _orig from the file name (from the nextcloud storage), Nextcloud will happily read and interact with the file. I can even move the file around within Nextcloud to other directories and it still works. Of course, if I move that same file out of nextcloud and back in, it breaks again 😆

Anyway, attached is one of the problematic images :)

[schnello]

Thanks. I was now able to fix the issue with this information. I deleted now all Geo Tags from my photos and the message "Server not available" disappears

[akusokuzan]

I stumbled across this issue as well. My photos didn't even show up in the app when they had altitude 0. After removing that now the pictures show up and no more server not available message. So annoying took me hours to figure it out. Came here to post a bug glad to see someone else already did. Hopefully fixed soon.

[Lennyz1988]

Well I also have the issues of "Server not available" and only showing 43 files in a folder of 1000 files. The files are all pictures and movies. I deleted all the GPS tags but the problem still persists.

Could it be related to the thumbnails showing partially in "Media"? I also did ran exiftool -validate -warning -error -a "$jpg_file" to show if the jpg files have more errors. Most om them do. I am not sure if this could be the issue.

20220515_114622.jpg:
Validate : 11 Warnings (6 minor)
Warning : Non-standard format (rational64u) for ExifIFD 0x9201 ShutterSpeedValue
Warning : [minor] Unknown APP5 segment
Warning : [minor] Unknown APP4 segment
Warning : ExifIFD tag 0x9010 OffsetTime requires ExifVersion 0231 or higher
Warning : ExifIFD tag 0x9011 OffsetTimeOriginal requires ExifVersion 0231 or higher
Warning : Missing required JPEG ExifIFD tag 0x9101 ComponentsConfiguration
Warning : Missing required JPEG ExifIFD tag 0xa000 FlashpixVersion
Warning : [minor] IFD0 tag 0x0100 ImageWidth is not allowed in JPEG
Warning : [minor] IFD0 tag 0x0101 ImageHeight is not allowed in JPEG
Warning : [minor] IFD1 tag 0x0100 ImageWidth is not allowed in JPEG
Warning : [minor] IFD1 tag 0x0101 ImageHeight is not allowed in JPEG

[joshtrichards]

In hindsight, this seems to be the same as #12005.

[daukus]

Nextcloud android v3.26.x is working as it should, v3.27 and v3.28 have same error with "server unavailable" when navigating certain folders.