Nextcloud desktop removed all files from server #1433
Comments
|
This just happened to me AGAIN. It started removing everything in one subfolder and then crashed after removing a few thousand files from it. I have a complete (non debug) log of this process in the client. The first line that starts the delete is this: Since the log file contains tons of private file names, I can't easily upload it here unfortunately. |
|
This just happened to me a THIRD time within one week. It removed ALL the files from the server and crashed syncing the changes down. I've disabled the client for now, as it's simply running amok on my files. I have a log file for this incident and the previous comment's incident of partial deletion that I'm happy to answer questions with. |
|
Hi @rbu , really sorry for your experience with the client. However, to find the root cause for this it´s absolutely crucial to be able to reproduce this over here (if I just set up the client on my standard fedora box, connect it to my fresh NC16 docker instance with a user having a random tree of online folders nothing unexpected happens). I understand you do not want to expose file names by posting a complete log. Few things though:
|
|
Hey @DominiqueFuchs, thanks for the response. Regarding the log, if you have specific questions regarding the log or a way to share it privately with an individual, I could do that.
Edit: I'd like to add one thing that I found odd. I remember seeing error messages about "too many open files" (in red, part of the sync status bar) before/during one of these incidents happening. I wasn't sure if it's too many network connections, open files or maybe it failed to set up inotify listeners? Note that my client system allows a large number of inotify listeners: I saw the first incident maybe 3 days after upgrading the fedora package from 2.5.2-1.fc30 to 2.5.3-1.fc30. I have since my last comment downgraded to 2.5.2-1.fc30 and haven't seen this problem again. [1] List of enabled plugins
|
|
This has not happened in the 3 weeks since I downgraded from 2.5.3-1.fc30 to 2.5.2-1.fc30. I guess I'll just stay on that version for the foreseeable future 🤷♂️ |
|
I thought I'd give this another chance and BOOM... all files are gone... again, on 2.6.2. That's after about 2 weeks of usage. I restored and had another few days of it not deleting all files. |
|
Just wanted to say that this happened to me today, I caught the desktop client in the middle of deleting all files on the server INCLUDING files that I do not have locally but only on the server. The activity log shows no errors but lists a selection of files that were supposedly deleted . Thankfully I'm backing my server up regularly... Desktop client: 2.6.4 |
|
This also happened to me today. During the night while I was asleep all the files on my server were deleted. Server was also full because the files were also being re uploaded (thus in the main storage and trashbin) by the client that deleted the files from the server. Local files on that client appear to be ok. Local files on all other connected clients were deleted. I am in the process of cleaning this up and restoring from a server backup, but would really like to figure out how to prevent this in the future as it has taken most of my day. Confirmed that it was the one client by looking in the servers access-logs xxx.xxx.xxx.xxx - Bun-Bun [14/Mar/2020:04:19:16 -0600] "DELETE /remote.php/dav/files/Bun-Bun/wallpapers HTTP/1.1" 204 - "-" "Mozilla/5.0 (Windows) mirall/2.6.2stable-Win64 (build 20191224) (Nextcloud)" I only have one client of that version installed on my home IP. One of those lines for each of the items in the root of my nextcloud folder. Server OS: Centos 7 |
|
The samen happened to me today. Has someone found a solution to solve this? Ik would like to use Nextcloud again, but with such as risk of loosing data this is not possible. |
|
My solution was to install Nextcloud-2.3.3.1 client and configure it to not check for updates. That is the last version of the client before they started screwing everything up with it. |
|
Happened to me again today. 2020-04-23T06:21:35.283574205Z 192.168.1.110 - skjnldsv [23/Apr/2020:06:21:35 +0000] "DELETE /remote.php/dav/files/skjnldsv/Wallet HTTP/2.0" 204 0 "-" "Mozilla/5.0 (Linux) mirall/2.6.4git (Nextcloud)" "192.168.1.110"
2020-04-23T06:21:35.312710439Z 192.168.1.110 - skjnldsv [23/Apr/2020:06:21:35 +0000] "DELETE /remote.php/dav/files/skjnldsv/Wallpapers HTTP/2.0" 204 0 "-" "Mozilla/5.0 (Linux) mirall/2.6.4git (Nextcloud)" "192.168.1.110"
2020-04-23T06:21:35.365646789Z 192.168.1.110 - skjnldsv [23/Apr/2020:06:21:35 +0000] "DELETE /remote.php/dav/files/skjnldsv/Ressources HTTP/2.0" 204 0 "-" "Mozilla/5.0 (Linux) mirall/2.6.4git (Nextcloud)" "192.168.1.110"
2020-04-23T06:21:35.707730232Z 192.168.1.110 - skjnldsv [23/Apr/2020:06:21:35 +0000] "DELETE /remote.php/dav/files/skjnldsv/Recipes HTTP/2.0" 204 0 "-" "Mozilla/5.0 (Linux) mirall/2.6.4git (Nextcloud)" "192.168.1.110"
2020-04-23T06:21:36.191836604Z 192.168.1.110 - skjnldsv [23/Apr/2020:06:21:36 +0000] "DELETE /remote.php/dav/files/skjnldsv/Projets HTTP/2.0" 204 0 "-" "Mozilla/5.0 (Linux) mirall/2.6.4git (Nextcloud)" "192.168.1.110"
... etc etc |
This comment has been minimized.
This comment has been minimized.
|
Client logs 2.6.4git #=#=#=#=# Propagation starts 2020-04-23T06:20:32Z (last step: 473 msec, total: 473 msec)
06:20:33||pomodoro.md|INST_SYNC|Up|1587622830|57fae5758e5e15cdfb1f348a4b29a934|1595|00332907ocwwisqscdyi|4||204|1584|1587573309||||
#=#=#=# Syncrun finished 2020-04-23T06:20:33Z (last step: 622 msec, total: 1096 msec)
#=#=#=# Syncrun started 2020-04-23T06:21:32Z
#=#=#=#=# Propagation starts 2020-04-23T06:21:33Z (last step: 580 msec, total: 580 msec)
06:21:35||Wallet|INST_REMOVE|Up|1573118819|5dc3e3646e02c|0|00332902ocwwisqscdyi|4||204|0|0||||
06:21:35||Wallpapers|INST_REMOVE|Up|1573118964|5dc3e3f507b1f|0|00332904ocwwisqscdyi|4||204|0|0||||
06:21:35||Ressources|INST_REMOVE|Up|1586679129|5e92cd5944383|0|00245943ocwwisqscdyi|4||204|0|0||||
06:21:35||Recipes|INST_REMOVE|Up|1584547518|5e7246be0dffc|0|00372370ocwwisqscdyi|4||204|0|0||||
06:21:36||Projets|INST_REMOVE|Up|1573054036|5dc2e6555e104|0|00332782ocwwisqscdyi|4||204|0|0||||
06:21:36||ReactionGIFs|INST_REMOVE|Up|1586865570|5e95a5a2c15c5|0|00000165ocwwisqscdyi|4|Fichiers locaux et dossier partagé supprimés.|204|0|0||||
06:21:37||Notes|INST_REMOVE|Up|1585258126|5e7d1e9057409|0|00332779ocwwisqscdyi|4||204|0|0||||
06:21:37||Nextcloud|INST_REMOVE|Up|1579014247|5e1dd8680db6b|0|00332778ocwwisqscdyi|4||204|0|0||||
06:21:40||Photos|INST_REMOVE|Up|1584917324|5e77eb4c8122e|0|00332781ocwwisqscdyi|4||204|0|0||||
06:21:41||Images|INST_REMOVE|Up|1583069799|5e5bba6853237|0|00332777ocwwisqscdyi|4||204|0|0||||
06:21:42||Public|INST_REMOVE|Up|1587370555|5e9d5a3bdc9a8|0|00000180ocwwisqscdyi|4||204|0|0||||
06:21:43||Configs|INST_REMOVE|Up|1575530921|5de8b1aa00dc1|0|00332775ocwwisqscdyi|4||204|0|0||||
06:21:43||.Contacts-Backup|INST_REMOVE|Up|1587590604|5ea0b5ccbc5d0|0|00332774ocwwisqscdyi|4||204|0|0||||
06:21:46||emotionwheel.jpg|INST_REMOVE|Up|1577364107|d9ff8ef482f16a83c2f6ea0bd24c7344|317176|00363513ocwwisqscdyi|4||204|0|0||||
06:21:46||Documents|INST_REMOVE|Up|1586158591|5e8adbff18cb1|0|00332776ocwwisqscdyi|4||204|0|0||||
06:21:49||pomodoro.md|INST_REMOVE|Up|1587622830|57fae5758e5e15cdfb1f348a4b29a934|1595|00332907ocwwisqscdyi|4||204|0|0||||
06:21:51||InstantUpload|INST_REMOVE|Up|1587585809|5ea0a311dee9d|0|00332780ocwwisqscdyi|4||204|0|0||||
#=#=#=# Syncrun finished 2020-04-23T06:21:51Z (last step: 18518 msec, total: 19098 msec)
#=#=#=# Syncrun started 2020-04-23T06:22:32Z
#=#=#=#=# Propagation starts 2020-04-23T06:22:32Z (last step: 68 msec, total: 68 msec)
#=#=#=# Syncrun finished 2020-04-23T06:22:32Z (last step: 14 msec, total: 82 msec)
#=#=#=# Syncrun started 2020-04-23T07:20:33Z
#=#=#=#=# Propagation starts 2020-04-23T07:20:33Z (last step: 575 msec, total: 575 msec)
07:20:34||Configs|INST_NEW|Up|1575530918||4096|00381832ocwwisqscdyi|4||201|0|0||||
07:20:34||.Contacts-Backup|INST_NEW|Up|1587590615||12288|00381831ocwwisqscdyi|4||201|0|0||||
07:20:34||Images|INST_NEW|Up|1583069797||4096|00381833ocwwisqscdyi|4||201|0|0||||
07:20:34||Documents|INST_NEW|Up|1583938302||4096|00381834ocwwisqscdyi|4||201|0|0||||
07:20:34||InstantUpload|INST_NEW|Up|1578297635||135168|00381835ocwwisqscdyi|4||201|0|0||||
07:20:34||Nextcloud|INST_NEW|Up|1579014255||4096|00381836ocwwisqscdyi|4||201|0|0|||| |
|
Just after moving all my files to the trashbin, the client started syncing again all my files to the server. Hope that helps! |
|
|
Thanks @skjnldsv for providing the log snippets ands answering the questions above! That helps a lot trying to reproduce this. Based on the impact of this issue (extreme) and the comparatively low number of reports (4 people in this thread) there seems to be a pretty specific but exotic condition going on. |
|
@skjnldsv Could you elaborate on the thing regarding the trashbin please? Not sure if I got your description right there. Do you mean the unintentionally/suddenly deleted files are synced back again after you put the local copies in the trash bin on your client side? |
|
Sure, obervations are as follow:
|
Same scenario on my case. The bad client sent delete requests to the server, which moved everything to the NC trashbin, and then the bad client immediately started reuploading all the files back to the server. Which in my case caused it to fill up and stop working. Locally to the bad client the files were unchanged. |
|
In my case the files were gone on both server and client. Even in the nextcloud trash or the client trash (windows) were no files. So I think that in my case the client started removing files from the computer and this propagated to the server who also started removing the files. |
|
@Bun-Bun linux too? |
|
As my post earlier said Server OS: Centos 7 |
This comment has been minimized.
This comment has been minimized.
|
Maybe this is related. I had a 14GB folder with misc files that I yesterday:
Today I discovered that the folder was empty on all clients. I did not find anything on the server in trash. I got desperate and now I'm restoring a backup that I fortunately did the 24th. And just now I found that there was a restore button on the delete activity in the server that maybe could have fixed it even though I did not find the folders in the trash. Anyhow, maybe this can be used for reproducing the issue. The client was "Version 2.6.2stable-Win64 (build 20191224)" and Nextcloud 17.0.2 running in a docker container on Fedora 30. |
|
Please affected people can you make sure you upgrade to the latest release (3.3.3 at the moment). |
|
Been a while since that happened yep 🤔 |
|
I solved my problem by not nextcloud anymore. Besides "most probably" would not be reassuring enough to actually risk provoking this bug in anything else than a development environment. |
|
I just had something very much like this happen this morning. Running NC 23.0.0 on CentOS 7 and using the most recent (I believe, I always allow it to update whenever it asks though I have since uninstalled it because of this issue) Windows client. I actually hadn't been doing anything actively with it. Another user was moving folders from one shared folder to another, and later noted that it was empty a while after the move. Looking in the apache log file I see a large number of DELETE commands issued from me to the new location. I wasn't even aware of that user doing the work, and hadn't been doing anything to explicitly interact with NC except through a browser, but apparently my client thought that the empty directory was somehow the "right" one and I suppose tried to bring the NC server into sync with its emptiness. |
What version of desktop client are you using? |
I had kept it up dated any time it asked to, so I presume it was the latest. I have since removed it though since I can't have it deleting files other people create like that. Sorry I can't provide any additional detail, but it happened to me and one other person in the company who had the windows app installed. Each of us has removed the app after it deleted a number of files that had been created by a third person, and then she had moved them using the web interface from one folder to another. It seemed it was after that happened that our Windows machines decided those files should not be in the new location and issued http DELETE messages to remove them. |
|
I've seen this happen before, but always in combination with long file paths. My guess is that this might be an issue with long file paths in Windows:
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd When you rename a folder with files or subfolders inside, it is possible to create files with a path longer then the allowed 260 characters. My guess is: When that happens, nextcloud client syncs these files to the server. Then on the next sync the other client fails to create these files due to the path length limitation. One sync later this client sees these files aren't there locally, assumes they were deleted and deletes them from the server. |
|
Ah, that's a really interesting thought. I don't think that's likely it quite here though. I just checked and the directory containing some of the files that were deleted has 60 characters in the path to it. Of course, there were some characters for the local part of the path where I had it mounted and the name of the files within, but I don't think in general those would be around 200 characters more, certainly not for every file that was removed. I grabbed one of the commands from the apache log here, and I'm replacing some potentially sensitive names with an equal number of X characters:
Would it be likely to increase the chance of confusion if the path were shared multiple times, as seems to happen when a parent and one of its child folders are both shared with another user? For example, we have a folder for "ongoing efforts" and a different directory for each customer inside that. Many of those customer directories also got shared, as well as that "ongoing efforts" so everyone who isn't the original owner of the folder sees both "ongoing efforts" and, say, "customerA" in their top level of the Files app. If something happens in there, might the app see the move in one path, but not the other and try to clean it up or something like that? Like it gets the notification that a file at "ongoing efforts/customerA/subFolder1/file1.txt" was moved to "ongoing efforts/customerA/subFolder2/file1.txt" but then we also see the mysterious file at "customerA/subFolder2/file1.txt" and have no explanation for it so remove it? |
|
3.4.0 sadly had an issue which caused this, it is mostly related to a date problem with the client setting a wrong date when uploading files resulting in some confusion and then - file deletions. We fixed this and 3.4.1 should not do this. I think that this is what you bumped into, @erenouf |
|
I had pretty much the same behaviour as @luspi 's comment: |
|
@dots-git do you still have this issue with the latest 3.5.2 version? |
|
I had this happen to me recently. I have a mix of local and virtual files using the latest Desktop client. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@doodee123 |
|
Hi @allexzander |
|
I'm having this issue. 100's of GB deleted and missing. I finished syncing 1.2TB worth of files, as i migrated across from onedrive to nextcloud. Then a few days later, I noticed i was missing a number of files, and saw that the files were now sitting at around 200GB. I was using next cloud to sync all my files from my phone, 4 - 5 computers. This is a little devastating to say the least. It is consistently deleting the files. Running the latest nextcloud windows 10 client. 3.6.1 |
|
i have this problem too NCversion: 24.0.9.2 desktop: windows 10 client. 3.6.1 |
@sheggy-rin with that amount of users, wouldn't it be wise to start looking at professional Nextcloud support? Not that I want to marginalize the issue(s) of the Nextcloud Desktop software, but for an organization of the size you're mentioning I personally would not sleep well without it... |
|
@mgallien @allexzander so are people here still running into that same issue? If so, @tobiasKaminsky we should add it to planning? |
|
My client had a similar situation. A user's Nextcloud client (v3.8) deletes 5000 files in the Groups folder. I had to restore. However, the files do not automatically jump to the folder before being deleted, but instead jump to the root of the Group folder. I don't worry about the file being deleted abnormally, I just find the restore function of trashbin too bad. Restored files are not returned to the previous directory. |
|
This is happening to me right now. I'm downloading a lot of video files into the Nextcloud synced directory on a PC with a pretty full drive. The Nextcloud client pretty much constantly deletes files already uploaded to Nextcloud from the server without any input right in front of my eyes, sometimes with a "Conflict when uploading a file. It's going to get removed!" notification (though those might be because of automatically restarted downloads after the file gets deleted). I assume what's happening is Windows is trying to evict already uploaded local files to free up space and for some reason the Nextcloud client interprets that as "also delete those files from the server". Unfortunately they don't land in the deleted files for me... edit: original bug looks unrelated to VFS -- probably something else? |
|
v3.9.3 - still actual problem. |
|
I suspect those commenting after #1433 (comment) are not necessarily encountering the same matter this Issue was originally targeting. Though this issue was left open... so here we are. I'll leave this open for now since there is some recent history in it. However if you end up here, I would suggest you create a dedicated issue so that your individual situation can be evaluated alongside the details needed about your setup. This will facilitate reproduction necessary for resolution. |
and others
Expected behaviour
Nextcloud Desktop should not remove files from the server that are not gone from the machine.
Actual behaviour
Two days ago, Nextcloud desktop removed all my files from the server, including folders shared with others. It also removed myself from shares (to me) of others.
The files on the local system stayed intact. However, recovering from this took me significant amounts of time, sweat and conflict solving. Plus, all of the folder timestamps on the server are now gone.
Steps to reproduce
I hope I cannot reproduce this.
I'm seeing frequent crashes of the Nextcloud client. There's high memory usage that I attribute this to (#124), sometimes up to 1.5 GB of RAM when it's been running for a while.
Client configuration
Client version: 2.5.3
Operating system: Fedora 30
OS language: English
Qt version used by client package (Linux only, see also Settings dialog): 5.12.4
Client package (From Nextcloud or distro) (Linux only): nextcloud-client-2.5.3-1.fc30
Server configuration
Nextcloud version: 16.0.4.1
Logs
Access log:
The text was updated successfully, but these errors were encountered: