@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 firstname.lastname@example.org and you have to use your password. Can you confirm this? You can see this info in the Access Control section.
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.
If I trigger the app backup of the "cloud" app alone it succeeds, but as part of the box backup it seems to be that app that makes the full backup fail most of the time. I write most of the time since when getting back to it this morning the whole box backup already failed at a much smaller app.
In my quest to move my whole Cloudron to another server I have spent yesterday working on a script to directly trigger the cloudron api to disable automatic backups of all apps, trigger each individual apps backup and then immediately stop the app and then finally doing a box backup. But then I came to the realisation that apps not included in the automatic backup are also not part of the box backup (plus I cannot trigger app backups from stopped apps).
So my best of course of action seems to be to manually backup just the "cloud" app and have everything else covered through the whole box backup. And then restore the box backup on a new system and then manually import the last backup of my "cloud" app on the new host.
edit: I was just waiting for a box backup to complete again (with the cloud app enabled) and while it finished backing up all apps it did then finally crash when backing up "box".
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).
Admin credentials for mongo are really internal/implementation details. In general, do not make configuration changes to the mongodb instance because it may not work across all apps. This is the reason why all the databases are "locked" down and not exposed to users for easy access.
That warning said, you can do docker inspect mongodb | grep CLOUDRON_MONGODB_ROOT_PASSWORD to get the root password.