@nebulon no problem at all. The topic itself is quite large so individual bits are easy to miss. A script could be a nice idea as most users will probably not be comfortable with doing sql updates manually. But such a script can probably turn into something complicated quite easily. The flow that immediately comes to mind would be doing in ldap server on the ldap backend and comparing it with the users that Cloudron already knows. Followed by the possibility to switch auth for any users that are primarily managed on Cloudron, but exist on the ldap side as well. Probably easier to do it in javascript than it would be in e.g. bash.

To conclude this, it was a memory issue. The instance as a whole was a bit overcommited. If the backup task is idle, it won't consume any memory. Also Cloudron does not reserve memory based on the limits set, neither for backup nor for apps. The limit is just to avoid rouge apps or the backup task to bring kill other apps.

@onlybro must be some caching somewhere Are you running Linux? If so could simply edit your hosts file

@nebulon said in SSHFS Backup Mount again not working with version 6.3.6: @amahr sorry the command to restart/remount would be: systemctl restart mnt-cloudronbackup.mount It would be nice to have this exposed in the storage UI

@girish said in Client user locked out of SFTP?: explicity - Services -> SFTP ahhh ok thanks!

@comtop1 Did you get this sorted out? Usually, I have seen disabling and re-enabling cloudflare proxy fixes things. Seems to be some in Cloudflare SSL proxy caching.

@humptydumpty thanks, good to know. We don't automate Mailgun relay yet, so we are not affected.

@marcusquinn well spotted, this was a translation quote escaping issue and is fixed now in our dataset in weblate.

@sock_check_foo hard to say what might be the root cause here. If you want us to take a direct look at it, please enable remote SSH support and send us a mail with your dashboard domain to support@cloudron.io

If you like you can send us your domain name to support@cloudron.io and we can check if it's something on your side (i.e. some browser caching issue) or if we see it as well.

@girish ah alright, that sent me down the right path. needed to switch from encoded body to raw JSON and that cleared it up. thank you!

️ PERSONAL OPINION ️ Don't use Strato. At first glance they seem like a good hoster, but they are not. Even if their pricing model seems competitive. For basic stuff like a single Wordpress or something it might be fine, but I would not entrust them my systems. I had so many customers throwing Strato out of the window in a fit of rage. Just my personal opinion based on what I have witnessed.

If you have a VPS elsewhere, you can open an ssh tunnel to it pointing a public port on the VPS to the internal cloudron install to get to the interface. That will cause other problems since it's not reachable on port 80/443.

@girish Perhaps take a look at it from the pull perspective vs push. Maybe even originating the refresh from the mail container side, triggering the others.

I am currently debugging that instance, but just for others to read up, using nginx -s reload as root usually reveals the syntax errors in config files right away, like it was in this instance as well.

@kingkobra813 Can you try running the script again and check if you get the same error? Looks like maybe nginx.org was maybe down temporarily? You can also check if this works: wget http://nginx.org/packages/ubuntu/pool/nginx/n/nginx/nginx_1.18.0-2~xenial_amd64.deb

@nebulon Thank you for taking a look! My problem has just been solved! It started for me because your DOCS did not make it clear that Creating a Mailbox was a whole separate Necessity even for the ADMIN. And that as an ADMIN who Added a User with the whole Email Invitation sent, user responding, creating their own Username, and Saving this DID NOT by DEFAULT at least finish the process by Adding a new mailbox corresponding to the new User . I never guessed that THE ADMIN him or herself of the Cloudron installation would not have access AS THE ADMIN to setup Master default parameters for the Email App itself! In your docs after following along with the entire Email setup down to the check the Status instructions at last continuing down the page it merely says, casually, as if an Option -- *Mailbox Add Mailboxes can be created for Users and Groups on a per-domain level. To do so, simply create them in the Email view.* Mailboxes can be created for Users when it should really be highlighted as Now mailboxes must be set up here for your users if you intend to offer this as a feature. Nothing indicating that we are continuing in the Enabling Emails for Users instructions or after all of the above it still won't work. That not even the ADMIN now enacting all these steps Must manually install an Email box for him/herself. How about "Finally, you must Finish this process by adding each User's Mailbox manually. These were not created automatically when you finished creating the User. In fact, You must first make an Email Box for yourself with Superadmin privileges or you will not be able to Login to the Email application to customize it according to your preferences. It was finally only by reading carefully https://forum.cloudron.io/topic/4529/cloudron-email-wrong-usernam that I realized any advice I received about my email problem was ASSUMING that I knew this -- even though everytime I read your Docs I was assuming that the Mailboxes were automatically installed, certainly for the Admin first of all. I'd recommend really emphasizing this in your docs as a clear Step 1 through Step 10(?) process REQUIRED Final step or not even the Cloudron Admin can enter his own Email installation.

@austinsonger Regarding Linode and Mail - default is blocked by Linode: https://www.linode.com/docs/guides/running-a-mail-server/ Sending Email on Linode In an effort to fight spam, Linode restricts outbound connections on ports 25, 465, and 587 on all Linodes for new accounts created after November 5th, 2019. If you have a need to send mail from your Linode, we ask that you first configure (1) valid DNS A records and (2) rDNS records for any Linodes that you plan to use to send mail. Then, open a Support ticket from the Linode Manager – we’ll ask you to provide the name of the Linode(s) that will be used for mailing. Once you’ve completed those steps and provided that information, our Support team will be happy to review your request.