Cloudron Forum

@timconsidine You are so right. The best day for Team Cloudron is one in which there are no updates. I give @girish @nebulon @joseph an enormous amount of credit for the job they do. As someone who rolls out ~ monthly updates to users, every time that happens I pray that me and my team didn't miss something important. But it happens to all of us, despite good processes and best of intentions. But 8.3 will be replaced shortly with 8.3.1 and then 8.4 and then 9.0. And this difficult day will be replaced in everyone's memory by the great things that are yet to come!

I could not let go if it, so I kept digging a bit. I had previously reset the memory limit back to its default, but bumped it to 6gb now for another test. This time the restore of Nextcloud went through. So now everything is operational again (and I also cleaned out some apps that had errors, but I was not using anyways anymore). To get back to a working state I needed to restore each up using a postgres database to the state from before the upgrade to 8.3.0. Else the app would have no data in their databases (Mastodon users and toots gone, Matrix rooms gone, for example).

I will leave this question as unsolved.

@Gengar Oh amazing, thanks for sharing the detail. That's an interesting choice to keep on top of all the notifications.

@joseph said in Two annoying issues after updating to 8.2.3 - seemingly both solved by rebooting my server: The second one is more confusing because the volume in use comes from db afaik (not sure how a reboot sorts db constraints!). The volume was in use. The problem was another volume just wouldn't mount. But as both the working in use mount and the not working mount were actually both mounts of the exact same Storage Box I thought perhaps removing the in use mount would help. It didn't. But after a reboot the non working mount mounted fine again. (although I guess it's conceivable this also had something to do with the other mount no longer existing - but I doubt it given both mounts seem to happily exist together pre update to 8.2)

Thanks, @nebulon—this worked!

node.js has a "happy eyeballs" quirk. This causes premature network errors when there is no ipv6 and ipv4 is slow. I have fixed this in https://git.cloudron.io/cloudron/box/-/commit/aefa481c43603d284346d58497b6ff5b462efd88

As far as I understand those CVEs they are not relevant in that context. For the first, we don't use those affected configs and the second is for the ssh-agent. Given that the Ubuntu team usually knows what they do and are working closely together with upstream projects, there seems no need here to go beyond their recommendations of versions they push out via security updates.

@joseph , Running 'cloudron-support --recreate-containers' fixed the issue. Thank you.

Happens a LOT I don't mind at all.

@nebulon a checklist of current apps will be ideal scenario

@Beardmancer said in Failed backups and email config issue since 8.0.3 upgrade: I decided to go ahead and try adding this to /etc/systemd/resolved.conf since it's easy enough to comment out. DNS=8.8.8.8 1.1.1.1 After doing that and restarting the service with systemctl restart systemd-resolved, things seem to be working correctly. The file /etc/resolv.conf lists nameservers now and a manually-initiated backup just completed successfully. Thanks for the hlep @nebulon ! In the future, is there anything I should look out for to avoid this? I don't know what caused it. Maybe it was the 8.0.3 upgrade, or maybe it was an Ubuntu update? I think I rebooted Cloudron for the latter recently. If there's a configuration I might have setup wrong, I'd love to correct it.

@imc67 8.0.3 is needed

Thank you!

It did turn out to be a DNC issue which Joseph at Clourdon support fixed and then created a backup.

Sorted out on support. This had to do with some efi package blocking apt updates and thus the update stopped mid way.

I guess that is solved via https://forum.cloudron.io/post/95877

@joseph Thanks, that was it! It's all working now.

For the future generations: better do ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf to avoid messing with system's and cloudron settings Or use netplan's WireGuard capabilities.