@girish yep, it loads, awesome, thank you

@humptydumpty Yes, correct. Server restart won't fix the issue, have to restart the service explicitly (since it copies over certs).

@garyhost did you get this sorted out ? I guess the box code is/was down. You can figure using systemctl status box. And if it is indeed down, please check /home/yellowtent/platformdata/logs/box.log. You can also check if you have enough disk space because this is a common source of the box code being down.

@rmdes yes, I am not sure why. It doesn't happen in any of our demo servers or managed services. Quite strange. It could also be that maybe others have hit it but have not noticed it (since it only causes a CPU spike..) but clearly it's a bug since it's been fixed upstream.

@rlp10 there is no clear cut between which backup target is preferred. We try to cover a few options to cover a range or use-cases, but all should work. If you own the backup machine, I would anyways not advise to encrypt backups. Unencrypted files on trusted storage is a lot easier to restore if worst case trouble hits

I figured it out. Git's inline help, upon not knowing who you are, makes the suggestions: git config --global user.email <email> git config --global user.name <name> Cloudron's problem is "--global". It has no problem with setting the user.name and user.email for a particular /app. So this solved my problem: git config user.email <email> git config user.name <name> of course substituting my email address for "<email>" and my name for "<name>".

@nebulon You try to make things easy for us but we'll screw it up somehow. ; )

@girish Thanks for looking at this. Just triggered another backup with all apps active and it succeeded. I guess then it's finally time to move to the new hardware (plus making sure that the new system is using the c locale by default)

@girish right, I figured that out! Thank you! I am downloading that 10gb data now.. wuih! You are saviour!

@onlybro Thanks that worked

@girish said in Email into apps - DNS/MX/CNAME/TXT: You have to setup the CNAME/TXT for the root domain and not for my.example.com. You don't have to set it up for each app individually Thank you. That was my main issue.

@bluxomat To answer your questions (and my understanding of your needs): If you have different customers on one Cloudron instance, there is no option to have a "kind of" multi-tenant user management. If you give the role "user admin" to one user of client A, she is able to see and create all users on that Cloudron instance. In that case it's better for all (including Cloudron the company because of more subscriptions) to install a Cloudron instance per client. If you are a "frugal fox" (never heard of this before, I had a quick translate of the german word "Sparfuchs" that means something like: If I don't have to put more money in other people's pockets, why should I?), then the only chance is to have some kind of "multi-tenant" within the user management of the apps themselves. But if your customer has more than one app on your instance, you have to repeat the creation of users in every app again and again.

@derin Note that for SFTP the username is different for each app. It will look like username@app.domain.com and you have to use your password. Can you confirm this? You can see this info in the Access Control section.

@girish said in No backups because of NullPointerException: @guyds said in No backups because of NullPointerException: The first level is the per app level. Right now, apps are already backed up one by one, but they are not stored nor reported individually. And this is the missing feature in my opinion. Ah no, they are listed in app -> backups. So, even if you do a full backup, each individual app backup will be listed in app -> backups. Yes, they are listed at the app level, but there's no reporting at the app level because the backup succeeds or fails at the box level. You can also use that backup to restore/clone the app. Yes, but only if the backup succeeds for all apps. So, again, I think the current issue is that everything is treated as a whole while it makes more sense in my opinion to treat each app individually and then in the end (optionally?) bundle the individual parts as a whole. Yes, so they are treated individually, it's actually very close to what you want. The only issue is that when a full backup fails, those successful individual app backups that are part of a failed full backup will get removed/cleaned up every night. Exactly, they are per app bot not treated like that in the end because success or failure is determined by the whole box. I have made a task to fix the behavior, let's see. Great, thanks!

As of now, Im not having this issue anymore. I really dont know what would have caused this. Im thinking of setting up an opnsense firewall, not sure if it would help though

Mystery solved; The server i was hosting Afterlogic on turns out is just too slow. Checking the logs it would always time out, which is 15 seconds. I ran Afterlogic on a much faster server and now it sends emails just fine. Thanks all for your efforts to help me, it was much appreciated.

@zylstra You have to SSH into the server and run those commands. You don't need to replace the "password", the root password of the database is actually just password (this is fine since it's not exposed externally and only available on localhost).

@p44 @jdaviescoates Got it working. Thanks for your help!