@nebulon Just to confirm: I presume you are saying that the updated package works well, and that you are not saying that the OIDC login works well. Is this correct?
This would seem to match my test: the package does work well in the demo instance, but is without OIDC for now.
Also I suppose the App Status table here is updated regularly, but not automatically which would explain the info/package version discrepancies?
Many thanks again,
@girish Looks like v.3.3.0 is out and includes your fix. Would you consider looking into OIDC with releasing Cloudron's related updated package? Thanks,
Hi @JLX89,
This is something that has been discussed / requested a few times already.
Please see here:
https://forum.cloudron.io/post/91579
https://forum.cloudron.io/post/93245
and here for the latest:
https://forum.cloudron.io/post/96688
In short, my understanding is that it is coming in 8.2. Or could it be sooner @girish ? This seems in relative high demand.
If I get this right the Cloudron part is done, it just needs the related app package to be updated to make use of the Cloudron env variable.
@girish said in Cloudron Source & Release Notes:
@uwcrbc said in Cloudron Source & Release Notes:
Because this list seems to differ somewhat from the "What's coming in 8.1" forum post, I wanted to take a closer look to the release notes and note the differences, see what made the cut off and what has not.
yes, good catch. I will rename that post to 8.2 . We introduced many regressions in Cloudron 8.0. So, we made a 8.1 for mostly bug fixes and some minor features like OIDC group support.
Ah, I understand better now v8.1 vs v8.2. Thanks for this.
Am I right in thinking that the OIDC button branding did not make it into this release?
We are waiting for this for a few apps releases...
Also, just to confirm: is there any official place one show look for a complete set of release notes other than in a Forum/Blog post?
Thanks again.
@girish said in Cloudron Source & Release Notes:
@uwcrbc the repos have moved a bit in last few weeks. We are moving all the app packages into the CI for automated and reproducible builds. I will make a separate post later this week explaining what we have done (it's mostly only technical and probably interesting to a fellow developers
but not for cloudron users themselves). In the past, we were quite careless with how people registered and were given permissions. But anyway, to answer your question until that post pops up: we have made a few groups.
Cloudron code base - https://git.cloudron.io/platform
App packages - https://git.cloudron.io/cloudron
For doc repos - https://git.cloudron.io/docs
Unpublished apps, tools, testing stuff etc - https://git.cloudron.io/playgroundThe repos will most likely not get re-orged further but I will put the final org in my post.
@girish Great - This makes sense. Indeed I got the feeling that a few things were changing recently (Website, pricing tiers, repo - for the better I find!). It is like Cloudron is gearing up for the next stage and it feels good to see.
Possibly I think it would also make sense to update the open source website page to reflect these repo changes.
Hi all,
It seems as Cloudron v8.1 is being pre-release with the following release notes:
Because this list seems to differ somewhat from the "What's coming in 8.1" forum post, I wanted to take a closer look to the release notes and note the differences, see what made the cut off and what has not.
However I seem to struggle to locate release notes for it.
Are these publicly available (I mean other then the popup when triggering the release)? If so, where to find them?
Furthermore, in the process of looking for these release notes, and while I know Cloudron is "source available", I could not find the actual source anywhere.
The following page makes mention of Cloudron Gitlab instance where one can find the app package sources, but I wasn't able to find the "Cloudron code" as mentioned here:
Am I looking in the right place ?
Any help is much appreciated.
In all case, many thanks for this further release.
Apologies for the revival if irrelevant.
I am just wondering if this is still on the map and if so, if there is any hint of time until release?
Many thanks,
Thanks for this - Email sent.
Not too sure what you mean from fuse sshfs, but from the cloudron server I can SSHFS and mount the remote storage backup location just fine, using the same/relevant subaccount.
Did you mean something else?
Hi @nebulon
Yes, it is possible to ssh into the storage box both from a local machine as well as from a Cloudron server.
Hi all,
This could be linked to symptoms described here but also maybe not.
This is happening on 3 out of 6 servers all on Cloudron v8.0.6 and Ubuntu v24.04lts:
on 3 servers I am unable to mount Hetzner backup (storage box via SSHFS). The error given in Cloudron is the following: "Failed to mount (inactive): Could not determine mount failure reason"
looking in the log of the 2 servers I see the following entries when trying to mount the Backup Storage:
ct 01 15:15:28 box:shell remountMount /usr/bin/sudo -S /home/yellowtent/box/src/scripts/remountmount.sh /mnt/cloudronbackup
[no timestamp] dependency job for mnt-cloudronbackup.mount failed. See 'journalctl -xe' for details.
Oct 01 15:15:29 box:shell remountMount: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/remountmount.sh /mnt/cloudronbackup errored BoxError: remountMount exited with code 1 signal null
[no timestamp] at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:122:19)
[no timestamp] at ChildProcess.emit (node:events:518:28)
[no timestamp] at ChildProcess._handle.onexit (node:internal/child_process:294:12) {
[no timestamp] reason: 'Shell Error',
[no timestamp] details: {},
[no timestamp] code: 1,
[no timestamp] signal: null
[no timestamp] }
Oct 01 15:15:30 box:apphealthmonitor app health: 2 running / 0 stopped / 0 unresponsive
Oct 01 15:15:31 box:shell getStatus execArgs: mountpoint ["-q","--","/mnt/cloudronbackup"]
Oct 01 15:15:31 box:shell getStatus: mountpoint with args -q -- /mnt/cloudronbackup errored Error: Command failed: mountpoint -q -- /mnt/cloudronbackup
[no timestamp]
[no timestamp] at genericNodeError (node:internal/errors:984:15)
[no timestamp] at wrappedFn (node:internal/errors:538:14)
[no timestamp] at ChildProcess.exithandler (node:child_process:422:12)
[no timestamp] at ChildProcess.emit (node:events:518:28)
[no timestamp] at maybeClose (node:internal/child_process:1105:16)
[no timestamp] at ChildProcess._handle.onexit (node:internal/child_process:305:5) {
[no timestamp] code: 32,
[no timestamp] killed: false,
[no timestamp] signal: null,
[no timestamp] cmd: 'mountpoint -q -- /mnt/cloudronbackup'
[no timestamp] }
So at the moment, I have 3 out of 6 servers not able to back things up.
Based on this, does anyone have any idea what is going on and where to find/dig up more info?
Thanks in advance for any pointers
@jdaviescoates I absolutely and entirely did.....
So clearly missed a step.
all working as expected now - Many thanks!
Hi,
Maybe I have missed something and if I have, apologies in advance.
However, I have just installed a fresh WordPress (developer) (package v6.6.2) on one of our Cloudron server (v8.0.5).
The user management was setup during the install to "Allow all users from this Cloudron" (so OIDC).
After install, I can log in fine with the default first time use admin user.
However, any other Cloudron user is missing from Wordpress, despite seeing the OIDC plugins in the WP dashboard.
Have I missed a step? or do the Cloudron user need to be created manually in WP before being able to login via OIDC (I thought not but......)?
Many thanks for the hints in advance.
Hi all,
I am coming back to this since one of my server updated about 3 days ago to from v8.0.3 to v8.0.4 and the same happened.
Upon updating the back to Hetzner storage box failed until manually remounted.
I do not see this as a DNS issue - the remount just work fine
I also do not see this as a Hetzner issue - the pattern is fairly clear: it happens every time there is a cloudron update since v8.0.0 (I think).
Not a massive issue since the remount does the trick.
But as the failing notifications are only sent over email after 3 fails, it can potentially lead to a fair amount of backups being missed.
@any ideas?
Just to confirm that this is not an isolated case, since the same happened to some (not all) of my box.
Solution was indeed to remount the backup storage manually.
Should this help, I have had it happen with v8 and v8.0.2 so far, on multiple servers, but only with Hetzner storage box.
@girish This is very nice of you. Here are some packages that we would love to test:
Many thanks,
@girish Hi girish, with v8.0 "out of the way", I am wondering if the env variable mentioned above was already integrated in (some) app packages?
Looking forward to testing this.
Many thanks,
@joseph said in issue with update to 1.6.6?:
@uwcrbc said in issue with update to 1.6.6?:
I am also wondering why the logs are showing a time that is neither the one set in the Cloudron server settings nor the one from the server.
Cloudron server time is always UTC. This timezone is an implementation detail but it's easier if all logs and db fields are in standard time.
Cloudron Time zone is used for cron job schedules (https://docs.cloudron.io/settings/#timezone)
The times you see in the UI like the logs, eventlog are from the browser timezone . So.. I guess your browser is in UTC+1 ?
This also makes sense - I have a fairly locked down browser security wise, which explains the difference between local time and the time displayed in the browser.
I will try to remember this.
Many thanks again @joseph
@joseph Thanks - Despite me checking (or at least I though I had and more than once) it was indeed a backup storage location which was not properly mounted.
Remounting fixed this.
It would indeed make more sense if the log entry was mentioning the update abortion, but it is a minor thing since the notification for updating always remain until the update is successful
Thanks again.
A complete minor thing that I stumble upon randomly in checking a few things.
At the moment, in the list of language one can set Cloudron to, there is a "lang.id" value which is selectable:
As far as I can tell this is present in both 7.7.2 and 8.0 , I do not know about earlier release.
Switching to the "lang.id" value does not reveal any secret language at last 
!