Collabora not working with encryption

@SpiGAndromeda check this:

there is a bug report also, I have 14.04 fully updated and mine worked, but, again, doesn’t work on 16.04

I checked this bug thing. The CONFIG_AUFS_XATTR=y Option is enabled.

Ich checked this issue with the Virtuale Machine from Collabora. I updated the owncloud instance inside to nextcloud and activated the entcryption and the editor worked perfect.

With this knowledge i tried to transfer the Collabora Online Development Edition App to my nextcloud. Unfortunatly without success. There are a lot of differences in the general file handling between this app and the richdocuments app.

Does have anybody an idea how to debug the richdocuments app? Because the appearing error isn’t showing in any log file … even with debug log.

Another point I should mention is the delay wich is discribed several times. This delay doesn’t appear in the VM.

so you’re saying the app in the CODE VM is not the same as the one on github? If it isn’t it is 90% sure simply older, so a change must then have broken encryption or something… I suggest you file a bug in the app repo on github, they can then verify if it should work or not.

16.04 and also the same error. When disabling the encryption app it works. Any update how to solve this with encryption enabled? (seems to much of a hassle to decrypt all files for all users)

is there any news according to this encryption problem? By the way is it cloud problem, or app problem, or docker/libreoffice-online problem? I have the same error messages (except for delay what was solved few days ago in new docker image) as described here:

+ in docker logs when encryption is on I see also:

wsd-00009-67 19:04:46.477398 [ prison_ws_0057 ] WOPI::GetFile downloaded 9302 bytes from [https://cloud.local/cloudcrypt/index.php/apps/richdocuments/wopi/files/87?access_token=XjNTYXDIhdCbFRMKF6mDm6F VeOMxxFP1] -> /opt/lool/child-roots/16798/user/docs/16798/New Document.odt: 503 Service Unavailable

Any news on that one? Sorry for bumping but it’s been a month without an official statement.

Does using encryption mean collabora will not be working ever?

Were you editing old file after switching encryption on or a new one?

If you used an old file and did not run (encrypt all) the file was still unencrypted.


Collabora has informed that there is already official support of their product with Nextcloud/Owncloud. Didn’t you get the chance to look at it and encryption? Does it work already? On app home page there is only last message on September from developer that they need help to solve this.

Did anyone ever find a solution for this? I have a similar issue… Cannot decrypt this file.

I Really hope this stance will soon go away. I heard it far too often recently and it is just incorrect or at least incomplete IMHO

a) If an admin circumvents the encryption to access files, he can be made liable in certain countries.
b) Its much more attempting for admins to take a peak at unencrypted files then going through the effort to try to decrypt those files. Especially since he has to inject malicious code to catch the decryption password entered by the user.
c) If I, for whatever reason, start to distrust an admin, I can be sure he can not access my files - if he not already did - and I am not logging in anymore (not providing the required decryption password). By that I can virtually delete all my files on an nextcloud server, simply by not using it anymore. Sometimes level of trusts change, you know, and a elsewise trustworthy person might become untrustworthy after certain events.

So please finally fully embrace your neat encryption feature by
a) Support encrypted thumbnails
b) Support Collabora in encrypted mode
c) Support it everywhere else, where it is not yet supported, like offering it to apps (Contacts/Calendar)

And additionally put up a warning to the users in the “Basic encryption module”-setting, that their files could get compromised by a malicious admin that is sniffing the password. As the current “password recovery” option suggests to an ingenuous user that his files can not be accessed by anyone. Which, as you said, can only be achieved by using client side encryption.

PS: just went through 2 days of struggle to update my pi2 owncloud 8.2.10 installation to a 64bit pi3 openSuse Leap 42.2 + Docker + Collabora + Nextcloud 11.0.2. Just to learn in the fine print, “Oh btw, collabora does not support encryption, tough luck” :cry: … “What you are fine with using Documents, Oh sorry, we don’t support it either, cause Collabora had conflicts with it. Not your day, huh?” :sob:

Your reasoning looks like a very special use case where you have an admin who you trust in general but who is a bit snoopy (and not enough to circumvent encryption). And you are confident enough to be able to figure out before he gets malicious.

