[Bug]: Version 3.15.n seems to be stuck in an infinite loop during "Checking folder changes". HDD is running hot.

[chris-blues]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

Debian 12 Linux, Gnome DE, Nextcloud Desktop client 3.15.0

Version 3.15.0 seems to be stuck in an infinite loop during "Checking folder changes". HDD is running hot. I've let it run for 30 minutes and more, just to see if it eventually stops at some point. It doesn't.

General startup of the client seems fine. File sync runs through fine. After that it goes into "Checking folder changes" - that's where it gets stuck in the loop. Reaction times get very slow on every action I take in the client. Gnome offers generic "App not responding, should I kill it or wait" warning. With every older Client (e.g. 3.14.3) it works just fine. So there seems to be some regression introduced in 3.15.0...

Edit: seems to be related to the fact, that there is a NTFS partition involved...

If there's any more info I can provide, please let me know.

Steps to reproduce

Startup Nextcloud-3.15.0-x86_64.AppImage
Wait for the app to start up...

Expected behavior

normal startup without trashing my HDD...

Which files are affected by this bug

folder

Operating system

Linux

Which version of the operating system you are running.

Debian 12

Package

Official Linux AppImage

Nextcloud Server version

30.0.3

Nextcloud Desktop Client version

3.15.0

Is this bug present after an update or on a fresh install?

Updated to a major version (3.14.3 to 3.15.0)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

Seems to be internal Desktop Client issue

Additional info

No response

[chris-blues]

Nextcloud_debug_archive.zip

[Thorsten42]

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

[chris-blues]

Im also running on a NTFS drive! Funny, didn't think of that! Thanks for the input!

[MadFatVlad]

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

[stefan-franz]

Same Problem on Linux Mint 22 Cinnamon with 3.15 Flatpak

Hope this will fixed fast.

[chris-blues]

Desktop Client version 3.15.1 still has same issue.

Nextcloud_debug_archive.zip

[chris-blues]

Desktop Client version 3.15.2 still has same issue.

Nextcloud_debug_archive.zip

[blwh]

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.

[alraban]

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.

[stefan-franz]

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

[petrkr]

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.

[alraban]

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

[petrkr]

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

[blwh]

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.

[mbiebl]

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.

[mbiebl]

@mgallien ^ can you please have a look

[mbiebl]

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

[chris-blues]

Very nice! Now let's hope that someone from Nextcloud ever sees this and puts this to work. Thanks a lot. I'd love to put a thumbs up or sth, but github won't let me in anymore since I stupidly activated 2 factor auth. Microsoft is very actively involved in locking people out... Anyway! Good work! And thanks!

[mbiebl]

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

[pati-ni]

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?

[mbiebl]

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.

[thieneret]

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

[petrkr]

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.

[petrkr]

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

[tomdereub]

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.

[grossardt]

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.

[mbiebl]

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.

[petrkr]

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

[chris-blues]

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!

[chris-blues]

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

[jbfriedrich]

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.

[camilasan]

I am experiencing this too on mac OS.

[camilasan]

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...

[MystikReasons]

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.

[Kleisli]

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

[thejulian]

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

[oppiman]

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.

[chris-blues]

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... 🦖

[GetGeit]

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

Running the 3.14.1 appimage without issue.

[MystikReasons]

Can confirm that the issue is still present with 3.16.3

[woah-buddy]

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.

[chris-blues]

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!

[mbiebl]

@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.

[lepolau]

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.

[oppiman]

FYI
it is solved for me.
See: https://help.nextcloud.com/t/endless-syncing-on-linux-3-15-2-and-3-15-3-3-14-3-was-fine/214719/37?u=micha_o

So no bug I guess, but a fundamental change in behavior that seemingly nobody is able to explain.

[pati-ni]

Before trying a full resync of our files and messing with the /etc/fstab file, is it clearer to the developers what is causing this behavior?

[chris-blues]

... is it clearer to the developers what is causing this behavior?

Yes, it's been clear for a while now. As I understand it, the client asks for the FS type, expecting 'NTFS' to be the answer, but Linux reports it as 'fuseblk', which could be anything that is supported by fuse.

Though I'm surprised, that this still wasn't fixed...

[pati-ni]

Yes, it's been clear for a while now. As I understand it, the client asks for the FS type, expecting 'NTFS' to be the answer, but Linux reports it as 'fuseblk', which could be anything that is supported by fuse.

Oh, thanks for this update! So, it is not purely a Nextcloud issue? Should we cross-post this to the fuse repo to see if they can fix it on their end?

[chris-blues]

I would wait for @mgallien and/or @mbiebl to decide that. Wouldn't wanna add more confusion than nessessary. But maybe it might be a good idea to see if fuse could offer some better response than 'fuseblk'...
Let's see, what the devs decide!

[petrkr]

Yes, it's been clear for a while now. As I understand it, the client asks for the FS type, expecting 'NTFS' to be the answer, but Linux reports it as 'fuseblk', which could be anything that is supported by fuse.

Oh, thanks for this update! So, it is not purely a Nextcloud issue? Should we cross-post this to the fuse repo to see if they can fix it on their end?

It is not fuseblk issue.

Everyone use ntfs-3g which uses fuse. So it is not 'badly' reported as fuseblk. It is fuseblk.

Issue is definitely on nextcloud side, as this driver is used for years, because kernel one does not support write.

And also nextcloud client 3.14 works without issues with it.

[jbfriedrich]

I have this issue on macOS, without NTFS being involved at all 😔.

[muety]

Is there a potential fix for this in the offing? Being stuck with 3.14.3 also prevents me from upgrading my system to Fedora 42 meanwhile.