Nextcloud_debug_archive.zip

I have the same issue on arch linux also with gnome. My nextcloud folder is located on a ntfs drive (windows dual boot) and mounted using ntfs-3g. I've reverted to 3.14.3 and everything worked again

Same issue with NTFS partition on Arch Linux when using 3.15.0
3.14.3 works fine

Same Problem on Linux Mint 22 Cinnamon with 3.15 Flatpak

Hope this will fixed fast.

Desktop Client version 3.15.1 still has same issue.

Nextcloud_debug_archive.zip

Desktop Client version 3.15.2 still has same issue.

Nextcloud_debug_archive.zip

Can confirm I experience the same issues running 3.15.2 on Arch using KDE, ext4 formatted drives.

I tried downgrading to 3.14.3 but the problem still persists. If I restart nextcloud it will sync fine until I change a file - then it hangs.

I am also experiencing the same hanging issue on Arch Linux with only ext4 formatted drives. Downgrading to 3.14.1 seems to resolve the issue, but every version after that one leads to UI hangs and seemingly indefinite CPU usage for me. It sounds like the issue only cropped up after 3.14.3 for some users, but I definitely see the same issue with that build, and it sounds like some others here also still saw issues with 3.14.3.

If others here could confirm whether 3.14.1 does or doesn't show the same issue, that might help bisect the issue.

3.13.4 Appimage is running on my Linux Mint 22 the last, that runs normal.
3.14 is not startable as an Appimage - wants passwords busshit
3.15.2 als flatpak (normal i use flatpak) has also the bug that it syncs all time, despite nothing is changed on the file system.
3.14.x as flatpak had run fine. 3.15.x brought the bug

Just updated on arch... Same result. CPU 100%, flooding logs.

I already deleted package cache. How I can download previous version at arch linux? On mirror is already new version.

Check the arch linux archive for prior versions: https://archive.archlinux.org/

Check the arch linux archive for prior versions: https://archive.archlinux.org/

Thanks https://archive.archlinux.org/repos/2024/11/09/extra/os/x86_64/nextcloud-client-2%3A3.14.3-1-x86_64.pkg.tar.zst

I tried to compile it from sources, but after hour it seg faulted in some test

I am also experiencing the same hanging issue on Arch Linux with only ext4 formatted drives. Downgrading to 3.14.1 seems to resolve the issue, but every version after that one leads to UI hangs and seemingly indefinite CPU usage for me. It sounds like the issue only cropped up after 3.14.3 for some users, but I definitely see the same issue with that build, and it sounds like some others here also still saw issues with 3.14.3.

If others here could confirm whether 3.14.1 does or doesn't show the same issue, that might help bisect the issue.

This did not resolve the issue for me.

I did some testing. I find that if I create an empty file (touch foo for example) in the Nextcloud root folder or in a folder with fewer files there is no issue. However, if I create a file in a specific folder (a 130 GB one with many files and git repos) Nextcloud hangs as described by this issue.

I can confirm the problem (on Debian sid using 3.15.0).
My nextcloud folder is also on an NTFS partition and after the upgrade I saw a high CPU load of the nextcloud binary and the ntfs-3g fuse driver.
I ran git bisect which showed 5b2af16 as the first faulty commit.
I suppose that trying to apply the file permissions does not work on NTFS so nextcloud tries it over and over again.

@mgallien ^ can you please have a look

I've rebuilt 3.15.2 with 5b2af16 reverted and nextcloud-desktop is working properly again.

For completeness sake, the NTFS partition is mounted like this:

$ grep data /etc/fstab
LABEL=Data      /mnt/data       ntfs-3g auto            0       0

$ findmnt /mnt/data 
TARGET    SOURCE          FSTYPE  OPTIONS
/mnt/data /dev/nvme0n1p11 fuseblk rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096

I have the same issues using the same account in two different systems having the latest nextcloud client. htop reports 100% CPU while the UI is unresponsive. I have had this behavior in debian and arch linux.

