Operating system and version (e.g., Ubuntu 24.04):
Debian 12.12
Web server and version (e.g, Apache 2.4.25):
Apache2 2.4.65
Reverse proxy and version _(e.g. nginx 1.27.2)
none
PHP version (e.g, 8.3):
8.3.23
Is this the first time you’ve seen this error? (Yes / No):
Problem since some time, failing to solve it!
When did this problem seem to first start?
temporarily enabled encryption
Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
NCP
Are you using CloudfIare, mod_security, or similar? (Yes / No)
No
Summary of the issue you are facing:
I once enabled ‘encryption’ in NC, tried it for some time, then disabled it again.
I then found out, that I have 1500 encrypted files which I cannot access anymore.
Somehow, for some time, I managed to live without these files and I had few time to search for a solution.
I did first tries to recover the files with https://github.com/syseleven/nextcloud-tools/blob/master/rescue/decrypt-all-files.php made by yahesh (?).
But I have no idea what’s going on in that script.
I have config.php with passwordsalt, secret and intanceID.
I have the encrypted files in directories like
…/ncdata/user/files/path_in_NC/filename
I have also have
…/ncdata/user/files_encryption/keys/files/path_in_NC/filename/OC_DEFAULT_MODULE/master_.shareKey
and …/filekey - but ‘filekey’ not for all files!
I edited in decrypt-all-files.php: DATADIRECTORY, INSTANCEID, SECRET.
Do I need to put passwordsalt somewhere?
When I apply the script then, I get the following error:
PHP Warning: scandir( …/ncdata/user/files_encryption/OC_DEFAULT_MODULE/): Failed to open directory: No such file or directory in …/decrypt-all-files.php on line 559
PHP Warning: scandir(): (errno 2): No such file or directory in …/decrypt-all-files.php on line 559
PHP Warning: foreach() argument must be of type array|object, false given in …/decrypt-all-files.php on line 560
ERROR: COULD NOT DECRYPT ANY PRIVATE KEY
Obviously, the script requires a different directory structure under …/files_encryption/… for the key files!
Anyone with some experience on this around?
Any hint is welcome!
you are not completely wrong but if you spend a moment looking at the Github repo you will see
ARCHIVED: This original repository has been archived and is unmaintained. Please find the maintained fork of the original maintainer at nextcloud/encryption-recovery-tools.
going further you find detailed decryption guides for both encryption-server and encryption-e2e guides. Please follow the readme and show the logs if you hit issues.
The (maintained version) of the recovery tools should work for you.
It sounds like perhaps you disabled the encryption module app prior to running a occ encryption:decrypt-all perhaps? Another solution may be re-enabling the encryption app and re-attempting an occ encryption:decrypt-all.
many thanks for these answers and the included hints!!!
Oh, I didn’t see that the script is outdated. I will try to understand the read me - again…
Yes, I did not try it in that sequence (with occ encryption:decrypt-all while encryption was still active). And I was not aware that I would need the full Datadirectory for the scripts. I thought I could apply it to single files somehow - that’s obviously a major point I missed in the readme.
I fear I am far deeper in that mess, than You can imagine… - Full story: That incident is already some time ago, around middle 2023. As far as I remember, my server broke down. I had to set it up again from scratch. And I didn’t manage to restore the backup (files with db) into the new server instance. Instead I had to add all user files in the files system and then had them scanned into the database.
Much later I noticed that encryption must have been active in the old instance and some files from the backup were encrypted.
I will check, if I can still find the correct full DATADIRECTORY-backup. Then - maybe - I will come back with ‘How can I use those php-scripts on such an external DATADIRECTORY’…
At least - in the meantime - I managed to reduce the losses out of other old backups from 1300 to 400 files! And the losses don’t seam to be really harmful…
Adding the files back into the system instead of restoring the DB probably did a whole lot of damage. First, the versions of the files are kept in the DB and are needed for the integrity check of encrypted files (thankfully the recovery tools ignore integrity errors for that reason). Second, it could be that on the new setup you either didn’t re-enable the encryption or it could be that when enabling the encryption on the new setup, a second pair of encryption keys got created. So there could be quite a bit to untangle.