@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 .

Here's the debian bug for unbound - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989959

@ei8fdb I delete the dump file, then decide to backup from that's date - restore will fail? No, a copy a the postgresql file is in the backup. The file at /home/yellowtent/platformdata/<appid>/postgresqldump is a temporary file. When we want to backup an app, we create a dump from postgresql and save it to that file. Then we upload that file to wherever the backup is located . After the backup is done, that file has no real use but we just keep it around because in some rare cases where you don't have backups it can help in recovery. So, to summarize: Safe to delete /home/yellowtent/appsdata/app-container-id/postgresqldump . But this will be created as part of the backup process, so it's going to be a pain. You have to delete this file everyday. Your final backup location will have a copy of the above file. Under <timestamp>/appid/postgresqldump . This is your backup, don't delete this file!

Generally, we are able to manage posts which have spam content. Most existing users, they are quite benign. I think we are lucky so far with that we do little to no moderation (maybe only fixing some typos and moving to the right category) In this specific case, the issue was the profile page had spam content. This is a bit more elaborate and I am not sure how @SPRADEEP even came across it. I think if we have a script to clean up profiles which are over 2 weeks old and have not posted anything and have some junk profile, we can delete them. I can't imagine it's hard to spot junk in profiles with some basic word matching.

What @d19dotca mentioned is correct, the next release will solve this issue and the current warning can be safely ignored for now.

@WiseMetalhead yep, that's exactly what I was looking for, thanks! I thought I typically keep up with recent posts on the forums but somehow missed that one. Looks like all is well and will be resolved with the next Cloudron release!

@girish Thanks for responding so quickly! I'll need to revisit my DNS knowledge to get that up and running. Doesn't seem too crazy to do. Thanks for the link, and also for actually trying to answer Daniel's question inside your link. Too many times people say "just don't do that" or, "do this other thing instead". Drives me insane

Okay, this was kinda weird. Did register the domain and added it to CloudFlare. Got the error "invalid domain" while adding it on Cloudron. Got the error while using CloudFlare, but also with wildcard. As I had some other work to do, didn't really check after my post. As I tried to add it to Cloudron for a screenshot and after that the manual solution, it suddenly worked, while having selected CloudFlare. So maybe there was a problem with resolving the domain before, but it is working now at least.

Ok, finally sorted after stopping queries that were locking old txnids and then doing a full vacuum. I suppose restarting the postgres container could have done that. This was useful to find blocking queries, in addition to pg_terminate_backend: SELECT pid, datname, usename, state, backend_xmin, query FROM pg_stat_activity WHERE backend_xmin IS NOT NULL ORDER BY age(backend_xmin) DESC; Went from 88% full to 38% full in about 10 minutes.