"All synced!" but lots of files have blue "syncing" icon rather than green checkmark

NextCloudPi 26.0.1, Windows client 3.8.1. Both newly installed.

I synced a bunch of video files from my client and it says “all synced!”, yet I have more files with the blue icon than I do with the green checkmark. “Sync now” or “force sync now” doesn’t change anything (almost instantly returns to “all synced!”), nor does closing and restarting the nextcloud client. What does this mean and how do I fix it?

I tried freeing local space on these and got the “can’t update non existing placeholder info” error ("Can't update non existing placeholder info" error - #8 by weasam).

Why is the nextcloud desktop client not smart enough to sync my video files nor give me meaningful error messages?

I’m still interested in understanding what the problem was there, but I solved it by deleting the contents of my directory and copying the videos in one by one, waiting for each one to sync before doing the next. The failure of a very basic use case is disheartening and creates a confidence issue unfortunately.

When you check on your server, the files are not synced yet? Question is, if it is a sync error that the files is not recognized and transferred or if it is a display error, that they should have the green check marks.

If you place a completely new file in your sync folder, is it syncing then? Feel free to check the logfiles if there is some helpful information:
https://docs.nextcloud.com/desktop/3.8/troubleshooting.html

Sounds a bit like your Raspberry is not taking it very well and the processes on the server crash (not enough memory)? Just a wild guess.
The client does parallel upload with 20 MB chunks, which creates more request, perhaps it is better to use larger chunks:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/big_file_upload_configuration.html#adjust-chunk-size-on-nextcloud-side

The files appeared to be transferred. I can’t say for sure that they transferred 100% successfully, but I think they were all there according to the web dashboard.

Like I said, I deleted all the files and then manually copied them in 1 at a time, so yes, one new file syncs.

My pi is a 4B. I assume that has enough resources. If not, nextcloud probably shouldn’t be supporting the pi platform. But I think that suggests the speculation that processes are crashing is not the case. I don’t have anything other than nextcloudpi running on there. Am I really expected to change obscure “chunk size” configuration to keep nextcloud from failing in a major way?

It sounds like this might not be a known bug and there’s no real explanation for this kind of behavior. Nextcloud should do its core purpose in rock solid fashion. It’s pretty disappointing that it doesn’t. It would be one thing if I had messed with stuff and screwed something up, but to have a pretty much straight out of the box experience like this?

The Pi4 is still a small device, and with a few users, or with some synchronous syncs you can easily saturate this device. It really depends on a use case. Also some apps can add an enormous load to it. For a somehow limited use-case it is an inexpensive and energy-efficient Nextcloud server. However wrong disk, no good power supply and bad settings can quickly degrade performance. NextcloudPi and the documentation around help you to avoid this.

And the pi4 is already a few years old, there are other small devices to run Nextcloud: What modern hardware do you recommend for NextcloudPi?

That would be interesting to know. In the logs, there can be hints if the transfer was interrupted or aborted.

Sure, but we need to know if they client just “forgot” to switch the symbol to green or if it never received the transfer confirmation. When you upload a file, you can check the webserver error log:

That would be for the query that uploads the file, e.g.


123.456.789.12 - - [09/May/2023:10:04:12 +0200] nc.example.org "PUT /remote.php/webdav/temp/del052023/TextFile.txt HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0" "-"

Here you got status code 201 for the PUT request to upload a file.

I’d try to upload more file, so it is failing again and check the webserver logs. Not sure what is happening then, you might be able to adjust the configuration to avoid this. And if the issue is known, report this to the desktop bug tracker that the client might be able to identify such a situation and reduce the parallel uploads.

Or other idea: get test account on try.nextcloud.com, add a sync client and upload a few files if you can reproduce. Then it is easy to report and reproduce the problem since it isn’t linked to your setup.

Like I said, this is a pretty much out-of-the-box experience, so I haven’t installed apps that might load my pi down, nor is anyone other than me using it at the moment because I wanted to get this reinstall solidified before anyone else uses it. So again, suggesting that my pi is to blame here doesn’t seem likely.

Whether the client “forgot” to switch the symbol (in which case doing another sync should correct that oversight IMO) or the sync failed in some other way is a little beside the point. The point is the system as a whole should be reliable for basic use cases, and my experience shows that it isn’t.

I’ll try a test folder when I get a chance and see if it happens again so I can follow some of your log related suggestions.

I would contest this is about Raspberry Pi not powerful enough.

Our nextcloud is being hosted on 78 core 1.5TB RAM and 200+TB SSD server with 12TB M.2 as main driver (Running on Linux).

My client is a dell laptop 12 cores, 32GB Ram, 1080Ti GPU, M.2 1TB as main drive and 4TB SSD as storage drives used for the nextcloud files…

Yet I have the same…

I synchronize successfully and the blue “Synchronizing” icon remains.

I experience the same - copying files one at a time solves the problem.

copying a bunch of the files - then I get this issue, sometimes, no clue when it would happen and when not. It just does.

It’s pretty random so I can’t say more about it, sadly…