@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.

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.