After having forcefully worked without a Nextcloud server for the past few weeks (had to shut it down because my files were getting massively deleted all of the sudden), I finally got around to installing ProxMox on a spare machine, fire up an Ubuntu 18.04 LXC instance and install Nextcloud via the awesome installation script (https://docs.hanssonit.se/s/bj0vl1ihv0jgrmfm08j0/build-your-own/d/bj0vl4ahv0jgrmfm0950/nextcloud-vm). All fine.
Then I re-created my personal Nextcloud account on the server (without copying previous data) and re-connected the Nextcloud client on my laptop.
I was hoping the 25+ GB stored on my laptop would then be synced back to the server, but the process stopped after about 2 minutes, with a lot of strange errors showing in the Nextloud client:
“Conflict - Server version downloaded, local copy renamed and not uploaded.”
This message repeated dozens of times on many different files.
Since this is a freshly installed server without any of my files, how can there be server versions of those files?
Then I checked the Nextcloud folder on my laptop, which held 25+ GB of data before the sync.
Shockingly, the folder now just contains only 1.9 GB of data…
So just as I experienced with the previous server (running Nextcloud Pi), my files are being massively deleted by the Nextcloud client for some reason.
As I’m writing this, I’m figuring not the server, but the client could be the culprit, but how do I know? And how do I debug this?
- Ubuntu 18.04.3 64bit
- Nextcloud client ‘2.6.4git.’
- ProxMox 6.1-7.
- Ubuntu 18.04.3 64 bit installed in an LXC container
- Nextcloud 18.0.3 installed from script as mentioned above.
Shut down the laptop and do not use the hard drive. There is various recovery software online - use one of them to recover the deleted data.
Likely the client started to sync with the new server. IIRC nextcloud works by syncing the server with the client. So if the data doesnt exist on the server it deletes it on the client.
That’s my understanding anyway.
Well fortunately, I made a copy of the local Nextcloud folder before starting the sync, so I have a backup
But if what you’re saying is true, then this is new behavior. I’ve used Nextcloud for several years and I have never seen Nextcloud behave like this before. And how come about 1.9 GB of my data (which was also not present on the server) was in fact successfully synced?
I don’t know. I’ve had nextcloud delete data on my devices when it doesn’t exist on the server backend.
Theres a reason I don’t use the nextcloud client or any sync client for that matter. I simply don’t trust them to keep my data.
Nothing is in the logs that would indicate someone breached your server or laptop, right?
A system breach… Oh dear that would be terrible. Of course that’s something I cannot rule out, but I have no idea how to find out if it there has been a breach.
This is what I checked on the Nextcloud Pi server when I was trying to get to the bottom of the issue: NextcloudPi 'spontaneously' deleting files
If it wasn’t the server, but my laptop that was compromised, it happened many, many weeks back. How would I know? I haven’t noticed anything out of the ordinary, except the mentioned Nextcloud behavior.
In all honesty - I believe a bug, hardware failure or bad config are much more likely than a system breach, but I’m more than willing to be proven wrong.
What do the logs show?
I’d chalk it up to a security breach over software bug but nothing can be ruled out without logs.
Assuming you mean the logs on my laptop - they show a massive amount of things, I have no idea what to look for. Is there a recommended way to get any meaningful / important information out of all the ‘noise’? Tools I should use?
If the system was in fact breached, it happened before (or on) Februari 21, the day the issues started with the previous server.
And when I look at the files in /var/log/, ‘auth.log’ only goes back to March 10, and that’s auth.log.4.gz, the last auth.log file in there.
In fact, most logs don’t go back any further than March.
What I did notice, is that /var/log/apt/term.log.2.gz shows the Nextcloud client was updated (to 2.6.3) on February 22, after the issues started. The update before that seems to have been on December 27, 2019 (to version 2.6.2). So that kind of rules out a bug introduced with a new version. Unless the timestamps are a day off and this behavior was introduced with 2.6.3