Desktop: PROPFIND Reply is not XML Formatted

[sseneca]

This seems to be an issue with the client. I originally opened an issue on the server repo: https://github.com/nextcloud/server/issues/13157

Steps to reproduce

1. Try to upload large amount of files/folders (1GB)

Expected behaviour

All files and folders should be uploaded to the server

Actual behaviour

After uploading some files (usually the majority, actually), I get PROPFIND Reply is not XML Formatted and the uploading stops.

Server configuration

Operating system: Debian/Raspbian 9 stretch

Web server: Apache 2.4.25, with HTTP2 enabled

Database: MariaDB 10

PHP version: 7.2

Nextcloud version: 15 (happens on 14 as well)

Updated from an older Nextcloud/ownCloud or fresh install: Fresh install

Where did you install Nextcloud from: Using NextCloudPi

Signing status:

No errors have been found.

List of activated apps:

- Accessibility
- Activity
- Calendar
- Collaborative tags
- Comments
- Contacts
- Deleted files
- Federation
- File sharing
- First run wizard
- Gallery
- Log reader
- Monitoring
- News
- Nextcloud announcements
- Notes
- Notifications
- Password policy
- PDF viewer
- Preview Generator
- Share by mail
- Support
- Tasks
- Text editor
- Themeing
- Update notification
- Usage survey
- Versions
- Video player

Nextcloud configuration:

Config report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": {
           ***REDACTED***
        },
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "15.0.0.10",
        "overwrite.cli.url": "***REDACTED***",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0,
            "password": "***REMOVED SENSITIVE VALUE***"
        },
        "tempdirectory": "\/var\/www\/nextcloud\/data\/tmp",
        "mail_smtpmode": "sendmail",
        "mail_smtpauthtype": "LOGIN",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "overwriteprotocol": "https",
        "loglevel": "2",
        "log_type": "file",
        "htaccess.RewriteBase": ""
    }
}

Are you using external storage, if yes which one: local usb stick

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Client configuration

Browser: Firefox

Operating system: Arch Linux

NC Client Version: 2.5.1, 2.5. Happens with OC Client 2.5.1 as well

OS language: en_GB

Related discussion on forums: https://help.nextcloud.com/t/propfind-reply-is-not-xml-formatted/

---

Qt version used by client package (Linux only, see also Settings dialog): Qt 5.12.0

Client package (From Nextcloud or distro) (Linux only): Distro

Installation path of client: /usr/bin/nextcloud

[AlexMV12]

I can confirm this doesn't happen with version 2.3.3, no matter the server version (14 or 15).

[Tanarri]

I also confirm - testet with Server 15.0.2
Client V2.3.3 works like a charm
Client V2.5.1 have the XML error

[baldurmen]

Upgrading to Nextcloud 15.0.4.0 and starting from a fresh directory (i.e. re-downloading everything) fixed that issue for me.

[jdefoe2]

I now have 15.0.4 installed and tried upgrading my client to 2.5.1, but got a combination of PROPFIND errors and client crashes. Again, downgrading to 2.3.3 solves the problem straight away. In my case starting from a fresh directory wasn't an option since my server backup is for my entire /home/ folder.

[wurmf]

Upgrading to Nextcloud 15.0.4.0 and starting from a fresh directory (i.e. re-downloading everything) fixed that issue for me.

Cannot confirm that. Upgraded to Nextcloud 15.0.4 and started from fresh directory but still get the same error.

I'm using client version 2.5.1.

[martingwb]

