Server: Synology CloudSync client gets stuck syncing via WebDAV

Created on 5 Jul 2018  路  14Comments  路  Source: nextcloud/server

Steps to reproduce

  1. curl -v --header "Depth: 1" -X PROPFIND --basic -u 'account:password' 'URL'
  2. Check XML output for HTTP 404 responses.

Expected behaviour

XML output should be like the following:

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" 
    xmlns:s="http://sabredav.org/ns" 
    xmlns:oc="http://owncloud.org/ns" 
    xmlns:nc="http://nextcloud.org/ns">
    <d:response>
        <d:href>/remote.php/webdav/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Wed, 04 Jul 2018 16:55:53 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>8559175380</d:quota-used-bytes>
                <d:quota-available-bytes>4325726508</d:quota-available-bytes>
                <d:getetag>&quot;5b3cfbeb5a294&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/remote.php/webdav/AppData/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Tue, 03 Jul 2018 18:51:07 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>168688573</d:quota-used-bytes>
                <d:quota-available-bytes>4325726508</d:quota-available-bytes>
                <d:getetag>&quot;5b3bc570aee57&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/remote.php/webdav/CloudStation/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Wed, 04 Jul 2018 16:55:53 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>6872559614</d:quota-used-bytes>
                <d:quota-available-bytes>4325726508</d:quota-available-bytes>
                <d:getetag>&quot;5b3cfbeb5a294&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/remote.php/webdav/Uploads/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Tue, 19 Jun 2018 19:57:04 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>0</d:quota-used-bytes>
                <d:quota-available-bytes>4325726508</d:quota-available-bytes>
                <d:getetag>&quot;5b29601048578&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
</d:multistatus>

Actual behaviour

XML output contains HTTP 404 responses:

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" 
    xmlns:s="http://sabredav.org/ns" 
    xmlns:oc="http://owncloud.org/ns" 
    xmlns:nc="http://nextcloud.org/ns">
    <d:response>
        <d:href>/remote.php/webdav/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Wed, 04 Jul 2018 16:55:53 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>8559175380</d:quota-used-bytes>
                <d:quota-available-bytes>4325726508</d:quota-available-bytes>
                <d:getetag>&quot;5b3cfbeb5a294&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/remote.php/webdav/AppData/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Tue, 03 Jul 2018 18:51:07 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>168688573</d:quota-used-bytes>
                <d:quota-available-bytes>4325726508</d:quota-available-bytes>
                <d:getetag>&quot;5b3bc570aee57&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
        <d:propstat>
            <d:prop>
                <d:getcontentlength/>
                <d:getcontenttype/>
            </d:prop>
            <d:status>HTTP/1.1 404 Not Found</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/remote.php/webdav/CloudStation/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Wed, 04 Jul 2018 16:55:53 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>6872559614</d:quota-used-bytes>
                <d:quota-available-bytes>4325726508</d:quota-available-bytes>
                <d:getetag>&quot;5b3cfbeb5a294&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
        <d:propstat>
            <d:prop>
                <d:getcontentlength/>
                <d:getcontenttype/>
            </d:prop>
            <d:status>HTTP/1.1 404 Not Found</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/remote.php/webdav/Uploads/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Tue, 19 Jun 2018 19:57:04 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>0</d:quota-used-bytes>
                <d:quota-available-bytes>4325726508</d:quota-available-bytes>
                <d:getetag>&quot;5b29601048578&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
        <d:propstat>
            <d:prop>
                <d:getcontentlength/>
                <d:getcontenttype/>
            </d:prop>
            <d:status>HTTP/1.1 404 Not Found</d:status>
        </d:propstat>
    </d:response>
</d:multistatus>

Server configuration

Operating system: Debian 9
Web server: Apache 2.4
Database: MariaDB 10.1
PHP version: PHP 7
Nextcloud version: 13.0.4
Updated from an older Nextcloud/ownCloud or fresh install: Started with 13.0.1
Where did you install Nextcloud from: Bzipped Tarball

Signing status:


Signing status

No errors have been found.

List of activated apps:


App list

