@girish Sorry for the delayed response. My server is also hosted in Singapore (by Hostinger). I've noted a couple of seconds delay to open Cloudron's app store but it is definitively back. Thank you again for the support 🙂 !

no sorry. Just coincidentally having a similar issue with backups, at the same time I think. I can see why you'd think that, I kind of jumped into the conversation.

I have changed the error message now to this:

image.png

Ah, thanks! I hadn't seen the app-mail-folders before. 🙂

Got this reply from Storj @girish @nebulon

Could you change some settings in this software to use a delimiter for prefixes? By default it's `/` (a forward slash). Without delimiting you will hit the listing limit if you would use S3. As an alternative you may use a native Storj protocol, it doesn't have this limit, but I'm not sure that you can use it in this software. What's supposed to do? if backups, then I can suggest to use a normal ones, who can use prefixes correctly (and may reduce your storage costs by using a larger segments (less or equal to 64MiB)): [https://docs.storj.io/dcs/third-party-tools#backups](https://docs.storj.io/dcs/third-party-tools#backups)   Our S3 compatibility you can see there: [https://docs.storj.io/dcs/api/s3/s3-compatibility](https://docs.storj.io/dcs/api/s3/s3-compatibility) However, there is a limitation, how much objects you can list using the not limited prefix (like a prefix without a trailing `/`).

cloudron.io - this is Cloudron's website (the company)

console.cloudron.io - this is the place where Cloudron's customers login to manage billing. you cannot manage apps or anything of that sort here

yourdomain.com - this is the domain you gave when you installed Cloudron, the software, on your server. IMPORTANT: cloudron the company has no access to your servers. Cloudron the software is entirely selfhosted and only you have access to the server.

my.yourdomain.com - this is your server's dashboard. this is where you manage apps and other things

my.cloudron.io - this is actually Cloudron the company's, cloudron installation. you should not (and cannot) login here!

With this in mind:

When attempting to login us assigned IP it would redirect to my.cloudron.io.

this cannot ever happen.

how would I reach login when IP Changed/DNS is not available

If IP changes, go to your DNS and then just change the IP address of my.yourdomain.com manually to the new IP. Are you talking about dynamic IP here? If so, use the Dynamic DNS feature. It will automatically update the DNS with a changing IP.

Finally, if DNS itself is not available, I guess you have to use /etc/hosts . See also - https://docs.cloudron.io/troubleshooting/#unreachable-dashboard

Has anyone tried this and gotten it to work or even just using a VPS as an exit node without proxy?

Ah ok. I guess, let us know if it happens again!

Thanks, it's solved. No disk wasn't changed. It's running on AWS.

@JOduMonT an email server (without email relays) requires a public IP. There is no way around this. Even if you add a second IP, the second IP will be exposed and one can always access your Cloudron dashboard via that IP address. Just have to put an entry in /etc/hosts on my laptop and point that floating IP to my.domain.com and that's it.

I guess you are looking for a way to "sandbox" mail server to a specific IP somehow. We don't have a way to do this in Cloudron. I can move this to Feature Requests.

But also, it might be easier to just create another VM and run mail on the other VM? Security wise , this is the easiest and cleanest instead of writing a lot of code to make sure mail server and dashboard despite being on the same server don't step on each other (networking wise).

@taowang note that your IP is actually leaked. If you follow the MX record of your domain, you will find your server IP in the DNS. I think this is what the Cloudflare doc is trying to tell you.

@girish I tried this one, but i get a sad no-go :
Error put object cloudron-testfile. Message: Socket timed out without establishing a connection HTTP Code: TimeoutError
I'll wait the next update 🙂
Tx for the patch

@gerard thanks for testing. A fix for this is coming next release.

The issue is fairly recent. SpamHaus made some policy change when requests come from IPv6 addresses.

@nichu42 This could be a reason... I think source causes should be outside of Cloudron.

Let us know 🙂

@jdaviescoates Says me, since www. tells people to expect the main brand website. naked doesn't tell them anything, eg: SaaS apps often use naked for their login, and www. for the marketing site.

Check out pretty much any big brand you can think of that ought to know, www.google.com etc.

I'm sure I read a deeper article on the whys somewhere, but I was in your shorter is better camp for a long time until I realised there were good reasons for the www. being the destination.

Cookies containment from subdomains and use of CDNs are a couple of reasons I remember off the top of my head. I'm sure there's others.

@thoresson yes. If you have a Cloud firewall, you can also whitelist just your IP for port 222.

Will be fixed with next release: https://git.cloudron.io/cloudron/box/-/commit/ec7dabc1c72c2f34c3f3474bc4b3c903bb2d693d

This was a regression in Cloudron 7.7. Thanks for reporting @AartJansen

Fixed in https://git.cloudron.io/cloudron/box/-/commit/1afa2e87ec93881ebcd1f79d83d4477467b40770