This will eventually catch up. By design we do not actively track the servers of our users, so that info only comes in as the Cloudron checks for updates.

Thanks a lot @girish !
We're running mattermost under the indicated domain. I have disabled the outbound, since we have an external SMTP server running - it works now!

I didn't know that Cloudron overwrites configs, but well: Lessons learned 🙂

thanks for the report, we will fix that up then for next release.

@girish said in Disk usage issue:

https://git.cloudron.io/cloudron/box/-/commit/67cde5a62cf0394c8bf2d78ee3408e5995a220e7 is the fix if you want to patch it yourself.

Thanks, I wouldn't know where to start with that, but I guess useful for others who do 🙂

@girish I was a little impatient, it's back. Thanks

@girish So the problem was really with the encryption. Now the backup goes through Rsync without problems. Thank you very much for your help, I think the thread is solved 🙂

@d19dotca yeah, when files move around, the modules we use for file listing is not very good at handling things. I suspect it will work fine again/tonight. I am reworking the backups code to use a different module since we have had issues with apps like owncast as well which move around files a lot.

@natzilla Ah ok, I think I will improve the docs to say how to exactly recover if mysql is not even running. The troubleshooting guide assumes mysql is running but corrupt.

I got this one on of my cloudron installs and I just rebooted the server and that solved it.

Seems like something just needed to get "unstuck", but the issue was that the services were not starting properly.

@girish said in Some problems with API - PUT user in groups:

{"groupIds":["gid-3e96c503-d30f-4db8-aa37-ecaf98fa33fa"]}

Thank you, works fine. It was a spelling-error in the "content-type" .

Hi @girish.
Thanks for your quick response.
I use a manual domain, so it seams I have to update IP's manually.
To bad but thanks.

@girish said in Cloudron 7.3.2: "Analyze Disk" doesn't do anything:

The code is not handling CIFS/SSHFS volumes correctly.

was not, is now?

@d19dotca
We got improvement after the 500 mail for day, feed to our ML filter, BAYES normally need less information, but if you don't have enough fresh data it will always be too late.

@odie said in Fix for kernel bug in Ubuntu 20.04 causing various issues:

n the quoted line, there should be quotes around the "Advanced options..." line.

@girish sounds like that needs to go in your reverse instructions in the post at the top - your commands there don't have the quotes.

@prusaman If the instance has no IPv4, how do you ssh in ? Via a jump host?

@girish I didn't install anything, but I might have upgraded from 18 to 20 at some point as well as @Neluser did.

dpkg --configure -a resulted in dpkg: error: dpkg frontend lock is locked by another process, so I restarted the machine after all and updating worked fine.

Before that I killed the dpkg process and tried to run it, which resulted in that:

dpkg --configure -a Setting up grub-efi-amd64-signed (1.173.2~20.04.1+2.04-1ubuntu47.4) ... debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable dpkg: error processing package grub-efi-amd64-signed (--configure): installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent processing triggers for shim-signed: shim-signed depends on grub-efi-amd64-signed | grub-efi-arm64-signed; however: Package grub-efi-amd64-signed is not configured yet. Package grub-efi-arm64-signed is not installed. dpkg: error processing package shim-signed (--configure): dependency problems - leaving triggers unprocessed Errors were encountered while processing: grub-efi-amd64-signed shim-signed

Either way, solved not in the most elegant way, but solved 😄

@johannesjom generally it is not supported to install other things via apt manually. There are some warnings about this when you SSH into your server, but we can't quite prevent users who have root access to their own server to install things or also change essential config files. So not sure what we can do here besides warning the user.

@bcdodgeme this usually only happens when the server runs out of disk space.

The issue here was that unbound was not working. Because of that, all the docker image updates are failing like so:

2022-12-06T03:38:02.801Z box:shell startGraphite exec: docker run --restart=always -d --name="graphite" --hostname graphite --net cloudron --net-alias graphite --log-driver syslog --log-opt syslog-address=udp://127.0.0.1:2514 --log-opt syslog-format=rfc5424 --log-opt tag=graphite -m 429916160 --memory-swap 536870912 --dns 172.18.0.1 --dns-search=. -p 127.0.0.1:2003:2003 -v "/home/yellowtent/platformdata/graphite:/var/lib/graphite" --label isCloudronManaged=true --read-only -v /tmp -v /run "cloudron/graphite:3.2.0@sha256:182e5cae69fbddc703cb9f91be909452065c7ae159e9836cc88317c7a00f0e62" Box GET /api/v1/appstore/apps?repository=core 424 Failed Dependency getaddrinfo EAI_AGAIN api.cloudron.io 10.852 ms - 89 2022-12-06T03:38:03.581Z box:shell startGraphite (stdout): null 2022-12-06T03:38:03.581Z box:shell startGraphite (stderr): Unable to find image 'cloudron/graphite:3.2.0@sha256:182e5cae69fbddc703cb9f91be909452065c7ae159e9836cc88317c7a00f0e62' locally docker: Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: server misbehaving. See 'docker run --help'.

It was hard to figure why unbound is not working, all queries fail with ESERVFAIL (VM, Hyper-V, router, many things here). It's some networking related issue hard to diagnose without getting a full hand on the setup. The workaround was to add a file called /etc/unbound/unbound.conf.d/forward-everything.conf with the following:

forward-zone: name: "." forward-addr: 1.1.1.1 forward-addr: 8.8.8.8

Then, systemctl restart unbound . After that, host cloudron.io 127.0.0.1 should work.

Finally, systemctl restart box will then bring up all the containers again.

@girish said in Delete Local Backups:

Documented at https://docs.cloudron.io/backups/#old-local-backups

small typo there

s/snapshots/snapshot