There were a bunch of dangling images. Deleted those. Update failed because you no longer use AWS (....lol), but after https://forum.cloudron.io/post/59939 Update is complete. Well, 5 or 10 updates. Hey, everything kept working for years...! Surfer installed successfully. Thank you for your help! Note to anyone doing this in the future: the updates will result in a lot of backups (which can be removed via the web interface or at /var/backups) and a bunch of dangling or unused docker images which can be removed with docker system prune or docker system prune -a

@userino you should also put that in /etc/sysctl.conf to make the setting persistent across reboots.

@girish yeah, i did that.

@joack said in Cloudron partial install but server seems active: I tried installing it on my recently updated ubuntu20.04 desktop As others warned, don't do this! It's not meant to be run this way. You can create a VM on your desktop and install it in the VM though. The error itself is happening because you probably are using MySQL already and this is conflicting with Cloudron installation.

So, these errors are caused by the remote server. The XML error is returned by the AWS SDK in response to some remote error. Unfortunately, there is nothing much we do on Cloudron side to fix this.

For the app tasks, an 'x' button will appear on the right of the progress bar after 3 minutes or so. It's like this because once you cancel the task, you have to go to the Repair tab to bring it back up. We didn't want to show an 'x' immediately and complicate things.

Might not be limited to „lock“ files: Today I had a similar error (first time ever!) du error: Command failed: du -Dsb "/home/yellowtent/boxdata/mail" du: cannot access '/home/yellowtent/boxdata/mail/vmail/[REDACTED]/mail/dovecot.list.index.log.2': No such file or directory

Always check the CPUs via cat /proc/cpuinfo | grep avx

The mysql command should work as such, what error do you see?

@nebulon I do and thank you – sending e-mail as we speak.

@THI_Staff Apologies for a late response on this. I haven't used this yet. I was grandfathered on some free monitoring elsewhere. That being said, some of the delivery reports tell you servers that attempted to send email on your behalf. That has helped me resolve some delivery issues where others were sending legitimate emails, but using one of our email addresses instead of theirs. That tripped a DMARC fail. I would start their service without and then see if you want more.

@matix131997 my understanding is that issuance from E1 requires whitelisting of your LE account - https://letsencrypt.org/certificates/ . This is why ISRG Root X2 is still limited availability.

Can you try pulling that image manually using docker pull registry.docker.com/cloudron/g raphite:3.4.2@sha256:bc30121baecfa887856de56278fca5a532543c8ff439b60dc178132d578 ?

@girish hello, how are you? thanks for the tip I will move the post to another thread

If you want to receive email, you have unblock incoming port 25. If you just want to send emails, then use a relay as @jdaviescoates suggested.

@girish thanks that worked

@pixeltablet as long as the DNS settings are copied over to cloudflare, everything will continue to work. You can also make Cloudron add the DNS entries into Cloudflare by first switching to cloudflare and then sync DNS - https://docs.cloudron.io/domains/#sync-dns . Just so you don't hit any DNS issues, you can add the 'my' subdomain record manually into Cloudflare.

I thought I would just restart the server in case that fixes things after the weekend. The dashboard came up and I was able to start troubleshooting the unresponsive apps. I guess this is one of those things that cloudron fixes itself with those health checks. Thanks

... or even in the docs (which are, by the way, excellent!)

Thank you, that has solved the problem!