Hello @R4nmaru314,
Thanks for taking the time to write this up and I’m sorry it turned into the ordeal you are describing. Reading through it, the frustration is understandable.
We try hard to make passbolt as batteries-included as possible, so that for the community the installations mostly just works out of the box. Part of keeping that promise is holding our official documentation paths to the well-supported, standard environments. It isn’t that a setup like OpenLiteSpeed is beyond reach (and from your write up you clearly know your way around servers). The catch is what a official guide implies. Once we publish one, we are effectively committing that environment to be maintained across every future upgrade, therefore the the day-to-day burden of keeping the combination working lands on the SysAdmins. We really want to avoid that becoming the kind of “nightmare” you just wen through. Pointing people toward the support, batteries-included path is how we try to spare them exactly this pain, rather than any lack of care about the less common setups. Those recommended (and officially supported) methods live under our hosting guide.
I also really appreciate that you spent your time writing this, and I mean that sincerely. What I would have appreciated even more was the chance for us to spend our time helping you while you were still in the middle of it. We don’t have a deep official experience with OpenLiteSpeed (at least for myself) but a live back-and-forth problem in front of us is exactly where we usually dig and help properly. Once everything is wiped, all that goodwill on both sides has nowhere left to go.
Also, on the technical side, a few things stand out that might help you or anyone who lands here later, the permissions problem usually trace back to how the installation was made in the first place. For example, a from-source install and a packaged install place files with differences paths, owners and permissions so the right fix depends heavily on which route you took and which documentation you followed at first. Then, the error “The OpenPGP key can not be used to encrypt” is a error that I have seen in the past, it is very rarely the key itself which fits with encryption working fine for you from the shell and from PHP. That pattern almost always point to the environment the web server’s PHP runs under. Usual culprits are AppArmor or SELinux, depending on your distribution, quietly blocking the worker from reaching the key material or the GPG socket, possibly FIPS mode also being enabled which does not get along with ECC keys. This matters because ECC has been the default for users keys for a few versions now to increase the performances with all the E2EE operations. A FIPS-locked host will reject exactly the keys passbolt generated by default even though everything looks valid on inspection.
Regarding the healthCheck, I hear you that it can come across as a blame tool, even though that’s not the intention. Especially, I checked the code and it does carry a lot of remediation helpers across its various failure paths, so if you hit a failure that left you with nothing useful to act on, that is something we are very interesting to hear as we will have a better picture if we need more documentations or more helper guidance from the healthCheck itself (or both obviously). If you remember which checks fell short, I’d be grateful you sent them my way so I can raise them with the team.
If you ever comeback, or even if you just have a minute to the few questions about the install methods, healthCheck etc. This could definitely help to make this smoother for the next person in your shoes. Either way, thank you again for the honest write-up.
Best regards
