[NC 20+] Legacy encryption - mitigation and documentation thereof

[Kuphi]

With Nextcloud 20, the term "Legacy encryption" was introduced. The documentation does say little about what legacy encryption is: https://docs.nextcloud.com/server/20/admin_manual/configuration_files/encryption_migration.html I found another document, which gives hints about what could be meant: https://eprint.iacr.org/2020/1439.pdf

I run the command occ encryption:scan:legacy-format with output similar to this: sudo -u www-data php /var/www/nextcloud/occ encryption:scan:legacy-format Scanning all files for legacy encryption Scanning all files for username /username/files_trashbin/files/file1.odt.d1592989576 does not have a proper header /username/files_trashbin/versions/folder1/file2.xls.v1585723230 does not have a proper header /username/files_versions/folder2/file3.xls.v1189677150 does not have a proper header

Now I got some files with inproper headers. Does my nextcloud still use legacy encryption for all files or does it use a more secure encryption? What are the differences?

When running occ encryption I also encountered a new command: Command "encryption" is not defined. Did you mean one of these? encryption:change-key-storage-root encryption:decrypt-all encryption:disable encryption:disable-master-key encryption:enable encryption:enable-master-key encryption:encrypt-all encryption:list-modules encryption:migrate-key-storage-format encryption:recover-user encryption:scan:legacy-format encryption:set-default-module encryption:show-key-storage-root encryption:status

There is no documentation about encryption:migrate-key-storage-format but an excerpt from the file /nextcloud/core/Command/Encryption/MigrateKeyStorage.php - https://fossies.org/linux/nextcloud/core/Command/Encryption/MigrateKeyStorage.php 75 ->setName('encryption:migrate-key-storage-format') 76 ->setDescription('Migrate the format of the keystorage to a newer format')

Am I supposed to use this command? I have key-type: user keys ( https://docs.nextcloud.com/server/20/admin_manual/configuration_files/encryption_details.html#key-type-user-key ) Will I still be able to use user keys after running this command, and is it save to run it?

My feature request is: please answer this questions and update the documentation of nextcloud. Thank you very much for maintaining nextcloud! :)

[yahesh]

@DPTJKKVH You could try to to var_dump($path); var_dump($content); after line 184 to find out which file path causes this problem and then see whether the corresponding file exists and is readable the system user that is used to migrate the keys.

[DPTJKKVH]

@yahesh Currently in the process of migrating the key storage format. Thanks to your suggestion I am able to see what files are causing issues but not why they cause issues. The stack trace for when an error occurs is identical to what we had before.

I'm currently running the migration command, wait for an error, let the user move out the files causing trouble, empty the trash bin and then re-run the migration command. I will repeat this process until it succeeds. Then I will report back. :)

[DPTJKKVH]

@yahesh Many thanks for all the support you are providing! I have some good news and some bad news:

Good:

• After many iterations of the above described procedure the command ran through successfully. The encryption.key_storage_migrated entry in my config.php was automatically removed.
• I re-ran the encryption:scan:legacy-format command successfully and removed the corresponding entry in my config.php as well, effectively disabling legacy encryption. Then I restarted the apache2 process.
• None of the users gets an error message about their private key when they log in. So the migration seems to have indeed succeeded.
• Most of the files work properly. So they can be downloaded and opened fine.

Bad:

• Some files are broken. I was able to identify two kinds of errors:
• Missing signature -> Results in an "File not available" error.
• _Encryption not ready: multikeydecrypt with share key failed:error:REDACTED_POSSIBLE_KEY_ID:rsa routines:RSA_padding_check_PKCS1_type2:pkcs decoding error -> Results in an "Internal Server Error".

None of the affected files are shared, so the second error is especially confusing.

I log Nextcloud errors to syslog so here are the corresponding error messages from the syslog as gists:

Signature Error

Multi Key Decrypt Error

One additional question: As you can see I had to redact a private key that was written to syslog when the second error occurred. That sounds rather dangerous to me. You don't have to explain it to me but I wanted to notify you of this because you are able to determine if that is a security issue which should be reported.

[DPTJKKVH]

