Yeah, with a purchased SSL cert, as LE didn’t seem to want to play ball.
Hello @JapSeyz,
If you don’t mind cleaning (rm -rf ~/.config/pydio/) and reinstalling with the following:
- INTERNAL: domain:port
- EXTERNAL: by default should have scheme:domain (nothing to change if you are not running behind a proxy).
Once it is done could you try the sync with a regular workspace.
Also recreate your S3 datasource and tell me if you have any issue.
Regards
Will give it a go when I get home.
Can I simply delete the config and then run the installer again?
Yeah it’s pretty much that, (make sure to clean database + config)
Alright. Will clean the .pydio meta file from the buckets, to ensure they’re completely reset too.
Ps. in regards to the S3 datasource, it seems to be able to find it no problem, as it creates the “folders” in the bucket and adds a .pydio meta-file to each “folder”. But maybe one of the microservices has a prefix or something?
I’ll try to sync with a regular disk workspace first though, and then move it over to the S3 buckets afterwards
Good plan! When the cells server is running, first try to up- and download files on the web interface. Then, set up the sync client. If you have problems with the sync client, try to connect directly to the server (without the proxy).
[SOLVED]
This has been solved, there was a few caveats that the people at Pydio were kind enough to help me figure out.
-
When using Let’sEncrypt, the external URL should be like this:
https://domain.comand the internal url should be like this:domain.com:443 -
Currently an internalPath with S3 is unsupported or results in a bug. I am not sure if this is written anywhere, but it was observed as we set it up.
If you run into any similar issues, hit me up and I’ll see if I can help you out.
Cheers
2 Likes
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?..