@nebulon Thanks. Ohh, I was so close last night. Your post gave me the courage to plunge back in. The username I gave to the user who owns the policy was a really wierd choice several years ago. So when I went to the aws users page, I didn't think of exploring there. Also the ID and secret were in a file on my local machine, filed well with a good file name. Last night I just wasn't careful in looking for it. So I'm all good now.

I figured out the issue - posting here for anyone who encounters the same... I had not whitelisted my new server's IP address with my registrar (Namecheap). Once I did this, installs and uninstalls are now working. The error was actually an external error passed from Namecheap, not an internal Cloudron error message

That's the last thing I would have expected... thank you for finding this out!

The preserving of the file permissions is now also fixed for next release.

@ccfu right... if DNS is not mainained by Cloudron, we have to show some message/alert the user. This requires some work, this is why this feature is not done yet It seems like quite some work for very little value.

Thank you @girish - yes. that worked! I can sftp into the app And i am so glad you took the time to review and fix the issue.

Got it thanks.

We mostly rely on the spamd default settings, those are not easy to get right on a generic level. On my personal Cloudron I have tweaked those with great success, but mileage may vary. In my case I have raised the score for some bayes rules to give the learning more relevance. You can try this on your instance by putting the following content: score BAYES_999 2.0 score BAYES_99 4.5 into the file /app/data/spamd/custom.cf in your mail containers data folder, via SSH onto your host server the shell session is: docker exec -ti mail /bin/bash root@e05ce221283c:/app/code/haraka# cat /app/data/spamd/custom.cf score BAYES_999 2.0 score BAYES_99 4.5 root@e05ce221283c:/app/code/haraka# Then restart the mail container via the services view in your Cloudron dashboard. As said though this may also result in mails landing in spam which are legit for your cases.

alright, i have just tested the feature, and it works. thanks

Ahh yes! That makes perfect sense @nebulon ... and I feel rather silly for not taking that into consideration. It should have been the first place that I looked - because indeed the subdomains rocket-chat, and mastodon were pointing to the old server still. Therefore, there is nothing more to be assessed or figured out here, because you have helped me to solve the problem. I am taking the old server offline, and setting up the apps within the new host environment - as it seems this was much ado about nothing!

Fixed with https://git.cloudron.io/cloudron/box/-/commit/c3574614bc074750864b2e0424494a4cb58778e9 for next release.

@MooCloud_Matt I think you can just use "no-op" in your situation and also use a custom wildcard certificate. The proxy can then accept just that wildcard cert. no-op ignores DNS checks. The cert can be Let's Encrypt or not depending on if your proxy can carefully forward well-known HTTP requests.

@Jeyakumarrathnaselvi services -> redis -> restart it. I think you should be able to restore after that.

@girish Thanks, will try this !

I think we have to 100% move to auto-generated passwords for the initial user in apps from the next release. We will make this a priority.

@rbin saw your ticket on support. I sent you a response there.

Glad it all worked out

@girish alright, thanks a lot. Always useful to learn more about the things we use I did what you wrote above and now everything works just like usual If disk issues keep on happening, I will have to get in contact with the provider..

@nebulon thanks a millio! it works now, i am going to proceed with the update to the ubuntu 20.04.

This is fixed already with https://git.cloudron.io/cloudron/box/-/commit/5fc0a5f9a28be601bcec2e3bcf68fc93f3b3e8c5 but only part of next release.