Desktop Client suddenly stopped synchronizing

📱 Desktop & mobile clients 💻 Desktop
, ,
1

Hi everybody, I am seeking assistance in troubleshooting an issue with my Nextcloud Desktop client, which suddenly stopped synchronizing files a few days ago.

  • Client: 3.16.5 (I also tried older versions including 3.15.x, to no avail)
  • OS: Fedora 42 KDE Edition, fully updated
  • Server: 31.0.5.1, self-hosted on a rented server

The server itself works: My cell phone synchronizes just fine, and I installed Fedora 42 KDE Edition in a VirtualBox on the laptop that has the issue; installed the client in that virtual machine and started to synchronize from scratch, works well, including newly added files.

So it must be something specific to my laptop.

Symptoms:

  • Client starts well.
  • Client reports recent activity appropriately, including files that have been added by others.
  • Pending changes/updates to files are being discovered.
  • But then nothing happens, the client says “Syncing changes” forever, the tooltip that appears when hovering over the taskbar icon says “Preparing for sync”.

Given the current issue with slow remote discovery on the first run of client version 3.16.5, I had it sit overnight, nothing happened, and I tried older versions which also no longer sync my files.

The only thing that seems remotely meaningful in the client logs are mentions of “Etag poll timer timeout” like this (timestamps removed for clarity):

[ info nextcloud.gui.folder.manager /home/user/src/gui/folderman.cpp:1009 ]:    Etag poll timer timeout
[ info nextcloud.gui.folder.manager /home/user/src/gui/folderman.cpp:1013 ]:    Folders to sync: 1
[ info nextcloud.gui.folder.manager /home/user/src/gui/folderman.cpp:1023 ]:    Number of folders that don't use push notifications: 1
[ info nextcloud.gui.folder.manager /home/user/src/gui/folderman.cpp:1040 ]:    Run etag job on folder OCC::Folder(0x5587cbf21e40)
[ info nextcloud.gui.folder.manager /home/user/src/gui/folderman.cpp:1046 ]:    Can not run etag job: Sync is running
[ info nextcloud.sync.credentials.webflow /home/user/src/gui/creds/webflowcredentials.cpp:406 ]:        request finished
[ info nextcloud.sync.networkjob.jsonapi /home/user/src/libsync/networkjobs.cpp:969 ]:  JsonApiJob of QUrl("https://***/ocs/v2.php/apps/notifications/api/v2/notifications?format=json") FINISHED WITH STATUS "OK"
[ warning nextcloud.sync.***me/user/src/libsync/networkjobs.cpp:990 ]:       Nothing changed so nothing to retrieve - status code:  304

Thank you for any hints to get this back to a working state!

Changes are being discovered (it seems)
Changes are being discovered (it seems)439Ă—150 14.2 KB

Then it changes to this status and nothing happens, forever
Then it changes to this status and nothing happens, forever657Ă—220 28.9 KB

Taskbar tooltip

2

Since it works fine in your clean VirtualBox install, this is most likely a client issue on your main Fedora system.

Quick question: how exactly did you install the client there?

  • DNF?
  • Flatpak?
  • AppImage?

The “Preparing for sync” + Etag timeout problem often happens with the Flatpak version. I’d recommend testing the official AppImage → https://nextcloud.com/install/#install-clients

3

Thanks for the quick reply. I was indeed using the AppImage all the time.

After poking around even more on my system, I decided to remove what appeared to be a local Nextcloud-specific database file sitting in my cloud’s root folder. Or rather, I did not remove it, I just renamed it.

If others come here with a similar problem, try the following.

  • Terminate the client.

  • Rename the .sync_*.db file which is hidden in the cloud root folder, e.g.:

    mv .sync_bdf0e9092364.db .sync_bdf0e9092364.db.bak

    (I guess the bdf0... part will be different on everyone’s system.)

  • Start the client.

  • The client then goes through all the cloudy files, but transfers only those that actually need to be updated locally or on the server.

  • In case this does not solve the problem, stop the client, rename the database file back to its original name, start the client and hopefully you will find a different solution.

Interestingly, when I did this, some two dozen file conflicts turned up, even with some files that I had not touched in a while. Possibly there had been some database corruption creeping in that eventually caused the synchronization to stall? I don’t know.

So for me, this problem is solved – hopefully this information will be useful for others some time.

Thanks!

1 Like
4

Great to hear you got it sorted! :+1:
It’s interesting that you prefer using the AppImage version over the one from the repos.

I’m running CachyOS (Arch-based) and using the Nextcloud client from the repos — haven’t had any similar issues in the past 3 years.

I personally avoid using the AppImage version, since it still doesn’t support showing sync status icons in the file manager (like green checkmarks, sync arrows, etc.).
The regular client from the repos handles this perfectly.
This might also be something specific to Arch-based distros.

5

Thanks, I had totally forgotton about the repo version :wink: Been using the AppImage ever since my Ubuntu days when I needed one particular bug fix and the repo version was too far behind (IIRC). Will give it a try again :slight_smile: :+1:

1 Like