@81ewlska you can send a mail like this: Get mail server container IP - docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mail Get relay auth token - docker inspect -f '{{range $index, $value := .Config.Env}}{{if eq (index (split $value "=") 0) "CLOUDRON_RELAY_TOKEN" }}{{range $i, $part := (split $value "=")}}{{if gt $i 1}}{{print "="}}{{end}}{{if gt $i 0}}{{print $part}}{{end}}{{end}}{{end}}{{end}}' mail . Don't ask me how this works, I stole it from Stack overflow But essentially, CLOUDRON_RELAY_TOKEN is an environment variable in the container. You can also get this from docker inspect mail | grep CLOUDRON_RELAY_TOKEN and do some string manipulation. Then, send mail (example.com below is your primary domain): swaks --server <mail_server_ip> --port 2525 --from no-reply@example.com --to test@cloudron.io \ --body "Test mail from Cloudron" \ --auth-user no-reply@example.com --auth-password <relay_token> Note: above only works from the server itself. You cannot send mails from outside the server using a token.

Cheers, yes I've added the r8125 module to that now. I'll see what happens next time I need to restart. I haven't had to either, must be my cheap hardware choices biting me in the ass.

@savagemic ok, so this has to do with Cloudron box code not starting up and not to do with installation. Can you please check /home/yellowtent/platformdata/logs/box.log ? The start up is getting stuck somewhere. If you can write to us on support@cloudron.io we can debug this quickly.

@Advika58 Are you a bot?

good question...I had yunohost before...they did recommend to install the CAA record. I think, that is the reason.

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