Cloudron Forum

@girish Thanks for the quick reply, that makes sense to me. I’m not worried about Cloudron’s health logic itself; the main thing I’m running into is that the current path (/wp-includes/version.php) consistently triggers Patchstack because it resembles direct access to a core WordPress PHP file. That leads to a lot of blocked requests and noisy logs, even though the container is functioning normally. Switching the health check to something like /wp-json/ would still meet Cloudron’s requirement (“anything non-5xx is healthy”), but it would avoid these false positives entirely. As a bonus, it also reflects more accurately that WordPress is actually up and running dynamic code. I do already monitor sites externally, so no concerns there... this suggestion is more about the internal health check interacting unexpectedly with modern WordPress hardening tools. As these tools become more common, using an endpoint like /wp-json/ might help avoid similar issues for other users without changing Cloudron’s expectations for the liveness of an application like WordPress.

Hi @Joseph , any ETA by any chance on this feature/fix?

Should I try updating this 600 and see if that allows the key to be used?

@james thank you for the clarification and the link! Do I understand correctly, that proxyAuth add-on will respect the Access Control setting of the app and allow access only to the allowed users via their Cloudron authentication? The target app may want the extra auth then but that is fine. Is there a way to add proxyAuth for the existing app? I do understand that documentation says it is impossible, but what if we have quite a big data already in the app that we want to protect and we are not able to just run a fresh install? p.s. Just as a side note, what is the best way to isolate the particular app from the public interface? This will allow us to be able to hide any app without clear reinstall with proxyAuth. This public-interface disabling also would come handy if we wanted the app to only be allowed on the VPC interface (i.e. on our ZeroTier network, but not on the public).

@james Thank you for pointing to this file. It's incredible to me that in 2025, with all the security issues around, that they decide to drop such a feature. This sounds inherently insecure. Astonishing! I followed your advice and established a new user and proceeded to delete the old admin user. Thank you for this suggestion. To other users of this app - they decided to call the admin role "Can manage settings and invite members, with full administrative access" instead of calling it "admin".

@AartJansen Looks like they now fully and openly abandoned the open source model which means users will likely have to migrate to other solutions.

@joseph excellent work. Seems like it was designed for an RPM distro.

The fix for this to clear the search filter on ESC if the view is active: https://git.cloudron.io/platform/box/-/commit/425e196dfc4f4c7e31870f36df7cab0417f7a523

@archos Did this occur while upgrading from Cloudron 8 into the 9 series?

@FrenchyBear @tecbox and you got the same error message but the issues were totally different. The fix I posted was for S3 (used by @tecbox). In your case, you are using gcs. It's a slightly bigger fix - https://git.cloudron.io/platform/box/-/commit/99c14533a5930a6175630b6c299a577d64f2decb . You can get the raw file from https://git.cloudron.io/platform/box/-/raw/99c14533a5930a6175630b6c299a577d64f2decb/src/storage/gcs.js and replace /home/yellowtent/box/src/storage/gcs.js .

OpenCloud uses the slogan “Web Office - Productive Teamwork” in the Features section of its website. Below or next to it, you can see a screenshot. This screenshot shows the Collabora Online logo. Therefore, you should look into how you can activate/integrate Collabora Online in OpenCloud. I don't use OpenCloud yet, but I would assume that you have to enter the information about your Collabora instance in the settings. [image: 1764853031574-2025-12-04-13.56.40-www.collaboraonline.com-7dcb1af60b8c-resized.jpg]

Haven't encountered such timeouts from thunderbird, unless the network is actually flaky. Maybe check if both ipv4 and ipv6 are setup but only one works? Could be that thunderbird (probably relying on the system's network interface selector) sometimes picks one of the two which resolves but does not route.