ownCloud 8.1: Get your encrypted files back after an update failure from 8.0.X

I use ownCloud on a daily basis. I have setup a server years ago, and all my digital life stays there instead of going onto those “I don’t know who, I don’t know where and what they do with it” servers of Dropbox, Google drive etc…

Lately, I upgraded from ownCloud 8.0.4 to 8.1, followed all the necessary steps indicated in the manual, waited few hours for the migration to finish (encryption app is different and I have 400GB of data) and everything seemed fine. Until I try to access some of my files (especially non image files). I was getting an ERROR 500 or 403. No specific clue in the Apache log (apart from an error related to encrypt script) and no way to get my files back!

I will share here the safest way I found to get all my files back without waiting again and again for key migrations or other migration processes taking very long time on such amount of data.

Briefly summarised, you will need to:

1. get a copy of your failed ownCloud “data” folder (it’s at the root of the ownCloud folder)
2. install a new instance of ownCloud using an identical version of what you were using before the update
3. setup ownCloud users with identical user names and passwords (very important!) as you have on the failed instance
4. do some move/copy work
5. sync your data with the ownCloud client on a computer where you will get your files back, unencrypted

So Let’s go into the details:

The computer setup is composed of 3 computers:

• ServerA which contains the failed instance of ownCloud
• ServerB which will host the new instance of ownCloud
• WorkstationA where you will sync all your files from ServerB so to get them back unencrypted

Here is the detailed steps:

1. From ServerA, copy the “data” folder located into the ownCloud directory to a safe place onto ServerB. The best is to use rsync over SSH if you are dealing with a WAN between those 2 servers
2. Install ownCloud on ServerB. Warning! Use the very same ownCloud admin username and password as ServerA for this installation. Don’t forget to activate the encryption App. Then, on this new instance, create all the users you were having on the failed instance with the very same username and password. For each user, login and logout to initialise encryption and the user directories
3. Move the “data” folder of the new instance to a safe place and put there instead the data folder of the failed instance. Now go into this data folder. We’ll need to put the encryption keys back in the right place just as it was before the migration. For this:
   1. delete the directory “files_encryption” located into “data”
   2. copy the “files_encryption” dir from the encryption_migration_backup_<date> dir (take the oldest if you have many) into the data dir. You end up with a “data/files_encryption” dir containing the encryption keys suited for the previous version of ownCloud, the one of the new instance
   3. go into each user dir of the data folder and do the same
4. Issue a “sudo -u www-data ./occ files:scan <username>” command for each user you have on this new ownCloud instance. This will bring back online all the files available in the data folder of each user. This may take a lot of time…
5. For each user, login and check that the files are back
6. Change your “hosts” file on WorkstationA to lure the ownCloud sync client you will install. It will make it think it’s connecting to ServerA (in fact it’s connecting to ServerB)
7. Install ownCloud sync client into WorkstationA and set it up to sync all your files back

Et voila. You now have a non encrypted copy of all your files on WorkstationA. From now on, you can either change from cloud system (I think I’ll move to Seafile) or copy it back to ServerA (after having a fresh install ready).

A small trick: Your sync client is failing syncing with some “Connection timeout” messages? The problem seems to be the default owncloud client setting for “timeout”. The solution is to increase this parameter, e.g. timeout=4600, in the section [General] in ~/.local/share/data/ownCloud/owncloud.cfg. Check also the memory limit in the php.ini file of ServerB. If it still fails, try to sync by chunks (by selecting what to sync).