Enabled:
  - activity: 2.6.1
  - calendar: 1.6.1
  - comments: 1.3.0
  - contacts: 2.1.5
  - dav: 1.4.7
  - federatedfilesharing: 1.3.1
  - federation: 1.3.0
  - files: 1.8.0
  - files_pdfviewer: 1.2.1
  - files_sharing: 1.5.0
  - files_texteditor: 2.5.1
  - files_trashbin: 1.3.0
  - files_versions: 1.6.0
  - files_videoplayer: 1.2.0
  - firstrunwizard: 2.2.1
  - logreader: 2.0.0
  - lookup_server_connector: 1.1.0
  - nextcloud_announcements: 1.2.0
  - notifications: 2.1.2
  - oauth2: 1.1.1
  - password_policy: 1.3.0
  - provisioning_api: 1.3.0
  - serverinfo: 1.3.0
  - sharebymail: 1.3.0
  - survey_client: 1.1.0
  - systemtags: 1.3.0
  - theming: 1.4.5
  - twofactor_backupcodes: 1.2.3
  - updatenotification: 1.3.0
  - workflowengine: 1.3.0
Disabled:
  - admin_audit
  - encryption
  - files_external
  - gallery
  - user_external
  - user_ldap

Nextcloud configuration:


Config report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "cloud...de"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "https:\/\/cloud...de",
        "htaccess.RewriteBase": "\/",
        "dbtype": "mysql",
        "version": "13.0.4.0",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "apps_paths": [
            {
                "path": "\/var\/www\/nextcloud\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/nextcloud\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "maintenance": false,
        "theme": "",
        "loglevel": 2,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "php",
        "mail_smtpauthtype": "LOGIN",
        "mail_domain": "***REMOVED SENSITIVE VALUE***"
    }
}

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

Client configuration

Browser: WebDAV Client: Synology CloudSync
Operating system: not relevant I think

I would appreciate any help on solving this as Synology tells me that this is probably a server issue.

0. Needs triage bug dav
Source
picture mback2k

Most helpful comment

I took another look at the daemon.log file produced by the CloudSync package and also my webservers access.log. It seems like CloudSync never retried to fetch any files from the WebDAV remote after getting stuck on error code -12. So this issue had nothing to do with the WebDAV protocol not being implemented correctly by Nextcloud.

After getting an HTTP error from Nextcloud while it being unavailable, the CloudSync client got stuck on the error "Sync folder does not exist." forever, never retried the connection and just disabled the "Resume syncing" button.

My solution was the following: I went into the Synology NAS via SSH, sudo su'ed to root, opened the file /volume1/@cloudsync/db/config.sqlite using sqlite3 and changed the error status of the sessions from -12 to 0. After restarting the CloudSync package everything worked again.

You can use the following SQLite queries to select and update the error status:

SELECT sync_folder,error FROM session_table;
UPDATE session_table SET error = 0 WHERE error = -12;
SELECT sync_folder,error FROM session_table;

Thanks for taking a look at this issue anyway. I hope this will help other people who get stuck on the same issue.

picture mback2k on 13 Aug 2018
👍4 🎉2

All 14 comments

GitMate.io thinks possibly related issues are https://github.com/nextcloud/server/issues/3738 (Webdav), https://github.com/nextcloud/server/issues/6100 (Sync Synology and Nextcloud), https://github.com/nextcloud/server/issues/6858 (Add support (directly or via plugin) to hide folders from sync clients/webdav), and https://github.com/nextcloud/server/issues/5947 (webDAV PROPFIND).

nextcloud-bot picture nextcloud-bot on 5 Jul 2018

@rullzer @icewind1991 Any idea where this additional <propstat> element is coming from?

MorrisJobke picture MorrisJobke on 6 Jul 2018

They are perfectly valid responses for webdav. A 404 response on the propstat part just means we could nto find that property for the given resource.

rullzer picture rullzer on 6 Jul 2018

They are perfectly valid responses for webdav. A 404 response on the propstat part just means we could nto find that property for the given resource.

Ah ... got it now. Was confused a little bit, but those are different attributes. I thought there were duplicates.

So this is not the reason for this problem. Thus I will close this as we follow the RFC and this is how it should work. Maybe have a look at the synology logs for further details, what went wrong.

MorrisJobke picture MorrisJobke on 6 Jul 2018

Thanks for your investigation, but Synology support is now claiming the following about the WebDAV response:

Both aren't normal since you don't get any folder list after .

Hence we put it as a server side issue but not a client side issue since you can't even get any folder name by using a curl command.

