Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Synology CloudSync client gets stuck syncing via WebDAV #10123

Closed
mback2k opened this issue Jul 5, 2018 · 14 comments
Closed

Synology CloudSync client gets stuck syncing via WebDAV #10123

mback2k opened this issue Jul 5, 2018 · 14 comments
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap bug feature: dav

Comments

@mback2k
Copy link

mback2k commented Jul 5, 2018

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.
@nextcloud-bot
Copy link
Member

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

@MorrisJobke
Copy link
Member

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

@MorrisJobke MorrisJobke added feature: dav 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Jul 6, 2018
@rullzer
Copy link
Member

rullzer commented Jul 6, 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.

@MorrisJobke
Copy link
Member

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.

@mback2k
Copy link
Author

mback2k commented Jul 7, 2018 •
edited
Loading

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 <d:collection/>.

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?

@MorrisJobke MorrisJobke reopened this Jul 8, 2018
@rullzer
Copy link
Member

rullzer commented Jul 8, 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
Copy link
Member

rullzer commented Jul 9, 2018

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

@rullzer rullzer closed this as completed Jul 9, 2018
@mback2k
Copy link
Author

mback2k commented Jul 9, 2018 •
edited
Loading

@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
Copy link
Author

mback2k commented Aug 13, 2018 •
edited
Loading

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.

@TheDom42
Copy link

TheDom42 commented Jul 6, 2020

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.

@mback2k
Copy link
Author

mback2k commented Jul 6, 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.

@TheDom42
Copy link

TheDom42 commented Jul 6, 2020

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.

@mback2k
Copy link
Author

mback2k commented Jul 6, 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.

@TheDom42
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap bug feature: dav
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@rullzer @mback2k @MorrisJobke @nextcloud-bot @TheDom42