Correct, those "providers" are two different ones conceptually. One is where the server is hosted. This allows us to apply some VPS provider specific quirks, if required. The DNS/Domains provider is the one where the domain is registered or at least the nameservers for that domain. This may or may not be the same company as the VPS provider, but they have otherwise nothing in common.

I think you're right, it took a while to propogate fully.

@mehdi Thats kind of scary, thanks for the correction.

@girish said in Email not sending: include:sendgrid.net Thanks!

So, it seems like giving the app a "relocation" by pressing the save button under the Location config tab & a quick Cloudflare proxy off-on, and then some time is the fix. EDIT So it is Cloudflare that is the problem and not Cloudron. Specifically their proxy

@cyanogenic Did you install/enable any nextcloud plugins? This usually happens when one of the nextcloud plugins is not too happy. Try this https://cloudron.io/documentation/apps/nextcloud/#fixing-a-broken-install . Or if you have nothing important in it, I would just re-install nextcloud.

@foliovision said in SFTP Missing for some apps?: Hi Girish, Thanks for your quick answer. I did get as far as trying to edit the .env file with Vim in the Cloudron terminal. I think specifically with the .env file in Invoice Ninja that it's read only in Cloudron. Let me know if I'm wrong. Yes, the file will be editable. In fact, we pushed an update yesterday to move the env file location to /app/data/env (instead of /app/data/.env). Can you please check again if it's writable and report here? Note you will have to restart the app (Console -> Restart) after making changes.

@nebulon No worries, just thought I'd let you know

@girish The manual check method is good enough for me. If you do the release channel thing thats cool. But for those of us that a hungry, an extra few clicks isn't a bother.

@girish Yeah I was starting to think that as well. I'll give it a shot and report back. Thanks!

Agree, thanks for putting the links @fbartels . I will close that thread here in favor of the others.

Yes that is correct, follow the instructions at https://cloudron.io/documentation/backups/#move-cloudron-to-another-server Please not to not destroy the old server until the new works, you can just shut it down temporarily as mentioned in the docs.

@moonmeister I think it's better to use the username for login into all apps except the email apps like roundcube/rainloop/sogo (because they require email to know which mailbox to open). The email login was probably not a good idea to start with because the email can be changed unlike the username. These days when we bring in new apps, we don't bother much with email login.

@girish Got it. Thank you. I was using the SFTP login to SSH.

For example, it shows the 'Backup data' here in the graphs (which wasn't there in previous releases). We added this because sometimes users complain their disk is running out of disk space and it ended up being the backups consuming the space. This is only shown if you use the filesystem for backups, of course. [image: 1588030910526-a1065571-4a02-4499-a853-1b16ebb9e3fc-image-resized.png]

Hello bortsed, Cloudron offer ad LDAP server to be used by Apps like NextCloud, this is very useful if you use multiple apps in the same cloudron, or you use the email server provided with in Cloudron because you will have one account for everything. If you use external service Cloudron can be setup to replicate an existing LDAP server, we for example for managing our desktops or laptops we are using Jumpcloud.

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.