Suddenly OC deleted everything!

[Spire9]

Description

Major data loss.

User Stories

I installed and tested OpenCloud a few days ago, and everything went well. I tested with some non-critical files for a few days, and it worked well enough. Sometimes I had to log-out and log-in to fix an authentication error, but it seemed related to large-ish folders being added that took over 5 minutes to transfer over wifi. Then today I dropped a folder called "personal" in, and it locked up. I couldn't get it going with the log-out log-in trick, so I did a stop and start in Docker. I cleared Jetstream while it was stopped as I had before to fix such issues. This time when the sync resumed, it started deleting EVERYTHING from my PC. I tried to "quit" in a panic, but it was non-responsive for many seconds and the damage seems to be it wiped MOST of all my files from random locations, even the ones that synced correctly before. It seems adding a folder called "personal" to OpenCloud confuses it, and blows everything up. I still see many of the deleted files on the server, but they refuse to sync back. Unfortunately it deleted the files from my PC that were not synced yet too. I do keep as many backups as I can afford at today's storage prices, but my most recent and important files are hit and miss. And this WAS me taking a new backup. I'm stressed AF!
Edit: To clarify, I had thousands of critical files in a folder called "Workbench" that previously synced correctly. Now it is completely empty now. No signs of my files remain.

Value

Serious bug exists, likely related to syncing a folder called "Personal" directly into the "Personal" folder of OpenCloud.

[bxtcns4tdp-art]

What's your setup? opencloud version, host setup, etc?

And to be clear, it deleted files from your data directory? Or outside the data directory too?

[Spire9]

The server is the latest debian and fully up to date. the Docker pull for OpenCloud was initially done 13 days ago. A few days ago I went through the motions to update it, i don't recall if it changed anything. The Windows 10 app was downloaded 13 days ago from the Store, it doesn't tell versions.
It savaged the user files in the sync folder.
I have been dropping folders in the directory one at a time because there seems to be a bug if the sync takes longer than 5 minutes. Perhaps OIDC token expires? And when it does, it seems to corrupt Jetstream and send the server into high CPU loop that never ends. At least not until you do:

Client logout.
Client login.
Server:
cd /opt/docker
docker stop opencloud
rm -rf /mnt/samsung/opencloud/data/nats/jetstream
docker start opencloud

Then everything resumes. I've had to do it a dozen times, it's just what happens to OpenCloud if the sync is not done in 5 minutes or less.
I imagine what happened this time was the client screamed back to life after the logout/login and I didn't notice, and proceeded with the jetsream reset as it was operating. Normally it stays crashed until Jetstream is reset.

[Spire9]

I've added "OCIS_ACCESS_TOKEN_TTL=3600" to my docker compose in hopes of preventing this disaster again. But I will not be intentionally testing it.

[micbar]

Can you reproduce that on demo.opencloud.eu

Just to make it clear: there is no code in openCloud which deletes stuff on the server.

So it seems to me that you somehow swapped your personal space with an empty folder and the desktop client started to delete stuff because the server space has been empty. I wonder how this can be done without tampering with the storage directly. Weird. This needs more info and a clear reproducer.

Back to the problem: the original Space and all its files should still be on the server. Please check the storage.

[Spire9]

Nothing was deleted from the server side to my knowledge. It was ALL deleted from my PC, which included many not-yet-uploaded files. I dropped a large folder in, it synced 5-minutes worth, then crashed with an authentication error. After intervention, it came back online, but in a corrupt state and started destroying everything on the PC. Which I will say again, included MANY files that were waiting to sync to the server for backup!.
This has nothing to do with the Spaces.
Please go talk to Claude AI about this issue, it explains very well how this is well understood problem with OpenCloud and OwnCloud if your sync needs more than 5 minutes to complete, because 5 minutes is the default OIDC token lifetime.
The "fix" I see is to take control of the lifetime of the Access Token like I did in my previous post.
As for me demonstrating this by connecting my PC to your demo site, sorry, no. That's why this is a Story and not a Bug Report. My PC is not available for testing.
I will need to pull the drive from cold storage and see what can be recovered, that's where I will be spending my time. :(

[micbar]

I disagree with that analysis. The access token has nothing to do with that. Claude is just guessing.

All openCloud clients do token refresh.

Please try to do the same on demo.opencloud.eu

[Spire9]

This clearly needs to ON by default:

[Spire9]

@micbar So it seems overwrites and conflicts happen every time Windows wakes from sleep.
With advanced logs turned on I can see it's getting a little excited about Windows Search Indexer touching the file, but I'm not sure why it's trying to consider the server authoritative. The sync was absolutely full and successful before the PC was put to sleep.

[micbar]

Thanks for reporting back.

I need to mention our client experts @dragotin and @TheOneRing

[dragotin]

Can you share the "advanced logs"? That would be helpful to understand the problem.