Cloudron Forum

Hello @davejgreen said in Minio region issues after cloudron updates: Receive another Cloudron update and repeat. Do you mean this is the case for every Cloudron udpate, not only from Cloudron 8 to Cloudron 9?

@archos said in Old system backups are not listed: and restoring an older app backup fails with the fsmetadata.json ENOENT error. Does this file exist in the storage?

@Beardmann coffee. Drink coffee. Helps me.

So turns out that potentially the issue is disk space. we ran the process again without changing anything - same result we clean up and enable at least 40 GB of space and relaunched the update process = successful update suggestions: better pre-update space check and verbose messaging about needed space for update

Ok, based on the box.log file I got a LLM/Claude debug session going and it was pretty quick showing me, that there was a docker container (postgres) running that was attached to the Cloudron Network, but not managed by Cloudron. I think that was something I set up super early, before I understood how Cloudron works. Claude helped me dettaching it and now the update went through without issues and everything is running again. Thanks for the hint with the box.log file @joseph !

@smitrparikh 8.3.2 is the latest stable version of Cloudron . If you are asking about Cloudron 9, it is being rolled out slowly. The update will appear in the coming weeks.

Handled via support ticket

Done via support

I have just freshly reinstalled the app, because I ran into the issue. However, although the port has been set to 25000 automatically, I still have the issue.

This is implemented in https://git.cloudron.io/platform/box/-/commit/d7fdfd6d71c403f343f2e37dfc988f2c5a120898 . The app object now contains updateInfo . This has two fields isAutoUpdatable and manualUpdateReason (added in https://git.cloudron.io/platform/box/-/commit/84297ff473d6c0c100d2597e425c7edfe9481f8f)

@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 finally got to the bottom of this. Fixed in https://git.cloudron.io/platform/box/-/commit/fb39aa32bb0017b64af9c238fb81ba256862ecbb

I use netcup too, I disabled IPv6 on the server entirely and since everything has been working with no issues. Though disabling IPv6 persistently on reboot was not straightforward and had to be done modifying netplan config, see above on the thread (https://forum.cloudron.io/post/102554).

@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.