I'm getting bombarded with redis connection errors causing major lag and it's why the manager isn't working right. I can rename a folder just fine with any other app. MB!

@joseph thanks for looking, it's in the same window/tab that it happens.

Thanks for reporting, looks like that slipped through but is fixed then with https://git.cloudron.io/platform/box/-/commit/1586a286d85b3e097954c1345e6d19d4b179becb

you have not set a value for medialinks ! Or one that is accessible. In CloudronManufest,json. Yeah that was the second mistake. Before, I got the message "Invalid manifest: mediaLinks is empty in manifest" I had a cryptic message like: "Could not resolve CloudronVersions.json from url". In the end, my CloudronVersions was wrong, and the error message before was not helpful. However, the medialinks error message was For this one: CloudronVersions.json needs to be publicly accessible also the Docker image CloudronVersions.json is public, yes Docker image is private - but it works I have the ghcr with credentials registered on the cloudron. So no issue anymore. In case you are interested in an error-message-improval-bug-hunt, I can send you a version of my "broken" CloudronVersions.json via PM - if not - I am happy now

In the end I used S3 compatible option to set this up successfully. IDK why I could not get the Scaleway option to work. Thanks all for your help & input

Could you please check whether this applies to the PTR4 record as well? As I hadn’t configured it on the Cloudron – since I was using a relay – I experienced issues with incoming email delivery until I configured it. I then configured the PTR4 record and everything was solved. I know that PTR4 record is related only to outbound, but I want to figure out if there is some relationship on what happened. Thanks a lot

@girish yeah did found a solution, I only did recreate container before updating and it fixed the mysql issue.

I changed nothing, but it is working today. I imagine what is happening is that the upstream storage drops connections occasionally and cloudron simply passes that on to the user instead of having a retry loop in the background. So, I still believe this functionality would benefit from being more robust, as before it would manage 20-50MB per go before drop, and if the thing was in a retry loop it would be able to get the archive out by just resuming downloads. I realise it is annoying having to deal with people who insist on unreliable storage... but it is what we have.

@girish said: @sansguidon might be best to wait for the next release which should be out shortly. This bug is only in rsync and not in tgz. With the manual patch it did work . I'm not sure to understand your advice anyway, for me the backups are a very critical part of if not the most important of Cloudron, so they should not be skipped, and my understanding is that with rsync blocked my backups are local and no copy exists outside of my server, if I'm not mistaken? This seems risky enough and a sufficient motivation to take immediate action, or please correct me if I misunderstood.

@robi thank you. Indeed it does allow me to type a command . My bad (I was waiting for the prompt to blink or something) Case solved I guess

Aaaah, thank you for this explanation!

@girish Perfect thank you

Hello @nozy Please be aware that the ext4 volume option mounts the disk itself, so no need for a custom fstab entry. If you want to manage that yourself in fstab, you should use Filesystem (mountpoint).

Device Authorization Flow is implemented in 9.1.4 (will be released shortly). With this, it won't require cors/callback.

@joseph thanks a lot for your prompt answer. I migrated and after 24 hours I saw this problem. So, right now what other I did: I enabled LAMP recovery mode I disabled LAMP recovery mode I rebooted whole VPS (not only LAMP app) Problem is solved after those further steps. Migration script could be improved to update cron job container ID if any cron job configured in a specific app.

@girish Totally understood logic. Thanks a lot for your answer.

Small update from my side. I contacted Spamhaus through their ticket system and after communicating with them it seems everything is now resolved and the IP has been removed from the blacklist. Emails are working normally again. Sorry for the false alarm and thank you for your help and responses. I did notice that occasionally I still see the error that was present in the previous version, so I will keep

@girish thank you

Just to come back to the previously suggested solutions - Would it be a big feature request to add group name parsing into the mailing list input box? E.g. instead of (or in addition to) a list of email addresses it could take something like "group:foo" and then this would dynamically pull in the email addresses of all users in group foo as needed. Is there a way that cloudron user group info could be pulled in @roundcube (or another mail system), so that instead of setting up forwarding rules that go to a list of emails it could go to "group:foo". Is there a way that we could run a cron job (or similar) which could hackily create either of the above functionalities by generating and inserting the lists (rather than these lists being dynamically generated), with the downside that this would only ever be as up-to-date as the frequency with which the cron job runs.

O what a pity was hoping this could be a solution