@andreasdueren said in LDAP authentification for Macintosh: But when the IP is not whitelisted, it just keeps going and is not getting closed. So strange. The behavior should be the exact opposite! Not sure what to suggest anymore, maybe you can write to support@cloudron.io and we can try to debug.

So I've tried several times to restore the apps and everything is fine.

By now the internal IP for mysql is hardcoded to 172.18.30.1 so this command is not required anymore: https://docs.cloudron.io/guides/connect-mysql/#internal-ip-address

@dsnradio at this point, no. You can maybe try the previous version of Cloudron. You can run the setup script as cloudron-setup --version 7.5.2. But please be aware that you cannot upgrade.

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