Setting up under the wildcard option worked. Hopefully the wider issue with DigitalOcean will get resolved.

Are you able to login without 2fa yep - by setting up temporary password with cloudron cli tool Note that the ldap connector does not sync with a cron job, you have to press the sync button manually. Not valid - as otherwise I wouldn't be able to login with temporary password - user wouldn't exist. Manual sync - yes, sure. My logins worked up till I setup 2FA on admin on master server.

Ah .. ssdnodes can also be ip6 only. ip4 adds a fair chunk of money these days.

I had tried that before posting, but it failed. Turns out Vultr wants you to boot from a recovery disk to resize. Much faster (and no downtime) to just create new block storage and copy data over.

This is now fixed with https://git.cloudron.io/cloudron/box/-/commit/c8cd67258ad0329214e46b841de62e26e36842de

Well I'm kind of ashamed to say it but I gave up, I spent far too many hours on this one (felt like ~25 between the last three days) just on this one single issue in order to avoid an IP block for my clients as Microsoft was blocking the IP of the host machine, and I still couldn't get it to work. I eventually opted instead to create a new Public Cloud instance at OVH instead, migrated all the data to it, using the floating IP, and things seem to be working fine now (only accessible with one public IP address so Docker had no other choice, lol). Sorry there's no confirmed solution to this one.

Well then looks like OVH is not setting the DMI/SMBIOS values then properly. I guess there is not much to be done to remedy this from our side, unless some other metadata standard is used by them instead.

Fixed now for next release.

This is fixed now. The original issue is that the zone is added in Cloudflare but the nameservers of the domain are not set to Cloudflare. This makes Cloudflare return name_servers as empty in the response which makes our code crash.

@VictorMC26 There are two totally separate accounts. One is to access your server's dashboard to install and manage apps. This is via my.domain.com . The account you have here is local to your server. The other is cloudron.io account. This lets you manage billing/subscription. The screenshot you posted appears in the 'App Store' view in your server's dashboard on first time use. It is asking for this account's password. If you don't have one, you have to sign up. Once signed up, you can use the My Account link on the top right at https://www.cloudron.io/ to manage billing/invoices.

@nebulon I’m not sure I understand… if my server had 128 GB to set, why does Cloudron allow me to set nearly 256 GB? That doesn’t make sense to me.

There are some hard coded rate limits - https://docs.cloudron.io/security/#rate-limits

@nebulon It took a while to look into it - on my external facing URL it was my proxy & firewall that was blocking it. I switch to using the local IP & changed the Base DN as you mentioned & it is now pulling in users. Thanks for your help!

@ChicagoGregg said in Removing a domain produces an SQL error: Low of the totem pole. Low of the totem pole. Just use "least significant/important/crucial".

I forked this into a separate thread. Think we need some more context. Are you saying using localhost:port of your MacOS device does not work with the app proxy anymore? In the recent releases, an app proxy related change that happened is that we set the Host header to the initial request endpoint. Would your set up be affected by this change by any chance? Related issue in NPM - https://github.com/NginxProxyManager/nginx-proxy-manager/issues/127

@alphy Is there a way for us to access the server? Not sure why unbound is not resolving but that's the root of the problem. If it's possible to access it, please send us info at support@cloudron.io and we can debug further.

I don't think there is any backup option out there which can do what you are hoping can be done. The one exception is if you are manually extracting the data to be restored, and putting them in different locations. I just say this so you don't go feeling like this is some sort of weakness of Cloudron. Backups rely on timestamps and exact conditions. You couldn't restore the second backup because it would look for the time slot from which it was built, in the records, and those records aren't going to be in the currently restored backup. But if it is the media you want, then the fact you do have separate sets of backups does mean you can at least navigate through the backup and find that media, and then as @nebulon said, manually add them back to your Mastodon. But I gotta say, why do you need to have this media? I mean, Mastodon IS social media, and it's meant to be ephemeral. If there is some info you like, then screenshot it, or click the link and bookmark it, print it out to PDF, or follow the poster (to then check them out post-restore to see that specific post) etc. But saving it and keeping it to be viewable only within your Mastodon seems like a use even Mastodon wasn't really meant for. Anyway, good to hear you are back up and running. Hope the new year remains happier. I'm @shane@social.futurnumerique.com if you want to expand your follow/followers!

The current addon uses 14.9 so I guess you could run the corresponding image from https://hub.docker.com/_/postgres

You are welcome @alphy. Enjoy Cloudron!