This was because the upgade to mysql didn't complete. apt --fix-broken install completes the upgrade. I guess ubuntu upgrade was somewhat midway? I think https://docs.cloudron.io/guides/upgrade-ubuntu-20/#post-upgrade (though the server was already in Ubuntu 22). After that the update worked.

@corevoid I guess this is dup of https://forum.cloudron.io/topic/12327/ldap-not-starting-after-8-0-3-upgrade ?

@ramiroro If you do systemctl restart box, you will something like this in box.log 2024-08-20T19:07:19.792Z box:directoryserver starting server on port 3004 lsof will show the listen # lsof -n -i :3004 | grep LISTEN node 78452 yellowtent 26u IPv6 517617 0t0 TCP *:3004 (LISTEN) check the rediect from 636 to 3004 # iptables -t nat -L | grep 3004 REDIRECT tcp -- anywhere anywhere tcp dpt:ldaps redir ports 3004 test with telnet my.domain.com 636 . Note that if you are behind Cloudflare this won't work.

@girish One thing to note, all stopped apps where not imported through the restore method even tho they had backups retained with them. We are still trying to find and recover those apps atm, but they must be buried in a random 2024-04-08-030000-684 folder. Never the less. Is it possible to recover data from the snapshot folder? what is that for if backups pull from the other folders? I think our stopped apps are in there but Im not sure how to recover them through the front end that way. One thing that would have made this process so much more seamless is just including that restore config file in the snapshot folder, and the corresponding configs for each app backup, would have saved us hours of finding the correct backup id manually for each method, since Im assuming they are slightly different?

The issue was that docker got stuck in removing the Cloudron network during the starting after the update. Not clear why and when this happens but stopping docker then running docker network rm -f cloudron manually (which will start docker due to socket activation) makes it work...

@matix131997 My freescout app is the one that crashed I think and it's around 1GB only. I have backups disabled for my Nextcloud because I'm pretty sure it would never finish the job within a reasonable time even if it didn't crash.

Edit: fixed. I found docker.service inside /etc/systemd/system/multi-user.target.wants/ I didn't get this to happen: "Then, systemctl start my-disk-mounter would automatically start docker and box." But that's ok. I run a manual startup script that prompts for the encryption password, mounts the disk, then starts all the systemd services. Instead of my-disk-mounter.service, I have check-that-all-disks-are-properly-mounted.service which is Required by box and docker. Thanks again.

Thanks for sharing . Right... our current domain/location configuration follows an all or nothing approach. If one or more fail, it will refuse to bring the app up and will get "stuck" forever . We have a task somewhere to make this more smart and also make the app repair feature smarter but it always gets pushed out as low priority.

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

Oops nm I figured out the right Wordpress login url and redirect pattern to use

Thanks, it's working !

Just tried to reproduce this with Cloudron 8 again and it seems to be fixed now.

@dsp76 this was a bug in 8.0.x release . It's already fixed . See https://forum.cloudron.io/topic/12254/edit-files-using-the-file-manager-changes-their-ownership-why/ and https://forum.cloudron.io/topic/12203/config-php-permissions

@bennyv53 the SSH key is the key to login to your server. How do you ssh into your server? There are two common modes to auth with ssh - with a password or via key . For example, ssh root@my.tee.digital . Do you enter a password here ? Or does it automatically log you in without a password (most likely ssh key based if that's the case).

Indeed, after sync I enable the IPv6, the app store works just fine as well as the current apps running, i test a few other case this also resolve issues with sometimes the manifest of the updated apps not shown From my experience, don't syn the DNS while having the IPv6 Networ Enabled in Cloudron if no AAAA records in apps or domain I don't know if it happens to anyone else using the Cloudron version 8.x but since I set my networks both work with IPv4 and 6, and it seems everything works normal

@joseph Thanks for this! I was trying to wrap it up last night so I decided to just reset all the users passwords to a known password, and then send them a password reset link to change it to their old password on their own. I will definitely keep the group approach in mind next time I'm migrating to Cloudron - but my next server likely won't migrate until XMPP gets some love ( https://forum.cloudron.io/topic/10465/xmpp-server-prosody/26?_=1723504540984 )

Thanks for clarifying!

@awestenb it means that IPv6 record is not set up. try host -t AAAA my.domain.name . This should be the ipv6 address of you server. If your server does not have IPv6, then in the cloudron setup page -> advanced -> disable ipv6.

Thanks for the report, this is fixed for the next release.