I don’t deny that there are some use cases where it can be an advantage. But these are special cases and very in-transparent to end users (how can you be sure that encryption is enabled at all?). But if there is a problem with the encryption implementation, or your admin didn’t backup properly (and that’s more critical with encryption), you might lose your data.

I prefer a clear statement: everything happening on the server is not under control of the user. Consider that the admin can access your data. Trust him/her with certain data or implement efficient security mechanisms (client-side encryption or don’t sync it).

I thought this is the default case for Nextcloud users. Not big corporations but selfmade admins offering their setup to friends/family to use? They might just be able to set up everything but are a long shot away from being even able to decrypt this on their own or silently introduce malicious code.

Also people sometimes get bored or drunk, disappointed or weak. Snooping around unencrypted files is easy and quickly done. But they still would not even come close to the idea to go such lengths to decrypt the data.

Also if I have two servers to choose, one promises me to enable encryption, the other says, “does not make sense” I would always choose the first one, as I can virtually delete my account at any time, for whatever reason. Quickly & simply by stopping using it. This is not necessarily because I don’t trust them any more, but because I choose a different method. I don’t even have to worry about backups as they were also encrypted. On the second server I totally lost control over what happens to my data. Period It could be on a system that the admin does not update anymore, and now totally insecure. I can’t do a thing.
Ofc the first one could have just lied to me and not enabled encryption as well. But I think in reality this is unlikely to happen and tough luck that you trusted them.

You could say that even if the encryption is not perfect, it is better than having no encryption at all. Some not-perfect protection is better than nothing. Well, it leads you to be much more careless because you somehow rely on it. You wrote for example you wouldn’t have to care about your data if the admin misses to put the latest updates. If there were a bug fix for the encryption module, your data could be vulnerable and you wouldn’t delete it because you think they were properly encrypted.

Suppose you are not fall for this false security. The encryption app adds a lot of code and complexity. Some are perhaps only annoying bugs you can live with. Some had already problems restoring their backup data Howto restore encrypted file into NextCloud, failing upgrades, …

In one setup I was using the encryption app as well (some versions ago). At some point, all problems I had were related to this encryption app. Since it was disabled, no problems. To encrypt my disks and backups, I use other solutions that are more tested and more reliable than this app. I would only use this app again with an enterprise subscription where I know to get support for such problems. Have seen too many users with unusable files due to encryption.

You argue as if I want a non existing encryption module, but actually it is already there and working fine. Use it in the company as well as at home. No problems yet beside Nextcloud not supporting it all the way. What a shame. Its like flying to the moon and then not landing on it because, reasons.

PS: I kinda missed the “Experimental” tag on the encryption module. What you describe sounds like it should be labeld as such. Last time I checked it said “Official”

It is officially supported (and always was). It is more code that can fail (and that did fail in the past). Perhaps it improved a lot and there are not many problems, updates/backups etc. Bugs will probably be fixed (I had some problem with files that were uploaded a few months earlier when there was a bug and the key file was lost).

Adding a code snipped that snoops the passwords took me about 15 minutes and I’m not a php expert (if a user forgets his password but still has a client with the password, this can be useful).

“Flying to the moon” would be full client-side encryption, and you can have that with 3rd party software (except for the sharing feature) that was developed by encryption experts, with (external) reviewing process, …

This is the main reason for Nextcloud… the sharing. Else I can use encfs and any cloud space.

BTW. Fun fact from the encryption FAQ of Nextcloud:

Is It Planned To Move This To The Next User Login Or A Background Job?
If we did that, then we would need to store your login password in the database. This could be seen as a security issue, so nothing like that is planned.

So suddenly, if someone needs ease of use decryption of already encrypted files. It is a huuuge security risk. This projects stance of this feature is all over the place. :unamused:

A similar thing happened to me during the last week. A lot of effort flew into this project, but in my case the encrytion module is too important to be switched off. I could appreciate if nextcloud made a clearer statement about one of its most powerful apps not supporting the encryption module.

Are there plans for the future that would allow both apps to coexist happily?

You can do it yourself, the documentation is public as well, everybody can contribute and improve it.

According to Nextcloud’s default encryption module is supported since Collabora Online app version 1.11.30 / 1.12.30 (for NC 11 and NC 12 respectively).