@yahesh I figured that you won't be able to help me with the remaining issues (signature and multikeydecrypt) and with some testing I noticed that I can simply remove the "broken" files and reupload them to fix my remaining issues.

However, please do look at the logs about the Multi Key Decrypt Error since I am certain that private keys should never be written to a log file. I trust you can determine if this is something that should be reported as a security vulnerability.

[yahesh]

@DPTJKKVH I had a look at the Gist and the place where the private key is written to the logfile seems to be in Crypt.php#L683. The error logging seems to be so generic that it also outputs arguments while, in this case, it leads to a security vulnerability as the plaintext private key used to the decrypt the files is printed to logfile as well. IMHO this should definitely be reported to the maintainers as a security vulnerability.

There are more occurences where a thrown exception might lead to leaked secret information, e.g. in Crypt.php#L505, Crypt.php#L617 and Crypt.php#L677.

[DPTJKKVH]

@yahesh I feel really bad to ask this from you after you helped me so much already but would you like to report this security issue to Nextcloud? I don't know how I would go about to properly report such an issue other than pointing to our conversation here. You on the other hand have already identified multiple additional instances where such an issue could occur as well. (I am not interested in any credit or bounty or anything. I consider this security vulnerability as found by you alone. I am just some person who stumbled over something.)

The fact that private keys can be exposed by such trivial means is extremely scary. I guess this is an inherent problem when encryption happens server side instead of client side? However the least that should be done is limiting default error logging in a way that confidential information is not exposed.

It's kind of ironic that the Signature error log does contain instances of *** sensitive parameter replaced ***. Those are not done by me manually but by Nextcloud automatically...

[Alvarord]

Hello,

just to leave it written, the encrypt-all finish without error now that I tracked the exception with a var_dump(path) in front of:

https://github.com/nextcloud/server/blob/3cb8d85cf475061bcfbe6d901a9b9a0c29258ab4/lib/private/Encryption/Keys/Storage.php#L287)

First it finish always with an error:

In Storage.php line 287:

  Could not decrypt key

In Crypto.php line 122:

  Authenticated ciphertext could not be decoded.

It happened with a shared folder with just more folder in it and no files. So seems nextcloud was expecting data inside. I have removed the folder and the encrypt-all finish properly without exception BUT (and it is a big one) it still keeps encrypting not all files and each time I execute it is choosing a different subset of files.

I will try to check how the subset is chosen, at this time i'm trying to understand this part:

https://github.com/nextcloud/server/blob/3cb8d85cf475061bcfbe6d901a9b9a0c29258ab4/apps/encryption/lib/Crypto/EncryptAll.php#L264

There is where the loop cipher all files happens but I don't understand why it finish early in my case, I can see the $directories has a lot of objects with a var_dump but there is not the same amount of messages with the encrypt files and there is no log with files already encrypted neither.

Im not sure how to track this any further as from my point of view the code is totally correct but is strange that the loop for cphering the user finish early but I can see content in the directories and even I see a lot of files added so the getDirecrotyContent seems to be working properly too. It doesnt make any sense.

----- EDIT here

I have seen what is happening the progress is not showing all the files and seems ALL the files are encrypted:

I have put a trace here: https://github.com/nextcloud/server/blob/3cb8d85cf475061bcfbe6d901a9b9a0c29258ab4/apps/encryption/lib/Crypto/EncryptAll.php#L299

And seems all files are giving a true so they are encrypted but then I have a question:

Why if I deactivate the legacy encryption it fails? I have seen that the file I can't download if I deactivate the legacy is getting out through that line but then why it works when it is active and it stops working when not? I will keep searching an explanation.

[Alvarord]

Hello,

the issue with my file is exactly this one reported by @DPTJKKVH

Signature Error

So that seems definitively related to the issue #8546 with the 00sig00

[Cardes]

Hello,

first: thanks for all your helpfull comments here, those information helped me mitigate a lot of errors while migrating to the new encryption format. Sadly some obstacles still remain:

Maybe this is related and somewhat important if you are using the collabora online app (or try to use): The reason I'm writing this here is because it happens on files created via web interface after switching to the new encryption.

