[Bug]: 3.12.3 Cannot sync E2EE files. Encrypted metadata setup error!

[Eric-Sparks]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

In version 3.12.3, I'm not able to sync E2EE files. In fact, right now some of the E2EE files are showing up in their encrypted form on my client. I've verified the encryption mnemonic is the same.

Steps to reproduce

1. Add files to E2EE folder.
2. See the Nextcloud client fail with a red X icon.
3. See error message "Server replied with an error while reading directory "x" : Encrypted metadata setup error!"

Expected behavior

Files sync as expected.

Which files are affected by this bug

2024-01-26-Eric-Thrift_Savings_Plan_statement.pdf

Operating system

Linux

Which version of the operating system you are running.

Both the packaged version in the Fedora 39 repo and the flatpak version.

Package

Distro package manager

Nextcloud Server version

28.0.5

Nextcloud Desktop Client version

3.12.3

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

{"reqId":"9acBM5KcfqcHMHcn79bI","level":3,"time":"April 29, 2024 23:29:59","remoteAddr":"2601:14b:4780:beb1:c921:8815:955a:5c06","user":"USER","app":"webdav","method":"PUT","url":"/remote.php/dav/files/USER/Family_Files/Financial/2024-01-26-Eric-Thrift_Savings_Plan_statement.pdf","message":"Write access to end-to-end encrypted folder requires token - no token sent","userAgent":"Mozilla/5.0 (Linux) mirall/3.9.3git (Nextcloud, fedora-6.8.7-200.fc39.x86_64 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"28.0.5.1","exception":{"Exception":"OCA\\DAV\\Connector\\Sabre\\Exception\\Forbidden","Message":"Write access to end-to-end encrypted folder requires token - no token sent","Code":0,"Trace":[{"file":"/usr/local/www/nextcloud/apps/end_to_end_encryption/lib/Connector/Sabre/LockPlugin.php","line":148,"function":"verifyTokenOnWriteAccess","class":"OCA\\EndToEndEncryption\\Connector\\Sabre\\LockPlugin","type":"->"},{"file":"/usr/local/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"checkLock","class":"OCA\\EndToEndEncryption\\Connector\\Sabre\\LockPlugin","type":"->"},{"file":"/usr/local/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":456,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/local/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/local/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":321,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/local/www/nextcloud/apps/dav/lib/Server.php","line":373,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/local/www/nextcloud/apps/dav/appinfo/v2/remote.php","line":35,"function":"exec","class":"OCA\\DAV\\Server","type":"->"},{"file":"/usr/local/www/nextcloud/remote.php","line":172,"args":["/usr/local/www/nextcloud/apps/dav/appinfo/v2/remote.php"],"function":"require_once"}],"File":"/usr/local/www/nextcloud/apps/end_to_end_encryption/lib/Connector/Sabre/LockPlugin.php","Line":164,"message":"Write access to end-to-end encrypted folder requires token - no token sent","exception":{},"CustomMessage":"Write access to end-to-end encrypted folder requires token - no token sent"}}

Additional info

No response
Uploading nextcloud-client-logs.zip…

[Eric-Sparks]

[toniQva]

[NC Client 3.13.0 not recognizing file renaming in Windows!!!!!!!!

The same problem described here NC Client 3.12.0 not recognizing file renaming in Windows 3 has been reintroduced in the Nextcloud-3.13.0-x64 version. I have reverted to Nextcloud-3.12.3-x64 version and it works correctly again.

[JoshuaPettus]

Can confirm the issue is effecting 3.13.0 again. Just like toniQva, reverting to 3.12.3 did alleviate the issue, though I did have to clear and redo the private key then reupload. Also NC pushes to upgrade now. OP said 3.12.3 was the problem but that wasn't my experience.

[Eric-Sparks]

Is there any additional information you need from me on this? Not being able to sync with my server is getting annoying.

[JoshuaPettus]

Idk, but they quietly continued patching the 3.12 branch in the background and it's now 3.12.5 on github. I would just switch to that.

[Eric-Sparks]

Just tried 3.12.5 and still getting the same error.

[JoshuaPettus]

I had to copy out all the unencrypted private data. Go into the user's security prefrences and remove the encrypted keys. Then redo the whole thing from scratch. For me it worked on the 3.12 branch, 3.13 just went back to the situation.

[Eric-Sparks]

I had to copy out all the unencrypted private data. Go into the user's security prefrences and remove the encrypted keys. Then redo the whole thing from scratch. For me it worked on the 3.12 branch, 3.13 just went back to the situation.

For some reason, all my E2EE files are showing as encrypted on my computer so nothing is decrypted.

[JoshuaPettus]

oh no... do you have a backup of the unencrypted data?

[Eric-Sparks]

Maybe?

[JoshuaPettus]

There is some information here on how to decrypt, but honestly I think its better to keep a backup of the files unencrypted just in case. (or at least encrypted via other means, eg restic database) Ive been burned by E2EE before.
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/encryption_configuration.html

[Eric-Sparks]

It looks like I have access to that data on my mobile device so I can recreate it from there.

I think those instructions are for server-side encryption and not E2EE.

[JoshuaPettus]

Ah you may be right...

I keep a backup of my unencrypted files by syncing the private folder to restic periodically on the local machine (borg is a good choice too).

[Eric-Sparks]

I haven't tried it, yet, but it looks like this might work: https://github.com/nextcloud/encryption-recovery-tools/tree/master/end-to-end-encryption

[JoshuaPettus]

Ah that's good that there is an emergency solution. Still I'll try not to need it in the first place. I've said it before, E2EE, while great, is kinda dangerous. It doesn't take much for it to become unhappy and have its internal keys all messed up.

[toniQva]

3.12.3 It's ok 👌

[E1onE2]

I just updated my windows client to 3.13.1 and still got this error. I cant sync because of one folder issue since weeks.
Windows Client: "Encrypted metadata setup error!"
IOS App: "An internal end-to-end encryption error ccured"
I cant delete the problematic files/folder and they are not syncing, so I am stuck.

[E1onE2]

or some reason, all my E2EE files are showing as encrypted on my computer so nothing is decrypted.

Did it work? Whats your status right now?

[eikel]

I get the same error message with 3.13.2 (installed by Debian package 3.13.2-2). Downgrading to 3.11.0 (Debian package 3.11.0-1.1+b1) makes the error disappear.

Addendum: Installing the old version completely messed up my encrypted files and folders. I had to restore them from a backup. I therefore advise against downgrading.

[executed]

I think I was able to fix this... We will see how it goes.
Ping me to post the solution if you have problems with the PC client and not the app client + you have an unencrypted backup of problematic data + Docker installation (could be a showstopper if not Docker).

[eikel]

Still the same error message with version 3.14.1 (Debian package 3.14.1-1).
@executed Are you able to create a PR for your fix?

[executed]

Still the same error message with version 3.14.1 (Debian package 3.14.1-1). @executed Are you able to create a PR for your fix?

No. These were manual steps I wanted to suggest. I don't know the root cause.

[eikel]

Could you please share these manual steps? It would potentially help me working around this problem, and maybe will also help others to understand or solve this problem.

[executed]

Basically I had to do sync from scratch - I believe this is not the fix for you if your data in synced folders was only on NextCloud and not either in backup or still there in synced folders.

1. Disabled sync connection for all the folders on the PC client.
2. Enabled maintenance mode on the Nextcloud server.
3. Stopped PC client.
4. Exposed DB ports of MariaDB that are attached to my Nextcloud (port 3306).
5. Ran SQL commands to disable file locks related to end-to-end encryption (I don't know what these mean, DYOR):

DELETE FROM oc_file_locks WHERE 1; DELETE FROM oc_e2e_encryption_lock;

6. Disabled maintenance mode.
7. Used iOS NextCloud app to delete files in the parent sync folders.
8. Used iOS NextCloud app to decrypt folders;
9. Used iOS NextCloud app to delete folders;
10. Executed full NextCloud files scanning just in case:
    php occ files:scan --all
11. On Desktop moved all data from prev. synced folders to temp. location
12. Created empty folders through Nextcloud web UI that have same names as before, now they just empty;
13. Re-established sync connection on PC, avoiding virtual files config (suspected issue) by mapping Desktop empty folders to Nextcloud empty folders.

[goodfrank]

Same issue with Nextcloud server v27 and v28, Desktop client version 3.14.1 and 3.14.3.

Steps to reproduce

1. enable End-to-end-encryption app, enable default encryption module and enable server side encryption on the Nextcloud server
2. Connect the Linux desktop client to the End to end enabled server
   3.In the Linux desktop client v 3.14.2 enable End to end encryption, fill in the mnemonic
3. Create a new folder using the client and encrypt the folder
4. Copy data to the new encrypted folder in the client

Expected behaviour

Synchronisation should work without errors

Actual behaviour

Error appears in Nextcloud desktop client: "error while reading directory "xxxx", Encryped metadata setup error: initial signature from server is empty"

[executed]

Same issue with Nextcloud server v27 and v28, Desktop client version 3.14.1 and 3.14.3.

Steps to reproduce

1. enable End-to-end-encryption app, enable default encryption module and enable server side encryption on the Nextcloud server
2. Connect the Linux desktop client to the End to end enabled server
   3.In the Linux desktop client v 3.14.2 enable End to end encryption, fill in the mnemonic
3. Create a new folder using the client and encrypt the folder
4. Copy data to the new encrypted folder in the client

Expected behaviour

Synchronisation should work without errors

Actual behaviour

Error appears in Nextcloud desktop client: "error while reading directory "xxxx", Encryped metadata setup error: initial signature from server is empty"

Same issue with Nextcloud server v27 and v28, Desktop client version 3.14.1 and 3.14.3.

Steps to reproduce

1. enable End-to-end-encryption app, enable default encryption module and enable server side encryption on the Nextcloud server
2. Connect the Linux desktop client to the End to end enabled server
   3.In the Linux desktop client v 3.14.2 enable End to end encryption, fill in the mnemonic
3. Create a new folder using the client and encrypt the folder
4. Copy data to the new encrypted folder in the client

Expected behaviour

Synchronisation should work without errors

Actual behaviour

Error appears in Nextcloud desktop client: "error while reading directory "xxxx", Encryped metadata setup error: initial signature from server is empty"

This is different error. But I had this one recently too.
What helped me is going through steps in previous comment, but don't run DELETE FROM oc_e2e_encryption_lock SQL and also don't disable folder sync connection/delete all folders, just the ones that are priblematic

[philfry]

I get the same error after upgrading from 3.14.0-1.fc41 to 3.15.3-2.fc41 (Fedora 41). No locks in database, all other client still can access (and decrypt) the encrypted data.
Downgrading back to 3.14.0-1.fc41 solved the problem.

[xylo]

Same problem with the Windows client version 3.15.3. I downgraded to version 3.14.0 but still see the same error message.

[y0va]

I solved this by upgrading the server to latest.

[philfry]

Not for me. Still having this issue with server 30.0.5 and nextcloud-client-0:3.15.3-2.fc41.

[JoshBrownNeuro]

I was running server 24 and windows client 3.8 for several years with no problem, including an E2EE folder, and suddenly the E2EE folder stopped syncing with this error message. I upgraded to latest server 30.0.6 and client 3.15, but still the unencrypted folders would only sync if I detached the E2EE folder. It gave me the error message and wouldn't sync. I don't think this is server side as my android client could still access and download E2EE files from the encrypted folder. Finally I created a new folder on the client, turned on E2EE encryption for the new folder, copied the files over, and now the new encrypted folder is syncing fine. The original one still does not sync and blocks all folder syncing when attached. It seems something in the old E2EE folder configuration got corrupted client side. For any maintainers working on this bug, could you check for client side E2EE config corruption?