So now the issue is not about the 404 responses for these additional properties, but the collection actually being empty. Can you also investigate this please?

mback2k picture mback2k on 7 Jul 2018

The collection is supposed to be empty.

We follow the rfc as far as I know. Windows and Mac OS can mount it natively.

rullzer picture rullzer on 8 Jul 2018

@mback2k please reopen if they can point me to the exact part of the RFC that we break.

rullzer picture rullzer on 9 Jul 2018

@rullzer Unfortunately I am talking to a non-technical customer support as it seems:

Per those WebDAV servers we've tested, they would always respond a list of shared folders and Cloud Sync could know how many options it has to set up as a backup destination.

To look at DSM for further details, we'd recommend you reply with Remote Access so we could help you further.

Their only solution seems to be to request remote access to my NAS and Nextcloud, which I do not want to grant them.

mback2k picture mback2k on 9 Jul 2018

I took another look at the daemon.log file produced by the CloudSync package and also my webservers access.log. It seems like CloudSync never retried to fetch any files from the WebDAV remote after getting stuck on error code -12. So this issue had nothing to do with the WebDAV protocol not being implemented correctly by Nextcloud.

After getting an HTTP error from Nextcloud while it being unavailable, the CloudSync client got stuck on the error "Sync folder does not exist." forever, never retried the connection and just disabled the "Resume syncing" button.

My solution was the following: I went into the Synology NAS via SSH, sudo su'ed to root, opened the file /volume1/@cloudsync/db/config.sqlite using sqlite3 and changed the error status of the sessions from -12 to 0. After restarting the CloudSync package everything worked again.

You can use the following SQLite queries to select and update the error status:

SELECT sync_folder,error FROM session_table;
UPDATE session_table SET error = 0 WHERE error = -12;
SELECT sync_folder,error FROM session_table;

Thanks for taking a look at this issue anyway. I hope this will help other people who get stuck on the same issue.

mback2k picture mback2k on 13 Aug 2018
👍4 🎉2

Thanks for pointing me towards the right direction.
I ran into the exact same problem running a NextcloudPi with automatic updates (which always reboots the system, leaving the cloudsync connection in a failing state afterwards).
I don't really feel like always resetting the SQLite DB manually, so I was wondering if you found more permanent solution, @mback2k. Otherwise I would maybe open up another bug report with Synology and hope I would get a different response.

TheDom42 picture TheDom42 on 6 Jul 2020

Unfortunately I did not yet find a different solution. I even made my HTTP loadbalancer return a different error code in case Nextcloud is unavailable, but it seems like error code -12 and error message "Sync folder does not exist." is the same for all HTTP error codes. I just recently opened a new support ticket with Synology due to this, because the recent CloudSync beta looked promising since the changelog included something about improvements to the client getting stuck and fixing resume, but the changes do not help with this issue. I just asked them to be able to click "Resume" for this error, but they are not listening.

mback2k picture mback2k on 6 Jul 2020
👍1

Great, thank you for the update! I'm not sure if opening another bug report with them would help then as it seems that you explained all the technical details to them (which I probably couldn't). I just hope that they will find some kind of permanent solution or at least mitigation for this as this breaks a backup chain of mine if I'm not paying attention.

TheDom42 picture TheDom42 on 6 Jul 2020

I just hope that they will find some kind of permanent solution or at least mitigation for this as this breaks a backup chain of mine if I'm not paying attention.

Same for me. I am regularly nagging them about this. Let's hope they will at some point fix or improve this behavior.

mback2k picture mback2k on 6 Jul 2020

Let's hope they will at some point fix or improve this behavior.

I would like to return with a status update: I received an update for Synology CloudSync at the beginning of September. Nothing was mentioned about WebDAV or any particular stability issues (only concering other Cloud services). However, since that update, I think I never experienced the reconnect issue again. I return with that status message now, because my Nextcloud instance did a reboot yesterday which was usually the cause for the connection loss but so far, connection seems stable.
I was just wondering, if you can confirm this behavior or if that was pure luck so far, @mback2k.

TheDom42 picture TheDom42 on 26 Oct 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

jancborchardt picture jancborchardt  路  3Comments
MorrisJobke picture MorrisJobke  路  3Comments
e-alfred picture e-alfred  路  3Comments
georgehrke picture georgehrke  路  3Comments
blackcrack picture blackcrack  路  3Comments