Oc_filecache mysql/mariadb crash issue and (maybe as a side effect?) corrupted encryption

Nextcloud version: 26.0.3
Operating system and version: OpenSUSE 15.5
Apache version: 2.4.51
PHP version: 8.0.29

Not sure if I made a mistake: I was getting somtimes but increasingly frequent mysql/mariadb crashes which always have been related to table oc_filecache.

Found this hint: ownCloud MySQL table “oc_filecache” corrupt, can I regenerate it? - Super User

I know, it’s for owncloud and pretty old, but as the table name is oc_fileCACHE it sounds reasonable for me that “server will rebuild” will happen for a Nextcloud and also now also :wink:

In fact, the mysql / mariadb issues are gone now, and occ files:scan -vvv shows that all seems to be fine. And oc_filecache contains row for each file after this occ command.

BUT:

Content of EXISTING files is “encrypted” garbage. MAYBE a side effect of this, posted today: Encryption mixup after installing, configuring and activating "eID-Login" app

Situation now is:

As I have tons of backups, I’ve tried to follow docs at Encryption configuration — Nextcloud latest Administration Manual latest documentation and restored for a single user (to test)

data/<user>/files_encryption

and, as this does NOT solve the issue, also

data/<user>/files

Also doesn’t help, in fact now I’m now, after restore getting a “File coould not be loaded. Please check your internet connection ” error combined with a “Connection failed, reconecting” popup msg.

Any hints, esp. as restore doesn’t help???

I’m confused. The subject is about database crashing issues, but you’re asking about encryption recovery/restore stuff. :slight_smile:

Looking at your other post, yes likely related. I linked to the doc section about encryption usage when using alternative user backends.

You’ve got a few layers of things to sort out I’m afraid.

This might also turn out to be useful depending on which direction things go in:

Thanks for answering!!!

Tried your mentioned encryption-recovery-tool for some “weird” folders, sometimes even - as strange as it may sound - files are showing (wrong) content of other files ex. inside Nextcloud.

However, your mentioned scripts works GREAT, all folders and files tested are decrypted perfectly!

Left question for me is how to process finally, to solve my issue completely:

AFAI understand the recover.php’s usage readme about <targetdir>

target directory has to already exist and should be empty as already-existing files will be skipped,

means that I SHOULD NOT (or MUST NOT?) specify <targetdir> the same as <sourcedir>, correct?

(Would mean that I’ve at first create a <targetdir> large enough to hold all decrypted files. And there are gigabytes of them, mainly photos and videos synched for years from several of my family’s smartphones via Nextcloud’s mobile apps…)

If so, <targetdir> != <sourcedir>, my second question would be how to get the decrypted files back to their designated (original) location. As all is server side, DATADIRECTORY and <targetdir>, what would the prefered way to “restore” the decrypted files, overwritng the current whyever “corrupted” stuff? AFAIK I also should NOT move anything into DATADIRECTORY at the OS level?

Last question: AFAI understood Nexcloud’s “Encryption configuration” docs, in my case (VPS with full root access bv myself) usage of server side encryption for “home storage” didn’t made any sense. Haven’t been aware of these before. To get rid of it, in context of recovery, when could/should I DISABLE the “Encrypt the home storage” option?

Good luck I’ve had enough disk space on my VPS to recover everything via GitHub - nextcloud/encryption-recovery-tools: This project contains a tool to recover files that have been encrypted with the Nextcloud Server-Side Encryption..

Worked PERFECTLY, great and very helpful utility, kudos and many thanks to the authors and thanks to @jtr (Josh) for pointing me into this direction!!!

Tested for a user with just a few files:

  • replaced DATADIRECTORY/<user>/files
  • and DATADIRECTORY/<user>/files_versions

with the recovered folders, and performed an

occ files:scan <user>  -vvv 

afterwards.

ALL FINE.

Having done this now for all users, not that many but many files and folders, ~75GB, and having done an

occ encryption:disable    -vvv 

and applying these settings in admin webgui ** BEFORE ** the recovery:

I can confirm now, that new files are NOT encrypted anymore on server.


Last open question for me:

Would it be fine now to DELETE RECURSIVELY all left over DATADIRECTORY/<user>/files_encryption folders?
Or any reasons to keep them?


1 Like

@michaelof I’m happy that my script helped you. If you properly decrypted all files then you can get rid of the files_encryption folders.