I’m aware that this topic is quite old, but I just wanted to add an afterthought for those that might be searching for a solution and stumbled upon this topic, which is marked [SOLVED] 
I had a very broken configuration of Cells 2.2.2. The main reason for that is having migrated successfully from Pydio 8.X to Cells 1, and later to 2, and so forth until 2.2.2. While doing that, I managed to create all sorts of workspaces spread all over the place… To make matters worse, at some point I thought it would be a nice idea to consolidate two old Pydio 8.X installations — used by different sets of users — into a single Cells 2.2.2 installation, just separating users from each other in different groups (it’s a pity I cannot have different domain names for each group, but I can survive with that).
As you can imagine, this quickly became a mess, and tinkering with the pydio.json was just making things worse and worse. After reading this thread, it seemed that I had no other choice but to start from scratch.
Since, fortunately, the workspaces themselves are stored on disk, and are not modified by Cells, it seemed that the only thing I would ‘lose’ in the process was, well, all users and groups, their roles and permissions, and possibly some configuration details here and there. As most of these things were falling apart anyway, I thought that it was worth a try. Thus, I promptly removed pydio.json and deleted the database — after making a backup first, of course.
As this topic so correctly informs, running ./cells configure — in my case, I used the command-line setup, mostly because I wasn’t sure if I could get the reverse proxy to reach a ‘temporary’ configuration (i.e. bound to port 8080 — which I have used for other purposes and therefore need to pick a different one for Cells) that would allow me to point a browser to Cells and continue from there. But that wasn’t necessary: the CLI setup worked perfectly, and soon I had a ‘fresh’, working installation of Cells 2.2.2 again.
I missed the extra data on the ‘old’ database, though. So I did the following: I was getting some of those weird ‘Ladon’ errors. All the tables beginning with ladon-* were empty (what initialises them?). Thus, I simply copied the content from the old database over the new one — if everything broke apart, it would be just a question of truncating the tables again.
But everything worked! (Aye, that surprised me…) Whatever ‘Ladon’ errors I had on the logs simply disappeared. Great! One problem less!
Well, after that success, I noticed that the tables with idm-* were also empty… and these have considerably more information. Therefore, I did exactly the same as I did with the ladon-* ones… just copy everything over them… and guess what? I got practically everything back — roles, groups, users, permissions… even taking into account that Cells has all the storage and workspaces in completely different locations, this ‘copy & paste’ seemed to bring back most of the configurations (if not all)!
In the future, this two-step ‘full reset’ may, indeed, become a standard procedure — possibly even an option on the Admin Console, who knows?..