I get "Legacy cipher is no longer supported!" while using the collabora app for newly created files where everything else is working fine. Maybe its just not supported but it seems to mee the app is still somehow creating files with the old encryption format while everything else is using the new format. For reference: I migrated all users with password change in advance (coming from age old owncloud, migrated years ago to nextcloud), cleaned up the trash and versions files. I got no errors using scan:legacy-format & doing key-migration Users see no error message in the gui about invalid private key and can access their files just fine, create new ones and so on. I can reliably reproduce the behaviour with the collabora app which is just working fine on unencrypted, external storage shares using smb.

first variant with empty file

1. create an empty odt file in the users home folder or subfolder via web/files app "+"
2. access with collabora is fine and the file can be saved
3. reopen the file, edit some text and try to save: error is logged: "Legacy cipher is no longer supported!" and "Private Key missing for user: please try to log-out and log-in again" also showing an error in collabora collabora error as in: This Issue

second variant with template file

1. create a odt file from template
2. open the file in collabora and try to safe it: same errors as above

3. The difference between both situations seems to be that an empty file can be successfully written once while an existing file cannot be edited.

I realize I'm in a somewhat special situation where i use unencrypted, external storage via smb which just works fine and encrypted home folders for users where the error happens but I still whanted to create some awarness of this situation because I feel some people might too get stuck in a situation like me given that i could't find something in the documentation about the collabora app about encryption is unsupported.

[kaysond]

I'm curious if anyone has run into the problem where occ encryption:scan:legacy-format returns files/folders that no longer exist?

Then when I run occ encryption:migrate-key-storage-format, it crashes with the same message as in https://github.com/nextcloud/server/issues/24240#issuecomment-764703146 because the files don't exist.

It seems that $this->rootView->getDirectoryContent($folder) is traversing something that's not actually the directory structure on disk... Maybe there's some kind of structure I'm missing... I'm still working through the files to debug, but any tips would be appreciated!

[yahesh]

Might be that it takes the file list in the database as the basis for the file scan.

[kaysond]

@yahesh looks like you might be right. I turned off the db, and it errors out almost immediately, though its happening in OC::init, which may not necessarily be the code that traverses the directory. I'll open a separate issue for this

[eNTi]

I'm seeing the same issue. Getting lots of

does not have a proper header

messages for files. No idea what to do about it and how to proceed. Can I somehow resync the db so that it sees the correct files? And if so... what's next? Can I change the encryption for the files on the server for all users? So are they in effect getting decrypted and encrypted again? Is this dangerous?

Some guidance would be much appreciated!

[DPTJKKVH]

Hello everyone. Sad to see that the issue isn't even acknowledged by the devs yet. If it wasn't for Yahesh (🙏) I would be still stuck as well.

I don't have a nice solution for you guys but I can reiterate how I "fixed" the issue on my end.

Basically I undid all changes I made in trying to debug the issue. So I had a "vanilla" legacy encryption setup. Then I told every user of my server to locally backup their files and then delete everything stored on Nextcoud, including wiping the versions and trash bin. Then I migrated the key storage format and disabled legacy encryption. After that everyone had to reupload all of their files.

It was a painful process that took severals days but after that everything was well and still is well for months. I strongly suggest to go this route since I honestly exhausted every other possibility described here and beyond and none worked.

Only public shares do not work anymore and I guess that is caused by the new key storage format. It's annoying but after the trouble everyone went through we all decided to rather deal with it than risk breaking anything.

All in all this was an atrocious experience and I'm glad that nobody threw the towel and decided to sell out to Google or DropBox.

Best of luck!

[jknockaert]

