OK, with @NCKNE 's help we got this figured out. Cloudron has a anti-spoof check where we don't allow external servers to send email with FROM address set to any incoming domain. In this case, a backup MX is relaying email to Cloudron and it is correctly detected as spoof-ed email. The workaround is to simply whitelist the MX's IP in the SPF record. With this Cloudron has the "authorization" that the server is allowed to relay such email and accepts the mail. I have added a section in our doc here - https://cloudron.io/documentation/email/#alternate-mx

@girish Thanks. I'd already started down that route (reluctantly) because I could see no other option. I'll see how that goes ... I'll have to get back to that tomorrow. Thanks again for the clarification. (Some more detailed documentation on the main site would have been helpful.)

You can use both the external LDAP/AD or the Cloudron user management. Users synced from LDAP will be marked accordingly in the Cloudron dashboard. Cloudron also can handle as many domains as you like, however the dashboard is only installed on one. So all users logging into that dashboard would have to use the same domain. From what I understand your case, it may be better to just create individual Cloudron instances per organization, then all this is probably easier to manage.

Thanks for the reply, @girish. Doing a host -t NS lead me to find that the NS records were not added in DigitalOcean. Adding them in fixed the problem.

An important first line of defense here is to prohibit SSH login via password, but using keys instead. You can read up on how to do this for your Cloudron instance at https://cloudron.io/documentation/security/#securing-ssh-access This page also contains further information about how to harden your setup, so it might be worth it to read the whole document.

@ruihildt The issue in your case was different. There were so many apps that the query parameter limit was getting exceeded. This is fixed in next release. @necrevistonnezr this is most likely your issue as well!

@stantropics One thing worth looking into is https://cloudron.io/documentation/apps/nextcloud/#managing-deleted-files (especially, those deleted nextcloud files hang around indefinitely).

It proved a decent strategy given I get 50MB/s in a direct server-to-server transfer instead of caching it on my computer at a speed of 3MB/s.

@echokos Right as @NCKNE suggested, you can enable the dynamic dns option under Domains view before migration and take a backup after you enabled it. With that the DNS records will be automatically updated post migration. After migration, you can turn off that option since the IP won't change anyways.

@dieter if you add an ssh key whilst buying the Hetzner server then they don't even create a root pw

@timmeh let us know if @NCKNE's workaround works or not.

I wonder why it's trying to install from jessie-backports ? Is this a fresh ubuntu install or did you try to install something else prior to Cloudron?

@girish thanks for the info!

@beenmeckel said in Is data stored in a Custom Data Directory included in Cloudron backups?: So I feel fine about getting set up with Nextcloud on a server I'm renting from Hertzner. I'm just stressing about how much of the time it is likely to crash or go wrong I've got all my Cloudron stuff running on Hetzner and so far nothing had ever crashed nor gone wrong. Also the data on their volumes is triple replicated too. But yes, also looking into how to backup me backups elsewhere too...

@bangden07 Ah, that's a smart work around! I just noticed that you had SSL issues on the root domain. The wildcard cert only covers subdomains i.e *.foo.com but not foo.com. Cloudron still has to get normal certs for foo.com. I guess after a week, you can remove the cloudflare proxy.

Solution : In my case, /home/yellowtent was owned by root, gpg was trying to create "~/.gpg". My fix : "chown yellowtent:yellowtent /home/yellowtent/"

Upgrade went well - all good on v5.1.3 now

OK, I will try to reproduce it locally and reach out if required. Thanks!

THANK YOU. I use Cloudflare as my DNS provider. Looks like they have some sort of caching feature called Cloudflare Rocketloader which caused this conflict. I Turned it off and it worked now. Much appreciated! @nebulon https://community.cloudflare.com/t/how-can-i-remove-the-rocket-loader-script-from-the-header-tag-on-my-website/4229

The issue here was that @minhbaop imported a box backup (i.e a backup with box_ prefix) into an app. Cloudron clearly has a bug that importing an unknown format makes it put the app in some indeterminate state. We will get this fixed in some future release.