My account has around 150000 files

This causes disk IO on my desktop to run Debian, as I can hear the drive needle of my HDD working. In Debian, the system is NTFS. In my laptop running arch I am using ext4 storage and get the same behavior. This drains the battery of my laptop and causes it to run hot.

To make things worse, the service was auto spawned from the bus service, and I could not even kill the client without it restarting.

Can you please tell us what information we need to upload to get help with this issue?

I've filed a downstream bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091614 and the Debian maintainer was so kind to revert the problematic commit in the Debian package until a proper fix is found.

3.15.50 version from daily channel still has this bug. (OS: Linux Mint 22)

I've filed a downstream bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091614 and the Debian maintainer was so kind to revert the problematic commit in the Debian package until a proper fix is found.

Is possible do that same for other distros too?

Everytime when I update arch I have to downgrade afterwards nextcloud client, mostly I remember right after 100% cpu and battery drain after 1 hour instead 6h.

3.14.3 should work fine as well.

As @grossardt pointed out, 3.14.1 is the correct one to downgrade, at least for my case. 3.14.3 is not getting stuck like 3.15.x but eventually after a
longer period it also hits 100% CPU.

Yeah, I'm guessing that we're dealing with 2 different issues here. I'm not sure though. But the fact, that there is 2 versions making a difference, points towards it. Yet, guessing doesn't help here anyway. Just my 2 pennies...

I do not have high CPU usage, but I do have the filesystem problem. If I sync to the ext4 partition, where the OS is stored as well, no problems. If I sync to an NTFS partition on a different drive, (that can also be accessed by Windows Dual Boot) - it keeps saying: "Looking for folder changes" or "preparing to sync" or "beginning sync" - or it is offline altogether even though I have internet. Although, sometimes it works briefly and even syncs some files that I added. But then it stops recognizing new files, even after hours of waiting.

OS: Linux Mint 21.3 Cinnamon
Client: I built the #7745 Pull Request from Source, hoping it would save me (see my Blog Post). I tried a lot of different clients, older ones, very old ones, but they were all stuck in Offline Mode. Maybe because of different issues with my setup.

The fact that it does not work since a few months now painfully highlights how important Nextcloud sync has become in my daily life. Maybe you can take it as a compliment. Keep up the good work.

Can anyone confirm if v3.16 fixed anything regarding disk trashing & endless "sync"? Based on my tests, it didn't.

Oh well... back to v3.14.3.

@affe42 no, it does not fix the bug, that is why this bug is still open. They put it on the list for 3.16.1 if I remember correctly. You can track the progress here 💻 Desktop Clients team
It is already "In Progress", which is a good sign.

Indeed, the problem persists! Too bad! Anyway here's my log, if it helps...

Nextcloud_debug_archive.zip

Back to 3.14.3...

3.16.1 still has same issue... Getting tired of cleaning up logs, so github's upload limit doesn't explode...

Additionally, since 3.16.0 the client messes up the sync_*.db's so everytime I try the new version, the old 3.14.3 version has to resync everything from scratch! That's quite a mess! Please don't fuck up my DBs people!
I now have 3 accounts on the same server that fire up the old nice message, that there's mulitple accounts using the same sync... That's pretty annoying... One DB for 3.14.3, one for 3.16.0 and one for 3.16.1!

Any plan when this is going to be fixed? Will this fix be backported to previous versions? Users are getting their laptop batteries drained because of this behavior. Also, several linux distros have the client nextcloud client spawned by the dbus so even if it is killed by the user, it manually it autostarts. I hope the nextcloud team understands the impact of this behaviour in their user base and can provide a guideline of how users should deal with this issue.

I already asked arch linux if they will downgrade package, but they said problem is not on their side, so they will not do anything and there are not so many user with ntfs

https://gitlab.archlinux.org/archlinux/packaging/packages/nextcloud-client/-/issues/10

