@marcusquinn Great summary! I've similarly found that ingress transaction costs are more than my monthly storage costs with rsync option and tar zip backups keep timing out. @girish Thanks for adding the additional advanced backup configuration in 5.5! I've tried increasing it for my backups and am excited to see if it helps.

@d19dotca I have added some docs now. https://cloudron.io/documentation/backups/#schedule has info on the timeout and nice. https://cloudron.io/documentation/backups/#concurrency-settings on the concurrency settings.

Yeah, I was hoping to get a picture of the storage used by a user or usergroup across all apps on Cloudron. Apart from companies or single user installs of Cloudron, the thinking was that enabling groups of people to share a server and switch to self hosted open source software would involve having insight into the main variable resource - the storage - in order for the cost sharing to be transparent. I understand that's it's not feasible to implement, so will need to think of other community models for resource sharing. Mounting a users own NFS storage is an option, but Cloudron apps are restricted to a single storage location per app instance. Perhaps users mounting their own external storage in an app like Nextcloud is an option. Any thoughts on a clean model for this kind of resource sharing scenario? This seems to me an important consideration for "regular" users of Cloudron, who might want to get together in order to make switching over from Google etc. financially viable.

This seemed trivial to add, so I fixed it for next release. Thanks for the suggestion!

@Hillside502 embarrassing, yeah I accidentally posted here thinking it was the wishlist. I’m on mobile and can’t see a way to move the topic over... @girish, can an admin do that?

@murgero Yeah, makes sense.

@fair Here's a script to create a user and invite them. #!/bin/bash set -eu # fill these in cloudron=my.domain.com token=a803859d40c9ec4e111ccb111111111111111111111 # the user to add and invite username=test email=test@cloudron.io displayName="Test User" function urlencode() { # https://unix.stackexchange.com/questions/159253/decoding-url-encoding-percent-encoding python2.7 -c "import sys, urllib as ul; print(ul.quote_plus(sys.argv[1]))" $1 } # add user if ! out=$(curl -sS --fail -H 'Content-Type: application/json' -X POST -d "{ \"email\": \"${email}\", \"username\": \"${username}\", \"displayName\": \"${displayName}\" }" https://${cloudron}/api/v1/users?access_token=${token}); then echo "Failed to add user" exit 1 fi userid=$(echo ${out} | jq -r .id) echo "User added: ${userid}" # create an invite. this does not send the email. if you like you can share the invite link using other channels if ! out=$(curl -sS --fail -H 'Content-Type: application/json' -X POST https://${cloudron}/api/v1/users/${userid}/create_invite?access_token=${token}); then echo "Failed to create invitation" exit 1 fi resetToken=$(echo ${out} | jq -r .resetToken) encodedEmail=$(urlencode "${email}") encodedDisplayName=$(urlencode "${displayName}") echo "reset token: ${resetToken} . URL for user to sign up: https://${cloudron}/setupaccount.html?resetToken=${resetToken}&email=${encodedEmail}&displayName=${encodedDisplayName}&username=${username}&profileLocked=true" # tell cloudron to send the invite by mail. invite links are only valid for a day from when they were created if ! out=$(curl -sS --fail -H 'Content-Type: application/json' -X POST https://${cloudron}/api/v1/users/${userid}/send_invite?access_token=${token}); then echo "Failed to send invitation" exit 1 fi echo "Invitation sent"

@girish I seeeeee

@marcusquinn said in Cloudron Backups to GitLab/GitHub Private Repos: Not a high priority - but might be nice for both the really tight and multi-location/provider redundancy aims. I have to think through the rest but multi-location backups is in our radar. We have a long pending issue about this https://git.cloudron.io/cloudron/box/-/issues/528

@marcusquinn I like the idea of atleast just adding a doc page for the moment on how to do this manually till we implement the feature. I will add it our docs.

This is implemented in 5.4

This is implemented in 5.4

This was implemented in 5.2.

This was added in 5.1

Members only flag was added in 5.2

If this is disabled or archived, this also means that it is still "known" to the system, currently the data simply is not removed from the disk, but other relevant information is purged from the database. So I agree, that deleting an account should also delete the mailbox data, if there is no proper way to restore that (currently you have to create a new mailbox record with the same mailbox handle and magically the data comes back). For that some archived state could be the solution to have a structured way to restore.

good points, thanks, gonna switch to cifs then!

Indeed, currently catch-all has to have the feature to set mailboxes across domains (like aliases).