Using NC encryption has been a pita for a long time now. The implementation has been a mess from the very beginning (even before NC forked from OC), and documentation has been largely absent or even misleading (remember #8311). I've been trying to keep it going, starting with reimplementing the encryption stream wrapper (the original one being terribly inefficient) and then later fixing errors here and there. New errors came with new versions of NC, often resulting from largely undocumented commits. PRs to fix them sometimes take several months after submission before receiving a review. Enough's been enough, so today I decided to go without encryption and I switched it off. I will no longer be available to review or fix any issues with respect to encryption in NC.

[szaimen]

@jknockaert That's comprehensible but of course sad to hear!

Enough's been enough, so today I decided to go without encryption and I switched it off

I wonder what you use instead? No encryption at all or e.g. FDE?

[jknockaert]

I wonder what you use instead? No encryption at all or e.g. FDE?

I started using ZFS native encryption.

[J0WI]

Unfortunately, FS encryption can't replace user key encryption.

[DPTJKKVH]

Guys please. I do share your frustration 100% but this issue is for debugging and supporting people to get through the migration process and not for discussing alternatives to the standard encryption module.

This issue is very crowded and you ping everyone with your private conversation.

[szaimen]

Off-Topic @J0WI

> Unfortunately, FS encryption can't replace user key encryption. I am not sure if it was actually ever meant to be really secure from the admins: Citing this doc https://github.com/nextcloud/desktop/blob/master/doc/architecture.rst#end-to-end-encryption: > While data on the server can be encrypted, this is largely designed to protect it from malicious storage solutions or theft of the whole hardware. System administrators always have access to the data.

[eNTi]

Not to be ungrateful but @DPTJKKVH is right. Can you move this conversation somewhere else please?

[jknockaert]

The fun thing is, even after disabling encryption (occ encryption:disable) I still get the message:

The old server-side-encryption format is enabled. We recommend disabling this. For more details see the documentation.

That's quite a bit off. And don't expect the documentation to help you any further; it rarely ever did when it comes to the encryption app.

[kaysond]

https://github.com/nextcloud/server/issues/24240#issuecomment-819264419 So the solution to this, in my case, was to run occ files:scan --all (requires maintenance mode being off). Then it ran with no issues!

[kaysond]

Followup - I'm now getting a lot of encryption-related errors like:

{"reqId":"vlJTJhWNMRpObwgx8h8i","level":3,"time":"2021-05-08T16:32:32+00:00","remoteAddr":"99.240.225.175","user":"samir","app":"PHP","method":"PUT","url":"/remote.php/dav/files/samir/Samir's%20Pictures/ControlCenter4/Scan/CHQ%20for%20Jack20210508.pdf","message":{"Exception":"Error","Message":"Undefined index: encryptedVersion at /var/www/nubcloud/lib/private/Files/Storage/Wrapper/Encryption.php#669","Code":0,"Trace":[{"file":"/var/www/nubcloud/lib/private/Files/Storage/Wrapper/Encryption.php","line":669,"function":"onError","class":"OC\\Log\\ErrorHandler","type":"::"},{"file":"/var/www/nubcloud/lib/private/Files/Storage/Wrapper/Encryption.php","line":767,"function":"updateEncryptedVersion","class":"OC\\Files\\Storage\\Wrapper\\Encryption","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nubcloud/lib/private/Files/Storage/Wrapper/Encryption.php","line":623,"function":"copyBetweenStorage","class":"OC\\Files\\Storage\\Wrapper\\Encryption","type":"->"},{"file":"/var/www/nubcloud/apps/files_trashbin/lib/Storage.php","line":240,"function":"moveFromStorage","class":"OC\\Files\\Storage\\Wrapper\\Encryption","type":"->"},{"file":"/var/www/nubcloud/apps/dav/lib/Connector/Sabre/File.php","line":292,"function":"moveFromStorage","class":"OCA\\Files_Trashbin\\Storage","type":"->"},{"file":"/var/www/nubcloud/apps/dav/lib/Connector/Sabre/Directory.php","line":156,"function":"put","class":"OCA\\DAV\\Connector\\Sabre\\File","type":"->"},{"file":"/var/www/nubcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":1098,"function":"createFile","class":"OCA\\DAV\\Connector\\Sabre\\Directory","type":"->"},{"file":"/var/www/nubcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":504,"function":"createFile","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nubcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpPut","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"/var/www/nubcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":472,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nubcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nubcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":321,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nubcloud/apps/dav/lib/Server.php","line":332,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nubcloud/apps/dav/appinfo/v2/remote.php","line":35,"function":"exec","class":"OCA\\DAV\\Server","type":"->"},{"file":"/var/www/nubcloud/remote.php","line":167,"args":["/var/www/nubcloud/apps/dav/appinfo/v2/remote.php"],"function":"require_once"}],"File":"/var/www/nubcloud/lib/private/Log/ErrorHandler.php","Line":92,"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (Windows) mirall/2.6.2stable-Win64 (build 20191224) (Nextcloud)","version":"21.0.1.1"}

after I ran the migration and disabled legacy encryption support.

Anyone have any ideas?

[DPTJKKVH]

@kaysond I don't think it's related to the issue at hand. I suddenly have gotten such errors as well, after the server ran more or less okay for a time. I set up a second server, 100% fresh via the Snap repository, no backup restore or anything. I enabled the encryption module uploaded some files, and there were the errors already.

This is where I gave up. We are on SeaFile now.

But again: I don't think it's related to the migration since the errors happen on a fresh install as well, right after enabling the default encryption module.

[kaysond]

@kaysond I don't think it's related to the issue at hand. I suddenly have gotten such errors as well, after the server ran more or less okay for a time. I set up a second server, 100% fresh via the Snap repository, no backup restore or anything. I enabled the encryption module uploaded some files, and there were the errors already.

This is where I gave up. We are on SeaFile now.

But again: I don't think it's related to the migration since the errors happen on a fresh install as well, right after enabling the default encryption module.

Thanks for the info. I wonder if it is just the upgrade to the new version that caused this.

[DPTJKKVH]

That's very much possible. To be honest now that you mentioned it, I think the issues did start shortly after a server update.

Do keep in mind that those issue mean that your files on the server one by one become unreadable/undecryptable due to those errors. At least that is how it was on my server. You can try to verify if you suffer the same fate by logging in via the web client, downloading some files and then trying to open them. In my case the file names were okay but the files themselves were all messed up. (Either still encrypted or corrupted. It's hard to tell the difference.)

Fortunately the files on the clients stayed unharmed, so we were able to fully recover everything.

Before someone chimes in: I'm not trying to shit on Nextcloud in any way. I'm actually still helping people because I do care. I was a big proponent of Nextcloud and I somewhat still am but the issues with the encryption module and the devs not even acknowledging it, forced me to quit to avoid data loss, after literal months of dreadful work. I know the devs owe me/us nothing for offering free open source software. So no hate, no hard feelings. Just helping people to avoid data loss.

[szaimen]

Maybe this comment shelds some lights on something here? https://github.com/nextcloud/server/issues/27501#issue-920474958

[ajs124]

In my case, the files are just plain unencrypted files, in the filesystem. Nextcloud however seems to think that they are encrypted. I've already run occ files:scan --all and so on, but encryption:scan:legacy-format still finds the same files.

I fixed this by deleting the folders and files relating to those files from files_encryption/keys, dropping the entries referencing them from the database and setting the encrypted field to 0 in the database. Then I ran files:scan --all again and now it seems to work. Idk if that helps anyone here.

[PVince81]

for the case of unencrypted files wrongly detected as encrypted, please run: https://docs.nextcloud.com/server/latest/admin_manual/issues/general_troubleshooting.html#problems-when-downloading-or-decrypting-files

[Gajusbonus]

for the case of unencrypted files wrongly detected as encrypted, please run: https://docs.nextcloud.com/server/latest/admin_manual/issues/general_troubleshooting.html#problems-when-downloading-or-decrypting-files

Returns:
Command "encryption:fix-encrypted-version" is not defined. occ config:system:get version 20.0.10.1 So....what version do you expect me to run, to be able to fix decrypting files?

[RedKage]

Do you guys a favor and stop using encryption. This is broken since I have ever used nextcloud. And started with version 9 or 10. All these years I had 500 errors with bad encryption errors, had to re-up files to fix these issues. For 4 years I coped with this, until version 21 or something.

Then decided to reinstall everything, re-upload everything without encryption and do my own encryption with gocrypt-fs. I'm never going back. This is a broken feature from the start. And also prevent many apps to work with it, like the music app which tries (tried? Maybe fixed) to save tags on encrypted files and corrupt them or many other apps not handling encryption. Also now that I have removed encryption it's very easy for to backup and restore my data, as the data is unencrypted I can pull files directly from a backup. While still benefiting from fs encryption on top.

Anyway my 2cents guys.

[Pazu]

Hear, hear. The worst part is there is no apparent will or perhaps even ability on the part of the developers to do anything about this problem.

[asheroto]

Even on a brand new nextcloud installation the issue exists. If it's broken, it should be disabled and not offered as a working product. Related to #8546.

Going to try the solution @RedKage proposed.

[Flonky]

Hi, running ./occ encryption:fix-encrypted-version user seems to have fixed this for me, although I also had to run ./occ files:scan --all afterwards.

For reference, occ config:system:get version returns 28.0.1.1.

[asheroto]

Indeed, it will appear to fix it at first. But I found several days later that encryption was still broken for new or changed files moving forward, especially larger than a few KB even though running that command fixes the existing files.

This of course may not be the case for everyone, but when using the previously mentioned encrypted method encryption with S3, I found this to be the case.

[Flonky]

I found several days later that encryption was still broken for new or changed files moving forward, especially larger than a few KB even though running that command fixes the existing files.

Even after key migration? I haven't noticed anything like that yet, although my instance doesn't have too much traffic either.

[asheroto]

Even after key migration? I haven't noticed anything like that yet, although my instance doesn't have too much traffic either.

Yes! Even after that. I worked on this for days and made several posts. :-/ I ended up just switching to SSE with my S3 provider. That worked out fine, although it still rubs me the wrong way that my data is sent to the S3 provider without being encrypted first. I realize it is encrypted in transmit, but the S3 provider technically receives the raw data, then encrypts it at rest. 😊

[brotkastn]

Hello everyone. Since there have been some time since the last comment here, i thought i would take my chance again at disabling the legacy encryption.

Previously, i did the encryption:migrate-key-storage-format . Today i have taken the following steps:

www-data@srv-nextcloud:~/nextcloud$ php occ status
  - installed: true
  - version: 29.0.4.1
  - versionstring: 29.0.4
  - edition: 
  - maintenance: false
  - needsDbUpgrade: false
  - productname: Nextcloud
  - extendedSupport: false
www-data@srv-nextcloud:~/nextcloud$ php occ files:scan --all
www-data@srv-nextcloud:~/nextcloud$ php occ encryption:scan:legacy-format | tee ../../nextcloud-datadir/nextcloud_encryption_legacy_2024-07-25
Scanning all files for legacy encryption
Scanning all files for brot
Scanning all files for otheruser1
Scanning all files for otheruser2
Scanning all files for otheruser3
Scanning all files for otheruser4
Scanning all files for otheruser5
All scanned files are properly encrypted. You can disable the legacy compatibility mode.

However, if i try to access a share my wife made with a collection of family photos, via the link she used to send to our extended family, it seems to miss the legacy encryption. I can view the previews of the photos, but nextcloud throws an error when i try to access stuff. Neither the "Download" button on the top of the page or the download of an individual image seems to work. The nextcloud log shows the following entries:

{"reqId":"MSajkOfIBJz2hC2BEbwH","level":3,"time":"2024-07-25T18:10:54+00:00","remoteAddr":"2001:1234::1234","user":"--","app":"no app in context","method":"GET","url":"/s/shareViaLink/download","mes
sage":"Exception thrown: OC\\ServerNotAvailableException","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0","version":"29.0.4.1","exception":{"Exception":"OC\\ServerNotAvailab
leException","Message":"Legacy cipher is no longer supported!","Code":0,"Trace":[{"file":"/var/www/nextcloud/apps/encryption/lib/Crypto/Crypt.php","line":378,"function":"getLegacyCipher","class":"OCA\\Encryptio
n\\Crypto\\Crypt","type":"->"},{"file":"/var/www/nextcloud/apps/encryption/lib/KeyManager.php","line":403,"function":"decryptPrivateKey","class":"OCA\\Encryption\\Crypto\\Crypt","type":"->","args":["*** sensiti
ve parameters replaced ***"]},{"file":"/var/www/nextcloud/apps/encryption/lib/Crypto/Encryption.php","line":155,"function":"getFileKey","class":"OCA\\Encryption\\KeyManager","type":"->"},{"file":"/var/www/nextc
loud/lib/private/Files/Stream/Encryption.php","line":284,"function":"begin","class":"OCA\\Encryption\\Crypto\\Encryption","type":"->"},{"function":"stream_open","class":"OC\\Files\\Stream\\Encryption","type":"-
>"},{"file":"/var/www/nextcloud/lib/private/Files/Stream/Encryption.php","line":212,"function":"fopen"},{"file":"/var/www/nextcloud/lib/private/Files/Stream/Encryption.php","line":187,"function":"wrapSource","c
lass":"OC\\Files\\Stream\\Encryption","type":"::"},{"file":"/var/www/nextcloud/lib/private/Files/Storage/Wrapper/Encryption.php","line":489,"function":"wrap","class":"OC\\Files\\Stream\\Encryption","type":"::"}
,{"file":"/var/www/nextcloud/lib/private/Files/Storage/Wrapper/Wrapper.php","line":307,"function":"fopen","class":"OC\\Files\\Storage\\Wrapper\\Encryption","type":"->"},{"file":"/var/www/nextcloud/lib/private/F
iles/View.php","line":1169,"function":"fopen","class":"OC\\Files\\Storage\\Wrapper\\Wrapper","type":"->"},{"file":"/var/www/nextcloud/lib/private/Files/View.php","line":997,"function":"basicOperation","class":"
OC\\Files\\View","type":"->"},{"file":"/var/www/nextcloud/lib/private/Files/Node/File.php","line":116,"function":"fopen","class":"OC\\Files\\View","type":"->"},{"file":"/var/www/nextcloud/lib/private/Streamer.p
hp","line":132,"function":"fopen","class":"OC\\Files\\Node\\File","type":"->"},{"file":"/var/www/nextcloud/lib/private/legacy/OC_Files.php","line":217,"function":"addDirRecursive","class":"OC\\Streamer","type":
"->"},{"file":"/var/www/nextcloud/apps/files_sharing/lib/Controller/ShareController.php","line":492,"function":"get","class":"OC_Files","type":"::"},{"file":"/var/www/nextcloud/lib/private/AppFramework/Http/Dis
patcher.php","line":232,"function":"downloadShare","class":"OCA\\Files_Sharing\\Controller\\ShareController","type":"->"},{"file":"/var/www/nextcloud/lib/private/AppFramework/Http/Dispatcher.php","line":138,"fu
nction":"executeController","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/var/www/nextcloud/lib/private/AppFramework/App.php","line":184,"function":"dispatch","class":"OC\\AppFramework\\Ht
tp\\Dispatcher","type":"->"},{"file":"/var/www/nextcloud/lib/private/Route/Router.php","line":338,"function":"main","class":"OC\\AppFramework\\App","type":"::"},{"file":"/var/www/nextcloud/lib/base.php","line":
1050,"function":"match","class":"OC\\Route\\Router","type":"->"},{"file":"/var/www/nextcloud/index.php","line":49,"function":"handleRequest","class":"OC","type":"::"}],"File":"/var/www/nextcloud/apps/encryption
/lib/Crypto/Crypt.php","Line":301,"CustomMessage":"Exception thrown: OC\\ServerNotAvailableException"}}
{"reqId":"AjIzOqiDuIKw0n44A543","level":3,"time":"2024-07-25T18:11:11+00:00","remoteAddr":"2001:1234::1234","user":"--","app":"no app in context","method":"GET","url":"/s/shareViaLink/download?path=
&files=singleImage.jpg","message":"Exception thrown: OC\\ServerNotAvailableException","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0","version":"29.0.4.1","excep
tion":{"Exception":"OC\\ServerNotAvailableException","Message":"Legacy cipher is no longer supported!","Code":0,"Trace":[{"file":"/var/www/nextcloud/apps/encryption/lib/Crypto/Crypt.php","line":378,"function":"
getLegacyCipher","class":"OCA\\Encryption\\Crypto\\Crypt","type":"->"},{"file":"/var/www/nextcloud/apps/encryption/lib/KeyManager.php","line":403,"function":"decryptPrivateKey","class":"OCA\\Encryption\\Crypto\
\Crypt","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/apps/encryption/lib/Crypto/Encryption.php","line":466,"function":"getFileKey","class":"OCA\\Encryption\\KeyManag
er","type":"->"},{"file":"/var/www/nextcloud/lib/private/Files/Storage/Wrapper/Encryption.php","line":354,"function":"isReadable","class":"OCA\\Encryption\\Crypto\\Encryption","type":"->"},{"file":"/var/www/nex
tcloud/lib/private/Files/Storage/Wrapper/Wrapper.php","line":182,"function":"isReadable","class":"OC\\Files\\Storage\\Wrapper\\Encryption","type":"->"},{"file":"/var/www/nextcloud/lib/private/Files/View.php","l
ine":1171,"function":"isReadable","class":"OC\\Files\\Storage\\Wrapper\\Wrapper","type":"->"},{"file":"/var/www/nextcloud/lib/private/Files/View.php","line":491,"function":"basicOperation","class":"OC\\Files\\V
iew","type":"->"},{"file":"/var/www/nextcloud/lib/private/Files/Filesystem.php","line":530,"function":"isReadable","class":"OC\\Files\\View","type":"->"},{"file":"/var/www/nextcloud/lib/private/legacy/OC_Files.
php","line":344,"function":"isReadable","class":"OC\\Files\\Filesystem","type":"::"},{"file":"/var/www/nextcloud/lib/private/legacy/OC_Files.php","line":123,"function":"getSingleFile","class":"OC_Files","type":
"::"},{"file":"/var/www/nextcloud/apps/files_sharing/lib/Controller/ShareController.php","line":487,"function":"get","class":"OC_Files","type":"::"},{"file":"/var/www/nextcloud/lib/private/AppFramework/Http/Dis
patcher.php","line":232,"function":"downloadShare","class":"OCA\\Files_Sharing\\Controller\\ShareController","type":"->"},{"file":"/var/www/nextcloud/lib/private/AppFramework/Http/Dispatcher.php","line":138,"fu
nction":"executeController","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/var/www/nextcloud/lib/private/AppFramework/App.php","line":184,"function":"dispatch","class":"OC\\AppFramework\\Ht
tp\\Dispatcher","type":"->"},{"file":"/var/www/nextcloud/lib/private/Route/Router.php","line":338,"function":"main","class":"OC\\AppFramework\\App","type":"::"},{"file":"/var/www/nextcloud/lib/base.php","line":
1050,"function":"match","class":"OC\\Route\\Router","type":"->"},{"file":"/var/www/nextcloud/index.php","line":49,"function":"handleRequest","class":"OC","type":"::"}],"File":"/var/www/nextcloud/apps/encryption
/lib/Crypto/Crypt.php","Line":301,"CustomMessage":"Exception thrown: OC\\ServerNotAvailableException"}}
{"reqId":"AjIzOqiDuIKw0n44A543","level":3,"time":"2024-07-25T18:11:11+00:00","remoteAddr":"2001:1234::1234","user":"--","app":"PHP","method":"GET","url":"/s/shareViaLink/download?path=&files=singleImage.jpg","message":"Undefined variable $event at /var/www/nextcloud/lib/private/legacy/OC_Files.php#242","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0","versio
n":"29.0.4.1","data":{"app":"PHP"}}

I do wonder why that exact folder still relies on legacy encryption, as said pictures have been uploded around may - the "active" encryption-module was already set to the default one.

www-data@srv-nextcloud:~/nextcloud$ php occ encryption:show-key-storage-root
Current key storage root:  default storage location (data/)
www-data@srv-nextcloud:~/nextcloud$ php occ encryption:status
  - enabled: true
  - defaultModule: OC_DEFAULT_MODULE

I wonder what the way forward to disabling the legacy encryption module is. The re-download and start with a fresh nextcloud approach is a bit problematic since we are talking about 1.2TB worth of files, family spread across a few thousand kilometers and a huge number of share links which would be lost:

MariaDB [nextcloud]> select count(*) from oc_share where token IS NOT NULL;
+----------+
| count(*) |
+----------+
|      391 |
+----------+
1 row in set (0.002 sec)

Thanks for reading. I am happy that the community proved so helpful for people trying to get their data back. If there is someone with an idea how to proceed in my case, i am happy to test even more 'creative' solutions to this problem and report back.

Also, thanks to the devs for the awesome suite of software that nextcloud is :)