It seems that we have the same bug on windows 10/11 (so ntfs), desktop client 3.15.3 and nextcloud server 30.0.6.
Client gets randomly stuck on "Checking folder changes", we are forced to quit and restart it, and sometimes it manages to finish sync.

I just wanted to reiterate that this bug is not exclusively an issue with NTFS partitions. I have no NTFS partition involved but experience the same problem. My nextcloud files are in an ext4 on LVM on LUKS partition.

[Edit rather than new comment to not add to the cluttering:]
I upgraded to 3.15.3 in order to get some logs on the issue but strangely (at least for now) my issue seems fixed - maybe through some kernel or third party upgrade(?). If it comes back I will open a new bug report.

[Edit 2]
After running fine for three days, it got stuck at 100% CPU again. I am unsure if its a duplicate of #7729 - so will stick with 3.14.1 for now and wait for the stable Arch release of 3.16 to see if it helps.

I just wanted to reiterate that this bug is not exclusively an issue with NTFS partitions. I have no NTFS partition involved but experience the same problem. My nextcloud files are in an ext4 on LVM on LUKS partition.

same symptoms, but different root cause. Thus should be handled via a separate bug report.

@mgallien can you please lock this issue?
The root cause is pretty much known at this point and those me too's do not add any value and are just cluttering the bug tracker.

Yes, lock it, do not solve it, make it as 'not planed' we will forever use 3.14.3 version.

Yes, lock it, do not solve it, make it as 'not planed' we will forever use 3.14.3 version.

That's not fair! There is a fix in progress, which just haven't been finished yet. I too am getting restless, since it's been quite a while, but no reason to be that sarcastic! Seems like the dev's need more personnel!

For the record: 3.16.2 still has same issue...

I can second that. Every time when I put the MacBook to sleep I still have this issue. I need to completely quit the client and restart for it to resolve.

I am experiencing this too on mac OS.

In my case, it seems to be stuck uploading a big file.
Once I moved the file to a non sync folder, the issue was gone...

Can confirm that the issue still persists on 3.16.2 on Arch Linux stuck on high cpu consumption and being unresponsive. This is still a huge problem since it drains my laptop battery in no time. Normally I would get 10-11 hours with 100%-10%, with Nextcloud active in the unresponsive state, it reduces the battery to around 4 hours.

As a workaround I have paused sync for all instances and only activate it on demand.

On MacOS Apple Silicon the client is also stuck at "preparing to sync" or "checking folder changes"

chiming in:

My NTFS drive is mounted:
/dev/disk/by-uuid/B208763A0875FDA3 /media/oppi/DATA auto nosuid,nodev,nofail,x-gvfs-show,uid=1000,gid=1000\040 0 0

All is fine up to client 3.14.3.
Anything later loops endless.
(using App Image, but tried flatpak as well - no difference)

My OS is latest LMDE.

3.16.3 still has the same issue...

And still the client does a complete sync after reverting to 3.14.3. Battery and harddisk killer... 🦖

Same issues here with 3.16.3 but server storage is ZFS in my case.

Running the 3.14.1 appimage without issue.

Can confirm that the issue is still present with 3.16.3

I, too, am experiencing this. No NTFS is involved in my setup either. Happy to troubleshoot/help however I can. This is not an issue with VFS disabled/the non-VFS client in use.

3.16.4 still has same issue...

@mgallien and @mbiebl is there any sense in keep on reporting this? Or is it wasting my time? Any info, on when the fix is coming is appreciated!
Thanks!

@chris-blues I'm not a nextcloud developer, i.e. I can't foresee when a fix will be ready and as long as the issue is open it is clear that the issue is not fixed and posting an update or another me-too is imho not really helping the developers.

What you can do (and what I did) is to contact the maintainer of my downstream distribution (Debian) to temporarily revert the problematic commit and thankfully he agreed, so Debian and Ubuntu packages (as shipped in the distro) are not affected.

same issue with nextcloud-client 3.16.4-1 on arch linux with kde plasma.
Revert to 3.14.3 (26658) appimage solve the problem.