Cloudron Forum

Seconded, also interested in this for the tailscale angle

Nothing obviously related in there. And sure, just figured I'd drop a report in case it was important.

Also, now I think of it, Cloudron's disk is separate from the backup disk altogether..

Hmm, disk wasn't full though, just not big enough to hold the backup. And on Cloudron itself, the notification had the right info

On v8.0.6, I ran out of space for backups. I got email notifications about it (good), but the email body was empty. It might be nice to give a reason for the failure there so I know how much to panic about it (or not)

Subject of the mail was: "[Cloudron] Failed to backup"

Possibly relevant: https://community.home-assistant.io/t/sonos-no-sonos-devices-found-on-the-network/205049

First things first, thanks so much. I've wanted to play with HASS for a long time, but never really felt comfortable with running it myself, because it's quite... involved

I've set it up, and things seem to work remarkably well so far, with one exception. I tried to add a Sonos integration, but it doesn't seem to be able to find my system.

The documentation (over at https://www.home-assistant.io/integrations/sonos/) has a mention of Docker networking specifically, so I wonder if this might be something that needs some more tweaking/customisation in Cloudron.

I tried allowing port 1400 via ports.json, but so far, without success... Maybe there's some more firewalling blocking things (i.e. mDNS reply or something like that), not yet sure.

Just opening a thread so it's tracked, anyway, I'll update if I figure anything out.

@joseph Right, I get that. I got the option to update all my other installs a while ago, but the weird thing is that I didn't for this one, and I still can't see a way to update this one anywhere that works. I don't care what the PHP version is (I don't even use PHP), I'd just like to keep it current.

I have a few different LAMP installs. Today, I noticed (because one of them has a different, older icon) that one of them is running an older package version for some reason. Automatic updates are enabled (but obviously not working), and manually checking for updates doesn't seem to do anything either.

Is there some way I can fix this without migrating everything over to a new app install?

Old app details:

Package Version
lamp.cloudronapp.php73@2.0.0-1
Installed At
09/11/2020
Last Updated
Never

A sample from a newer one:

Package Version
lamp.cloudronapp.php74@4.0.0-1
Installed At
02/10/2021
Last Updated
07/29/2024

Aha, you were right actually.. Noticed some other quirks around DNS (most noticeably, it was repeatedly failing when I was ssh'd in). Turns out that unbound isn't very happy when something else above it hijacks DNS traffic (which I'm doing to filter our junk).

Quick fix for now was to add a forward-zone to unbound, but I wonder what the right way to handle - and detect - this is...

Yeah, it's green. I was fiddling with switch config a few days ago which I think was the cause in this case.

I noticed at some point an app I don't use very often failed to update. I noticed this because it wasn't running, and was in error state. In the repair section of settings, I saw this:

The update operation failed with the following error:

Network Error: Network error downloading icon : getaddrinfo EAI_AGAIN api.cloudron.io

My guess is that I had a network outage at some point at just the wrong time while the app was trying to update, and this then caused it to hang in that error state permanently.

Perhaps this sort of transient failure should (automatically) schedule a retry later on?

@girish yeah, well, since when has following the rules ever been fun?

I would guess that they say that because if your actions misbehave, or want to, they can interfere with the running gitea instance, so yeah, a separate host would be nice. but I don't know if cloudron has the ability to provision multiple containers for a single app?

tried to play with it a bit. enabled actions in the ini, as documented here:

https://blog.gitea.io/2022/12/feature-preview-gitea-actions/

installed a runner binary from the link here:

https://gitea.com/gitea/act_runner (just to try get up and running quicker..)

placed it into /tmp/ on the gitea container, chmod +x, ran it. could successfully register the runner.

actually executing actions seems to fail, because by default, it wants a docker connection. looks like this can be hacked out if one builds a runner by hand:

https://github.com/nektos/act/blob/636c8a34aedf9b6251df6729fe673d828f972030/pkg/container/docker_stub.go

... obviously, at the price of having no docker available to the actions, which mean some won't work.

but the docker hurdle aside, this is so easy to set up it that it might be worth exploring as part of the app's package..

looks really exciting, if it works well

@nebulon said in OpenHAB not starting after installation:

gosu cloudron:cloudron /app/code/runtime/bin/karaf daemon

Weird.. When I ran /app/pkg/start.sh in recovery mode, I got this:

==> Ensure directories
==> Changing ownership
==> Starting OpenHAB
Killed

When I started the last command by hand, it actually seemed to run okay (at least, no output, and it didn't get killed...

I had a hunch that maybe it was getting OOM killed, and sure enough, I raised the memory allocation to 512m, and it now seems to start successfully, so maybe the default allocation (256m I think it was?) is just a little too low to start, sometimes?

I've installed it, but in the dashboard, it stays in state "Starting..." and the web UI never comes up. Running Cloudron v7.3.4 on 20.04.1 LTS.

Logs says this (in a loop), unfortunately, without more details:

Dec 12 22:20:28 ==> Ensure directories
Dec 12 22:20:28 ==> Changing ownership
Dec 12 22:20:28 ==> Starting OpenHAB
Dec 12 22:20:34 ==> Ensure directories
Dec 12 22:20:34 ==> Changing ownership
Dec 12 22:20:35 ==> Starting OpenHAB
Dec 12 22:20:42 ==> Ensure directories
Dec 12 22:20:42 ==> Changing ownership
Dec 12 22:20:42 ==> Starting OpenHAB
Dec 12 22:20:51 ==> Ensure directories
Dec 12 22:20:51 ==> Changing ownership
Dec 12 22:20:51 ==> Starting OpenHAB

@girish said in Incorrect error when removing an obsolete alias for a service:

Did you happen to set this up manually?

Hmm, I don't actually know. It's not impossible I guess...

Good to know though, I'll work on cleaning DNS up

For the record, it did actually remove the alias, so I think the only confusion here is the unexpected extra presentation of an error message.

I had an app hosted at, let's say, "foo.bar.com". It had an alias for "barfoo.net", which was an old domain that subsequently has expired. Today, I tried to remove the "barfoo.net" alias by just trashing it and clicking save, but got an error:

An error occurred during the location change operation: Already Exists: DNS CNAME record already exists

The CNAME that already exists is for "foo.bar.com". It doesn't seem correct that this is an error, since the CNAME it is complaining about was already set up by Cloudron. All I wanted to do was to remove the alias, not also change the location of the service.

(Running Cloudron v7.3.2, using Hetzner DNS if it matters)