PROPFIND Reply is not XML Formatted

I have an open issue about the NC Client 2.5.1 crashing on account setup so after some research, it looked like I could try the OwnCloud client. That client connected right up to NC14 with no issues and started my long upload process. Then today, I get a power blip that resets my Raspberry Pi. Everything starts back up but partway through the Owncloud scan for changes, I keep getting errors that say “A HTTP transmission error happened. {some filename} PROPFIND reply was not XML formatted”. I can access that file location through the browser and it’s an empty folder. I can’t really tell if the client has suspended or is continuing to run the scan.

A Google search has failed to return any good suggestions for resolution. Has anyone seen this issue or have a suggestion to try? Thanks!

I signed up only to reply to this post, because I have the same exact problem and other searches can’t help with it.
The only difference is that I’m using the Nextcloud client: when I start the sync with a new device, I have to do it bit by bit, selecting just few folders a time.
In fact, if I select all my folders in one hit, I get this “propfind reply is not xml formatted” error.

Feel free to ask me more info, I’ll try to gather them.

1 Like

I couldn’t even get the NC client to startup (another ticket still open), but was seeing the same thing. It would run for a bit then stop with the PROPFIND error. I finally worked around the problem by installing OC instead of NC and using the OC client. Not the choice I wanted as it appears NC is superior and easier to setup, but with no client working, it was useless. I’d like to try it again when I can get the issued sorted out.

I have the same problem. Trying to sync all at once end in “PROPFIND reply is not XML formatted!” error.
But when selecting just a few folder… sync again… select more folders… sync again… works.

Im using Nextcloud on the Server
and Client version 2.5.1.

I have the same issue on both NC 14 and 15. Client version 2.5.1. Downgrading to client version 2.5.0 meant that it’d just crash each time I’d grant it access – idk if this is worth mentioning but on both versions the client seems to not detect a large number of files being uploaded to the server. I will try downgrading further still to find a functional NC client, or move to the OC client if that works.

I’m also using a Pi.

Edit: Using the OC client gives the same error. Also v2.5.1.

Another edit: I’ve opened this issue on Github: #13157

I’m also seeing this issue. The 2.3.3 version of the nextcloud and owncloud clients both do not exhibit the issue at all, so it seems to have been introduced in the jump to 2.5.

For anyone looking for a temporary workaround, reverting to the 2.3.3 version of the nextcloud client seems to work fine here with Nextcloud 14.


If you have problem with downgrade v2.5.1 on Ubuntu 18.04, check this topic:

Same issue here with client 2.5.1
Downgrading to client 2.4.3 solve the issue.

Anyone knows whether/when a fix is coming?


Probably a dumb question but how do I downgrade the nextcloud-client on ubuntu?
apt-cache policy nextcloud-client and apt-cache showpkg nextcloud-client only show the one version, 2.5.1
The nextcloud downloads page only has the appimage for 2.5.1 and the releases on github only go back to 2.5.0
I must be missing something.

Edit: I found an appimage of owncloud client which works for me, owncloud 2.4.3 did not launch so had to go with 2.3.3:

Edit: I reinstalled the client and the error when away for a while but it came back after 20% was synced…

I just reinstalled my kubuntu (downgraded from 18.10 to 18.04.2) and now i have exactly the same problem. Ive been on 2.5.1 from the day it came out without any problems.
Any fixes or news about this?

Hello all,
In my case, it was a server problem.
I have solved this problem “PROPFIND Reply is not XML Formatted” by replacing NextcloudPi by a clean install of Raspbian and Nextcloud. Now, It works like a charm.

2.5.1 is not usable for me, I’ve been running into this syncing issue (as well as many others).

I found that 2.3.3 works, but it took a while to find a working source of 2.3.3.

Here are the upgrade instructions for building 2.3.3 on arch based distributions:
Use the nextcloud-client-git package as a base, and use the git history to look through the history for the latest 2.3.3 package which is this one:

Download the files (plain) to a new directory, then build and install the package by issuing (downloading will take a long time):

sudo pacman -U <name of package>

Still same problem. Just reinstalled my pc

To me it looks like the server and the client are talking past each other:

{“reqId”:“3DZaZNOAcACJopRSiVCE”,“level”:0,“time”:“2019-06-11T14:43:32+00:00”,“remoteAddr”:“2003:d3:c71b:1300:210:c6ff:fee2:abd1”,“user”:"–",“app”:“webdav”,“method”:“PROPFIND”,“url”:"/remote.php/dav/principals/users/xxxx/",“message”:{“Exception”:“Sabre\DAV\Exception\NotAuthenticated”,“Message”:"No public access to this resource., No ‘Authorization: Basic’ header found. Either the client didn’t send one, or the server is misconfigured, No ‘Authorization: Bearer’ header found. Either the client didn’t send one, or the server is mis-configured, No ‘Authorization: Basic’ header found. Either the client didn’t send one, or the server is misconfigured",“Code”:0,“Trace”:[{“function”:“beforeMethod”,“class”:“Sabre\DAV\Auth\Plugin”,“type”:"->",“args”:[{“absoluteUrl”:“","class”:“Sabre\HTTP\Request”},{“class”:“Sabre\HTTP\Response”}]},{“file”:"/var/www/chrooted/jrweb/htdocs/",“line”:105,“function”:“call_user_func_array”,“args”:[[{“autoRequireLogin”:true,“class”:“Sabre\DAV\Auth\Plugin”},“beforeMethod”],[{“absoluteUrl”:“","class”:“Sabre\HTTP\Request”},{“class”:“Sabre\HTTP\Response”}]]},{“file”:"/var/www/chrooted/jrweb/htdocs/",“line”:466,“function”:“emit”,“class”:“Sabre\Event\EventEmitter”,“type”:"->",“args”:[“beforeMethod”,[{“absoluteUrl”:“","class”:“Sabre\HTTP\Request”},{“class”:“Sabre\HTTP\Response”}]]},{“file”:"/var/www/chrooted/jrweb/htdocs/",“line”:254,“function”:“invokeMethod”,“class”:“Sabre\DAV\Server”,“type”:"->",“args”:[{“absoluteUrl”:“","class”:“Sabre\HTTP\Request”},{“class”:“Sabre\HTTP\Response”}]},{“file”:"/var/www/chrooted/jrweb/htdocs/",“line”:316,“function”:“exec”,“class”:“Sabre\DAV\Server”,“type”:"->",“args”:[]},{“file”:"/var/www/chrooted/jrweb/htdocs/",“line”:35,“function”:“exec”,“class”:“OCA\DAV\Server”,“type”:"->",“args”:[]},{“file”:"/var/www/chrooted/jrweb/htdocs/",“line”:163,“args”:["/var/www/chrooted/jrweb/htdocs/"],“function”:“require_once”}],“File”:"/var/www/chrooted/jrweb/htdocs/",“Line”:168,“CustomMessage”:"–"},“userAgent”:“Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 Lightning/6.2.7”,“version”:“”}

I had the same problem syncing empty folder. Solved it by backing up parent folder, unchecking it from syncing, removing it from cloud, then add it back again.

1 Like

Same issue on Windows 10 and MacOS Mojave

It works, thank you!