@girish that’s perfect, great detective work! Thanks Girish for working to solve that. I really appreciate it. I’ll keep an eye on it in my server you patched and see if the issue comes back. Thanks again!

@nebulon My pleasure, one of my superpowers.

I see. Maybe that's because mailtrain adds unsubscribe headers in the email header etc. I don't really know of any other bulk mailer software. Are you able to contact the support of turbo mailer and ask them if they support STARTLS at all?

@scooke Yes yes, that's how it's supposed to work, correct. It doesn't work that way with Wordpress Multisite. You change the domain on Cloudron and the whole app breaks. I'll be fixing that in a future update to the Wordpress Unmanaged App package tho since that's the app I really want to work on. ️

@mehdi That’s exactly what I’m going to do. Thanks for pointing me in the right direction. I will do a merge request post 6.0 for first-class official Multisite support; I’ve got a list of 4 things to change to support Multisite now - I’m hoping I can get them all done in 2021! ️

@nebulon That's not to say that I don't think Cloudron shouldn't receive webhooks for other reasons. I'm surprised you aren't using them for your multi-cloudron dashboard actually (to update the status of "subcontainers" from all servers instantly).

I gotcha, I'll post again about it next year to see if there's interest. It's cool that the mail server's "my" was made optional. I'm glad you're open to revisiting this later because, maybe I'll have gotten so use to it by then that I won't even request it again.

@nebulon Oh, I have no intention of moving from the cloud and have no reason to run it at home. It would just make my development flow for the OpenVPN Client app I'm working on faster since it'd be localhost (my everyday work laptop). But, like I said, due to the way you guys designed cloudron build and cloudron update, it's actually pretty fast even in the cloud. One of my favorite aspects about your platform so far - ease of development. So I'll just keep doing that...well, I guess I could keep switching it back and forth, developing locally and then seeing how it performs in the cloud after the app is finished. I don't use Cloudron for anything production related right now, I'm just happily building apps to see how far we can take this platform.

@jdaviescoates said in Ubuntu Reboot to install updates left some Apps not responding: It is even possible for them to show as Not responding in the Dashboard but for them to actually be running? Yes. The 'Not responding' is simply based on a periodic health check. This can fail because of two reasons: a) some internal bug that is causing cron job to check health not firing. and b) the health check route of app returns a non-2xx http code. this can happen if your app is totally "protected" like say an auth screen on the main page with a 401/403 status. In the above two cases, the app itself is actually running and can be accessed from the browser but the dashboard will say 'not responding'. a) is a bug and b) is more of a Cloudron limitation, I think (this happens often in LAMP apps).

@jdaviescoates said in Nextcloud says 5.3GB used, Cloudron says Nextcloud is 19.16GB, why?: That's "just" a difference of 2.66GB (which I guess could mostly be just Nextcloud files themselves) So, assuming that is mostly just Nextcloud files themselves (I may do a clean install at some point just to see how big that is), I think this can be marked as solved.

OK, that wasn't the issue. We have an issue with the Cloudron 5.6.1 release that http://ip will serve up a random app. This is because we ended up removing 'default_server' and the nginx behavior is to serve up the first server it finds. Not the end of the world, but not nice. This issue has been fixed now. I thought the above was the reason you were getting served up some other app when you put an app in repair mode. I tested it now, but this is not the case. If you can duplicate this and let me know, I would like to have a look.

I can confirm that, now that the lifecycle settings are correct, backups get physically deleted from B2.

@andrewj720 Looks like DNS is not working on your server. You can also try host cloudron.io etc, I guess none of it working? Can you check if your cloud firewall allows outbound port 53 UDP ? I think there was a post on this forum some time ago that someone had it blocked in AWS security group by mistake, for example.

In Cloudron 5.6, we added a way to whitelist additional incoming ports - https://docs.cloudron.io/networking/#whitelist-ports

@d19dotca You can try https://git.cloudron.io/cloudron/box/-/commit/3c565defca000feb21c47e9d8c9ada4c62c11cef and then systemctl restart box. Alternately, you just use the docker CLI until the next release: usr/bin/docker update --memory 805306368 --memory-swap 1610612736 mail The containers are named mysql, postgresql, mail, mongodb.

@gml said in SSL error after upgrading to 5.6.0 on ubuntu 16: That seemed to solve it, even if a server reboot did not solve it. I also got a mail, that this was also visible from other mail-servers (not just from my mail client), as I use DANE for certificate pinning. Thx girish! I had the same issue. And the same fix. A reboot didn't work, a service restart did the trick. Thanks!

Done. I also made a change now where that ghost file is automatically removed after you use it once to login. Just in case, people forget to remove it.

@marcusquinn said in Lets Encrypt renewal time: Without looking at that screen again, maybe it wasn't clear it should recommend using the root domain for that input? I think many people start out just like you did and then move it to the main domain. We don't put the recommendation as such because I think it can be scary to throw your root domain and API credentials into a product you are just first trying out.

Those sync.cache files are state files of the rsync backup uploader. That has to run as root to be able to list and read the app's files, the app file permissions here depend on the app itself and how it manages permissions. The yellowtent user as such does not have root rights on the system and uses helper scripts in such cases. The list of scripts which need and thus run with elevated permissions can be found at https://git.cloudron.io/cloudron/box/-/blob/master/setup/start/sudoers