Linux Client seems to sync unknown, very small file all the time

šŸ“± Desktop & mobile clients
1

I am running the latest version of nextcloud desktop app (3.15.3) on an up to date (x)ubuntu client againts an up to date NC server.

The client keeps syncing something all the time, but is doesnt tell me which file (unless it syncs a file I really just created/updated).

Is there a way to figure out that the client is actually doing? Can I enable logs on the client side? Thanks a lot in advance.

nextcloud_small_file_sync

1 Like
2

Hi greenorca,

Your screenshot is somewhat unreadably small, and only shows limited information.

My NC client (version 3.7.3 on Debian) shows an activity log when I click on the icon in the task bar. It includes recent uploads.

I donā€™t know of an external log, but via settingsā€“>general, you can create a debug log which includes settings and an SQLite database of all actions.

Does it upload continuously, all the time? If the activity log and debug options do not show anything useful, and in case you didnā€™t think of it, you might troubleshoot by disabling sync locations one by one.

edit to add: I found the log at /home/myself/.config/Nextcloud/logs/ . If you canā€™t find it, a crude tool to get an idea where you might look is locate. If it is not installed, apt install locate, followed by updatedb. After that you can locate nextcloud to get output of all filepaths that have ā€˜nextcloudā€™ in them.

3

I have a very similar problem, running an up to date Windows 10 client (3.15.3) against a Ubuntu server running NC 29. The files client seems to sync continuously, CPU load is about 20 %, CPU frequency is incredibly high all the time :frowning:

I have found the option to export logs, which results in 800 Mb of logfiles. What do I look for?

4

Thanks a lot for the hint with the debug archive. In the logs in the zip files, one can really see one by one what files are synced. ~/.config/Nextcloud/logs seems to contain only logs from a previous NC client version (according to the date). Therefore, I cannot ā€œtailā€ realtime logs at the time the oddities occur.
It would take some time to analyze the zipped logs, but on the first look, I canā€™t see anything suspicious. It just syncs these heap of filesā€¦ Maybe I have too much tiny files on the NC folder that donā€™t really belong there (.git, node_modules etc).

Many thanks for your help.

1 Like
5

You can look inside for the zip file with the specific date and time when the high CPU usage occurs. The log contained will show which file is synced one by one, plus some more info for each file.

6

Judging by the log, in my case, the issue seems to be that every time any file is changed, then every single file is checked again.

In the log I find reference to (seemingly) every single file I have, with something like the following.

2025-01-28 09:33:55:213 [ info nextcloud.sync.discovery /run/build/nextcloud-client/src/libsync/discovery.cpp:553 ]:	"Processing \"path/to/file.md\" | (db/local/remote) | valid: true/true/db | mtime: 1670386732/1670386732/0 | size: 44/44/0 | etag: \"0ff4fb85ad59649863fe67dbdb1263e2\"//\"\" | checksum: \"SHA1:1d44bba81b95e266fa310e3936fc9c075d2ca36c\"//\"\" | perm: \"WDNVR\"//\"\" | fileid: \"04648418ocknvqxzkv7m\"//\"\" | type: CSyncEnums::ItemTypeFile/CSyncEnums::ItemTypeFile/CSyncEnums::ItemTypeFile | e2ee: false/false | e2eeMangledName: \"\"/\"\" | file lock: not locked// | file lock type: \"\"//\"\" | live photo: false//false | metadata missing: /false/"

The sync happens reasonably quickly, but if I have a file that autosaves as I type, or something like that, then all of the files get checked again and again, hence the constant load on the CPU. If I donā€™t touch anything in any of the synced folders, it quiets down.

Any suggestions on what could be checked? In my case itā€™s Nextcloud desktop client 3.15.3 on Fedora, but didnā€™t have this issue until recently, so I suspect this is related to a client update.

7

for windows 10: downgrading to the Desktop Client v3.14.3 (from here: Index of /desktop/releases/Windows) and resyncing seems to do the trickā€¦ No more high CPU usage :slight_smile:

so for me, obviously the desktop client was the reason it didnā€™t work. All 3.15.x versions had the same problem.

8

Similar problem here, using 3.15.3 on Fedora 43. The client keeps ā€œChecking for file changesā€¦ā€ continuously, while causing high CPU load and disk write I/O. Any ideas? Iā€™d want to avoid having to downgrade if not absolutely necessary.