User receives invalid key warning despite having never changed password

[fleish]

User receives the message "Invalid private key for Encryption App. Please update your private key password in your personal settings to recover access to your encrypted files”

The below is also logged:
{"app":"Encryption library","message":"Private key for user "****" is not valid! Maybe the user password was changed from outside if so please change it back to gain access","level":3,"time":"2014-04-23T16:14:47+00:00"}

However, this user has never changed their password so we are not sure why this is happening.

[blizzz]

discussion on IRC:

[18:18] <fleish> I also see some sh: 1: rsvg-convert: not found in the apache 
error log, but I don't think that's related to this
[18:19] <fleish> blizzz: yes, when I login as this user from my machine I can 
see his files just fine
[18:20] <Blizzz> fleish: okay, and the original users acutally sees garbage?
[18:21] <fleish> blizzz: the user keeps getting the invalid key message. I 
don't think he sees new things being shared with him for instance. not sure 
exactly what else he sees
[18:22] <Blizzz> fleish: but can he open his files successfully? to find out 
whether the message is just a false positive
[18:23] <Blizzz> fleish: it should not have any effect regard shares to him
[18:26] <fleish> blizzz: I'm trying to have them check that now
[18:26] <Blizzz> fleish: good, ty. also, do you know whether he uses the 
desktop sync client?
[18:27] <fleish> blizzz: I think he has tried to. though I had him logout and 
quit it to avoid any extra variables interfering
[18:28] <Blizzz> was it his first attempt with the client or was it running 
already for some time?
[18:28] <fleish> I'm not sure
[18:29] <Blizzz> i have the encryption dev on xmpp, but he needs to leave soon, 
in that case we'd need to open a bug report so he can have a closer look
[18:30] <Blizzz> do you know whether the client, as it was running, did show 
any errors?
[18:34] <fleish> blizzz: I'm happy to open a bug to track it. I have notes here 
from before and it says we had him quit the client and restart it and the icon 
showed the green checkbox
[18:37] <Blizzz> fleish: so that's also a sign that everything is correct. 
Smells like a false positive, if he can confirm that the can still open his 
files correctly.

cc @schiesbn

[gnanet]

I faced this issue with encryption enabled, and folders shared to a group.
All users in the group had encryption enabled and were already logged in, after that the shares were created, and the files were uploaded after that. But for one user who was never logged in before, the mentioned message comes up. I assume that his keys were not created, and the share process could not create his share-keys. see #7437

We still not fully solved our problem, but based on some hints about "do a reshare", we removed the user from the group and added him as single user to the share. But the process of sharing 10000-s of files for about a size of 30Gb it fails somewhere, leaving some files without a share-key for the user, but this is an other issue.

[schiessle]

But for one user who was never logged in before, the mentioned message comes up. I assume that his keys were not created, and the share process could not create his share-keys.

Yes, that's correctly. In this case the user should get a message along the line "Can not decrypt this file, probably this is a shared file. Please ask the file owner to reshare the file with you." if he tried to access the file where no share-key exists. But encryption should work for all other files.

We still not fully solved our problem, but based on some hints about "do a reshare", we removed the user from the group and added him as single user to the share.

You don't need to remove the user from the group. You just need to trigger the re-calculation of the users list. This can simply be happen by sharing the file additionally to the user (or also to any other user) and afterwards remove the single share again.

[gnanet]

This is unsolved for us: "But the process of sharing 10000-s of files for about a size of 30Gb it fails somewhere, leaving some files without a share-key for the user, but this is an other issue"

I could imagine a cli php script which i can run as long as i need

[fleish]

Ended up solving my user's issues last week. He was receiving several error message depending on what state we left his account on the owncloud server. But in the end we deleted his data directory which contained his private key. That resulted in an error message when he logged back in asking him to logout and back in again. However, that action did not change anything. It turns out there was an old public key in data/public-keys and once we deleted that he was able to login without any errors and use the service normally. I'll leave this open though since other people seem to be having the issue.

[schiessle]

@fleish great to hear that you could solve the issue. If only one key is gone it's hard to decide what to do. In the case of your user it would have been easier to just create a new key pair. But if a user still have encrypted file it could be better to exit with an error and give the user/admin the chance to restore the keys from a backup.

Because it is not always possible to do the right thing in such a situation we decided that it is better to stay in a error mode and let the admin investigate the issue and decide what to do to reduce the risk of data-lose.

[jancborchardt]

@schiesbn so what’s the call on this? Close, or are there tasks to do?

[schiessle]

according to @fleish the initial issue is solved and the issue from @gnanet will be discussed here #10010