Desktop: Synchronization broken on Linux

Created on 9 Mar 2019  路  24Comments  路  Source: nextcloud/desktop


Other people have already written in-depth about their experience with this issue, but unfortunately it seems they didn't make an issue, so I'm doing that in hopes that this will be solved.
At least I believe it's the same issue, especially since the report is only few days old.
This is the original report: https://help.nextcloud.com/t/nextcloud-linux-appimage-2-5-1-cant-sync-time-out-after-16kb/48534/3

Expected behaviour

Files being synced from my Linux desktop to my nextcloud server

Actual behaviour

File upload gets stuck on few hundred kilobytes, not proceeding at all until eventual timeout.

Steps to reproduce

  1. install the latest nextcloud version on OpenSuse Tumbleweed
  2. sign into an account (use https, the thread mentions http may work) and begin syncing something
  3. I don't know if it happens straight away, but at the point I am right now, what I describe in "Actual Behaviour" happens constanly, and doesn't stop happening because the synchronization always fails and therefore new one alwas begins.

Client configuration

Client version: 2.5.1git

Operating system: OpenSuse Tumbleweed

OS language: English

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

Client package (From Nextcloud or distro) (Linux only): distro (nextcloud-client, version 2.5.1-4.2)

Installation path of client: /usr/bin/nextcloud

Server configuration

Not relevant I don't think, it's 15.0.2 on webhost

bug feature sync engine os Linux regression

All 24 comments

Experiencing the same behaviour using 2.5.1git on Ubuntu 18.04.2

I have the same issue, starting ~ a week ago. What I surely can say: this occure only if the client on Ubuntu 18.04 is in the same network as your nextcloud server (client and server got same IPv4).

I tried all local connection types (two wireless, one ethernet) and all failed to connect.
Then I connect the laptop with the client by mobile tethering and all works fine.
(so there is no reason to switch connection to http)

I assume that update of some linux package(s) caused this?
Probably someone could have a deeper look into this.

I have the same issue, starting ~ a week ago. What I surely can say: this occure only if the client on Ubuntu 18.04 is in the same network as your nextcloud server (client and server got same IPv4).

I tried all local connection types (two wireless, one ethernet) and all failed to connect.
Then I connect the laptop with the client by mobile tethering and all works fine.
(so there is no reason to switch connection to http)

I can confirm that, at least in my case, the client and server being in the same network has no effect whatsoever.

using end to end encryption (e2e) can cause similar symptions, see issues #199 and #890.

not using e2e resolved my issues.

It may help others to indicate if e2e is being used for reports about this issue.

EDIT 1:
FWIW: sync works fine for me using nextcloud 15.0.4 from ubuntu 18.04 server to ubuntu desktop 18.04 with nextcloud client 2.5.1git (e2e disabled). Both client and server are on the same network but the url on the client points to a ddyns domain and a high port which is translated to port 443 on the server by my router (I'm not sure how this is routed but given the speed of transfer I don't think its going out off my network).

For reference, I'm also using 2fa and https with a self signed certificate.

nextcloud 15.0.5 is out, I'll upgrade and see if this breaks anything.

EDIT 2:
15.0.5 upgraded no issues and synced to a second ubuntu desktop client (18.04 with 2.5.1git), 104 MB synced of 98GB in use. Similar network config as in edit 1.

using end to end encryption (e2e) can cause similar symptions, see issues #199 and #890.

not using e2e resolved my issues.

It may help others to indicate if e2e is being used for reports about this issue.

I don't use e2e in my instance.

Client was updated yesterday to 2.5.2git but I'm still experiencing the endless scanning

Same issue for me : version 2.5.2 from distribution (Xubuntu 18.04). Endless scanning as soon as the scanned directory contains more then a few files.

I am also experiencing this problem.

Since this doesn't seem to be moving forward, as a workaround I'm using the 2.5.0 version, which works fine https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.5.0-x86_64.AppImage

Any progress on this? It's pretty annoying :(

bumpty bump, this is a very serious issue and I would very much prefer if it got solved.
From my observation, smaller files get a pass, but e.g a 75,6 MB svg file (don't ask) will probably try to sync forever

uhm, it just synced successfully
maybe I'm being a bit too harsh
I guess it's possible my other issues are not related to this
does anyone here still experience this in a reproducible manner?
otherwise I will probably have to close the issue

though now it looks a bit like #1274

the loading bars stuck at 0 and nothing perceivable going on

and now syncing again despite being in sync

may well be #1274

but then again, I've requested re-sync recently

let's see

I will leave it "Waiting..." overnight, that's how much I value giving useful information on this bug

@Mis012 Could you please stop spamming this issue? I (and many others) get an e-mail for each comment you make. Please just edit your comment if you have any additional information instead of creating a new one. Thanks :)

Hey,

we've just released 2.6.1 RC1 which is built with Qt 5.12.5 on all platforms (also has OpenSSL 1.1.1d, so it features TLS 1.3).

You may give it a try:
https://github.com/nextcloud/desktop/releases/tag/v2.6.1-rc1

Perhaps it solves the issue due to the Qt upgrade or other fixes?

I'm using 2.5.1git and e2e encryption and it works now (the e2e not really, but this is another story)

The same here, endless synchronization, in all versions 2.5, 2.5.1, 2.5.2, 2.5.3, 2.6.1...
back to 2.3.3, that works well
Linux 18.10, 19.04, 19.10... the same.
Server in 15.0.13

140K files 80Gb repository

Is this still happening?

Also, could you check, whether it might be related to #1165?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nilsbecker picture nilsbecker  路  3Comments

Linuxfabrik picture Linuxfabrik  路  3Comments

kaysond picture kaysond  路  3Comments

rguenther-dz picture rguenther-dz  路  3Comments

linucksrox picture linucksrox  路  3Comments