Hi, I am using NC31.0.5 on a Proxmox Installation using an Debian LXC container. Today a user informed me that he cannot open any files.
I just checked his folder in the data folder, and there was only a subfolcer cache. The folders files, files_trashbin and files_versions are gone.
The data folder is stored on a QNAP NAS, so I checked the daily snapshots of saw that these folders are gone since a long time. I had a old version which is 4 weeks old, but there are only some files.
I then checked all my users and found another user where the files folders are gone.
My question is:
How can this happen???
For the 2nd user it was not recognitzed because the user is syncing all files to local windows installation so the files are existing in the windows ssd, but also in Nextcloud nothing is there.
I’m afraid that out-of-the-box noone would be able to help you since your problem seems to be complex (as complex as Nextcloud as a software is, in general).
It’s now turns out, that I lost files again, also files only 2 days old. for my luck the data was stored on a external QNAP device, so I was able to restore the missing files from a snapshot unfortunately, even if the files are now back in the Nextcloud folders next cloud is not gonna able to open it My next idea would be to search the database for all the stored files, check if the files are there, and restore a missing file then at last step, I would do a occ rescan files again. Does this behave makes sense?
Hi, I was now able to do a scan of the Files in the volume after rebooting in Maintenance Mode. No Problems, same as when running the Scan for bad sectors. Now I am separating the files into several Data Volumes, and will see if maybe here the problem is related.
As @JimmyKater stated, fill out the template. In the course of doing that, you’ll be reviewing your logs. May have some clues there.
My initial guess is that your data folder, which sounds like it is mounted from your QNAP NAS somehow (NFS? SMB? etc.) somehow got disconnected or went offline while Nextcloud was running.
Your OS logs (e.g. journalctl) may have some clues here too.