[Bug]: client unusable on Arch, tried multiple versions

[AgyarJanos]

⚠️ 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

Multiple issues; in principle they should be reported separately but I am moving on from Nextcloud as I need reliable data storage today.

Two systems, both running Arch Linux, hardware differs (laptop vs desktop) but identically configured otherwise, both updated fully at least once a day. If you're not familiar, Arch uses rolling releases and there isn't really a "current version" to give of the OS. Basically, though, more current than any other distro you're likely to use, so generic "maybe you're not using the updated thisorthat library" answers will not help.

1. One machine has ~280GB in ~168,000 files; all drives are local. On this, sync never happens at all. The client reports scanning something like 36K files and 116GB, then CPU utilization goes to zero and nothing further happens, even if left alone overnight. I've removed and re-added the sync folder multiple times, deleted hidden Nextcloud files within it each time, removed everything in .config/Nextcloud and .local/share/Nextcloud multiple times. I've tried the AUR current version, 3.15.3daily, as well as the 15.3 and the 14.3 AppImage versions. No change to behavior of the app. .nextcloudsync.log always has zero bytes. (I also renamed files with names that were "too long"...)
2. Second machine has ~55GB in ~82000 files, a subset of the same files on the larger machine. Sync works fine. At some point after starting, time involved varied and I didn't track it, one core goes to 100% utilization. I've only tried the Arch version of Nextcloud on this machine (though I've uninstalled and reinstalled and deleted local files as described above several times), as if the machine above doesn't work at all there's no point in addressing this on my end. There are always 0 bytes in .nextcloudsync.log on this machine as well. As a minor side note, it's fairly ridiculous to fail to sync some files because of long filenames. I figured out an easy workaround bc those particular files are only accessed by an app I wrote, but still. This issue affected nothing else in this "report," as the other issues existed with or without those files.

I hope you guys fix this stuff for other users, but it seems unlikely to be done soon. So I've uninstalled the Nextcloud client and moved on to a simple rsync/inotifywait solution for now. I am willing to reinstall and play with it a bit if you need more info, but that's about the limit of my future involvement.
...

Steps to reproduce

1. Start Nextcloud
2. Log in if necessary
3. Watch the issues above happen.

Expected behavior

Syncing would have been nice to see. Also, eternally using 100% of a core and locking up the client should probably not happen. Quite possibly the sync log file should either have content or not exist if it's unused. Given that all systems involved are running Linux, and all files are accessible locally, the "long filename" issue likely should not exist.

Which files are affected by this bug

.nextcloudsync.log

Operating system

Linux

Which version of the operating system you are running.

Arch Linux (doesn't have versions as it's a rolling release)

Package

Official Linux AppImage

Nextcloud Server version

hosted with hetzner

Nextcloud Desktop Client version

15.3.3daily, 15.3 AppImage, 14.3 AppImage

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

Fresh desktop client install

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

not available

Additional info

I am not able to send you logs, as they include confidential info (filenames, at least for the unencrypted files).

[AgyarJanos]

FYI by "unencrypted files" I meant some of the folders are encrypted via encfs locally, not that end to end encryption via Nextcloud was in use anywhere in this.

[nilsding]

Are you using encfs on both machines, or just the first one?

as for the 2nd issue, it sounds like this is #7729 -- you might want to try out the 3.16.0-rc1 or a recent daily AppImage build for that

more current than any other distro you're likely to use

some of us use Arch btw too ;-)

[AgyarJanos]

1. encfs is used on both machines, for the same files. About 35gb.
2. If the first issue isn't fixed, the second won't matter...can't use Nextcloud in that scenario.
3. Ha! Yes, I get a little smug about using Arch sometimes. But, you know, often (even on github) people don't know what I'm talking about and kinda waste some back & forth time....

Thanks for the reply. I'm using Syncthing for now. Does what I want, including encrypting everything off-premises without needing encfs (though that's still in place also). Very slow, though. Luckily that's not really an issue for me.

[dgva]

Using EndeavourOS (same repos as "pure" Arch), client also is stuck on sync, but nothing is actually syncing. Been like this for about a month.

Client: extra/nextcloud-client 2:3.15.3-1
Server: Also hosted on Hetzner servers

EDIT: tested the AppImage 3.15.3, reseted configs and folders, and now it seems to be syncing. I'll keep testing to see if the problem returns.

EDIT 2: Sorry for the edits. Since the AppImage seemed to work, i made a clean reinstall of extra/nextcloud-client 2:3.15.3-1 and now it seems to be syncing properly. Will keep updating this if anything changes.