I can confirm this started to happen after upgrade to the 2.5.1 client with NC 14, upgrade to 15 did not change things.
Find enclosed a log from the client:
… [_csync_detect_update Checking for rename based on fileid 00010088ockubejeb23o [_csync_detect_update file: 0-9/foldername, instruction: INSTRUCTION_NEW <<= [OCC::AccessManager::createRequest 6 "PROPFIND" "https://servername/remote.php/dav/files/path/Musik/0-9/foldername" has X-Request-ID "36b323d1-19e6-4be3-ac74-854c3d6df3b0" [OCC::AbstractNetworkJob::start OCC::LsColJob created for "https://servername" + "/Musik/0-9/foldername" "OCC::DiscoverySingleDirectoryJob" [unknown stream 15 finished with error: "" [OCC::WebFlowCredentials::slotFinished request finished [OCC::WebFlowCredentials::stillValid Still valid? [OCC::WebFlowCredentials::stillValid QNetworkReply::NetworkError(NoError) [OCC::WebFlowCredentials::stillValid "Unbekannter Fehler" [OCC::LsColJob::finished LSCOL of QUrl("https://servername/remote.php/dav/files/path/Musik/0-9/foldername") FINISHED WITH STATUS "OK" [OCC::DiscoverySingleDirectoryJob::lsJobFinishedWithErrorSlot LSCOL job error "Unbekannter Fehler" 0 QNetworkReply::NetworkError(NoError) [csync_ftw opendir failed for 0-9/foldername - errno 10011 [OCC::SyncEngine::handleSyncError ERROR during csync_update : "Es hat sich ein HTTP-Übertragungsfehler ereignet. Server error: PROPFIND reply is not XML formatted!" [OCC::ActivityWidget::addError Item "Musik" retrieved resulted in "Es hat sich ein HTTP-Übertragungsfehler ereignet. Server error: PROPFIND reply is not XML formatted!" [OCC::ActivityListModel::addErrorToActivityList Error successfully added to the notification list: "Es hat sich ein HTTP-Übertragungsfehler ereignet. Server error: PROPFIND reply is not XML formatted!" [OCC::SyncJournalDb::close Closing DB "/home/path/Musik/._sync_348717f8624e.db" [OCC::SyncEngine::finalize CSync run took 10153 ms [OCC::Folder::slotSyncFinished Client version 2.5.2git Qt 5.11.1 SSL OpenSSL 1.1.1 11 Sep 2018 [OCC::Folder::slotSyncFinished SyncEngine finished with ERROR [OCC::Folder::showSyncResultPopup Folder sync result: 2 ...

[mrkskwsnck]

@martingwb I can confirm that client version 2.5.1 has problems with NC 14 and 15, respectively. Also, I can confirm that downgrading to client version 2.3.3 solves the problems. Pity :-(

[camilasan]

Hi! Have you tried our rc for 2.5.2?
https://download.nextcloud.com/desktop/prereleases/Linux/Nextcloud-2.5.2.20190205-rc1-x86_64.AppImage
I believe this issue is solved.
Let me know if it works.
Thanks.

[jdefoe2]

Hi, I would like to try the 2.5.2rc but I'm not sure how. What is an AppImage file? I am used to .deb files for manually installing packages (Ubuntu 18.04). There is the client package and also usually a library package -- does this contain both somehow?

[sseneca]

@camilasan Hi!

Just tested with 2.5.2rc, and unfortunately I get the same error:

[Tanarri]

@camilasan Hi!

I also tested 2.5.2rc, and I also get the same error. (Server Version 15.0.5 on a armbian cubietruck)
V2.3.3 works like a charm

[72Zn]

I can confirm. I have the same error with 2.5.1 and 2.5.2rc and Nextcloud 15. Tested under Ubuntu 18.04 and Kali 2019.1. Downgrading to 2.3.3 solved the issue.

[g00sed]

How are you all downgrading?

[mrkskwsnck]

@g00sed It depends on your Linux distribution. For example you cannot downgrade within the official Ubuntu bionic repository, nor the Nextcloud repository. But you can download an AppImage from over here: https://download.nextcloud.com/desktop/releases/Linux/

[72Zn]

How are you all downgrading?

I'm on debian testing. I did the following:

1. purge everything nextcloud
   apt purge nextcloud-desktop* nautilus-nextcloud libnextcloud*

2. Download and install the following packages from debian stretch backports
   https://packages.debian.org/search?keywords=owncloud&searchon=names&section=all&suite=stretch-backports

libowncloudsync0_2.4.1+dfsg-1~bpo9+1_amd64.deb
owncloud-client_2.4.1+dfsg-1~bpo9+1_amd64.deb
owncloud-client-l10n_2.4.1+dfsg-1~bpo9+1_all.deb

You might have to repair some dependencies sometime during the process. I don't remember. But it was painless once I knew where to get the packages.

[Bleuzen]

I there any fix without downgrading?
The 2.3.3 AppImage doesn't start on my system and I also need a client that supports 2fa login (I guess 2.3.3 doesn't with it's old login system).

2.5.2 still shows this propfind reply is not xml formatted error :/

[sseneca]

@Bleuzen, unfortunately it seems that currently downgrading is the only fix that works for everyone. This comment may interest you, though.

[fabian727]

for me a reconfiguration from 2M to 1024M in every php.ini file and a server (apache2) restart did it (at the moment everything is syncing (after initial re-setup because of upgrade)

[Tanarri]

I installed V2.5.3-RC1 and it seen the problem is fixed for me.
I am using the RC1 a few days now, and all runs fine

[Milokita]

The problem presists in 2.5.3daily-Win64 (build 20190725)

[brainchild0]

Confirmed, issue persists with latest releases, server 17.0.0 and client 2.6.1rc1 (on Linux Mint 19.2):

Permission denied: Error Transferring https://yourdomain.com/index.php/apps/files - server replied: PROPFIND Reply is not XML Formatted

[brainchild0]

By the way, is a workaround available?

Currently this issue is quite expansive, as it precludes introduction of new clients to synchronize with affected server folders

[Milokita]

By the way, is a workaround available?

Currently this issue is quite expansive, as it precludes introduction of new clients to synchronize with affected server folders

for your reference
https://github.com/nextcloud/desktop/issues/1182#issuecomment-548248310

[brainchild0]

@Milokita, I first encountered this problem a few days ago when I configured a new client. As the client was new, I chose to use desktop client 2.6.1-rc1.

You reference another issue, which leads me to two points of confusion:

• That issue is considered resolved in the same release where I am observing it.
• That issue relates to file names which contain umlauts. While I haven't checked exhaustively, I believe all files names in the particular folder are named using characters in the ASCII block (i.e. no non-English letters).

Prior to your recent comments the issues were not related. What do you identify as the relation?

[Milokita]

@Mikokita, I first encountered this problem a few days ago when I configured a new client. As the client was new, I chose to use desktop client 2.6.1-rc1.

You reference another issue, which leads me to two points of confusion:

* That issue is considered resolved in the same release where I am observing it.

* That issue relates to file names which contain umlauts.  While I haven't checked exhaustively, I believe all files names in the particular folder are named using characters in the ASCII block (i.e. no non-English letters).

Prior to your recent comments the issues were not related. What do you identify as the relation?

The short answer is: use client from owncloud for now.

As pointed out by @papjul, this issue is related to a bug in Qt, which affects all files containing non-english characters. If you don't want to use owncloud, you can try to disable http2 in your server.

[brainchild0]

@Milokita, these two issues appear to be separate. @papjul hasn't referenced this one, and I just confirmed that all my files in the affected folder have only ASCII characters in the names.

[Milokita]

@brainchild0
Interesting, do you enable http2? what's the size of your file? do you use apache2 or nginx?

[brainchild0]

@Milokita I'm not sure that the discussion you're starting belongs in this issue.

[baldurmen]

@Milokita that would make a lot of sense.... I still have this error and I did start having problems when I enabled http2 (on Apache).

I also have non-ASCII files.

[mduller]

I had a very similar issue (though it was a Connection Timeout Error in my case) that kept my Windows client 2.6.1stable from syncing successfully with NC 17.0.1. I had a couple of changes pending (renaming of files and addition of new files) that included files with non-ASCII characters. Long story short: after disabling http2 (by commenting out the LoadModule in Apache 2.4's config) the Windows client was able to sync successfully. I have since renabled http2 again and so far it's syncing nicely again with http2 enabled.
If this is a known issue with Qt and http2, is there an issue in Nextcloud that tracks the respective Qt issue?

[misch7]

[...]
Long story short: after disabling http2 (by commenting out the LoadModule in Apache 2.4's config) the Windows client was able to sync successfully. I have since renabled http2 again and so far it's syncing nicely again with http2 enabled.
If this is a known issue with Qt and http2, is there an issue in Nextcloud that tracks the respective Qt issue?

It's not that easy to track because of other issues, indirectly related to HTTP/2 bugs in Qt:
https://github.com/nextcloud/desktop/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+http2

Please see: https://github.com/nextcloud/desktop/issues/1503#issuecomment-593191875

The general issue would be #1072, I guess.

[e-alfred]

This issue sometimes seems to come up if an external storage is not available currently (showing up red in the web interface).