@Olgoonik-IT thanks for reporting, I have fixed this now.

@imc67 essentially the patch for this is https://git.cloudron.io/cloudron/box/-/commit/eb0662b2455e0687ab3ce5dd02d2466e16670092 so two files need to be adjusted. The .ejs file is a template which will result in /etc/nginx/applications/my.<domain.com>.conf so besides the editing the .ejs file additionally edit that file and then systemctl restart nginx and systemctl restart box.

@LeeW Thanks for trying it and letting us know!

@nebulon I didn't get any notifications in the dashboard for OOM which is why debugging was fairly unintuitive. @girish If I encounter it again, I'll check dmesg and let you know.

@nebulon Unfortunatelly not.

That is indeed a bug and is now fixed for the next release.

@leahcim37 are there any errors in /var/log/cloudron-setup.log ? When you say it installed but it failed, what do you mean?

This was indeed a bug. Fixed in https://git.cloudron.io/cloudron/box/-/commit/2434e813836e7837162c1798794d04655227d9cf . Thanks a lot @avatar1024 . It will be part of 7.1.2

@savity Indeed, there is no event log entry, I will add it.

@BrutalBirdie yes, this was a bug in 7.0.x. certificates of apps are "deleted" after 6 months or so. when this happens, the nginx config is left dangling. This is fixed in 7.1 with https://git.cloudron.io/cloudron/box/-/commit/5382e3d8321ddb96817f50ab94e9da56258b11e9

Ok this is fixed in the next patch release.

@3246 said in Restore Error - Cannot access 'error' before initialization: Do I always have to use the backup config (I did manage to change the path manually to point it to the latest backup after uploading the restore file)? No you don't need the backup file. https://docs.cloudron.io/backups/#restore-cloudron did you try to completely remove the mount and the configure it new?

I have clarified the text a bit more now.

For a start, the next version will require the user to add an encryption password if the backup config indicates that the backup is encrypted.

In 7.1 atleast, this seems fine: [image: 1645478658315-1c2d66a7-2e5f-4590-b935-685d949310b8-image-resized.png]

@scooke Solution was deleting a buch of files from path: /home/yellowtent/boxdata/mail/haraka-queue that files were created past Jan-06. On that day we had an account hijacked that started sending out spam. I deactivated the account and it was working fine until past feb-16th, when email service started to crash. HTH.

@nebulon : interesting about Nextcloud I used to have 4 x Nextcloud instances in my Cloudron server (different projects). 3 of them about 10Gb of files (other smaller). My backups were working but slow. Even after switching to 'better' VPS provider. So after testing Seafile for a while, I have moved 2 of the Nextcloud instances over to a single Seafile VPS (with different libraries for segregation). The other 2 Nextcloud instances will follow. I have nothing against Nextcloud and been very happy for it for long time. But if it is really only being used for file collaboration and device syncing, and you don't actually NEED the extra facilities it provides, my personal view is that Seafile is a better solution. So would be awesome to get Seafile onto Cloudron. But I'm quite happy running it on a separate VPS.

@matthewdykstra Cloudron actually does do upgrades for you. If you check the notifications from time to time, at my.example.com/#/notifications, there will be some in there that say some upgrades have taken place and that the machine needs to be restarted. So, the security upgrades that @girish mentions DO happen, just automatically. You don't need to worry that your server will be sitting there becoming increasingly weak and exposed.

@nebulon Had to wait a few days to execute on moved cloudron server. all resolved now. Thank you for this.

@neweconomy I think this is similar to https://forum.cloudron.io/topic/6509/unable-to-log-into-the-app-store . Can you go to Services view and check if unbound is running ? Can you restart it if it is not running ? After that you should be able to login .