@nebulon In which release will this fix be included

@nebulon Thanks guys.

so this should be fixed with the next release now, where we replaced https://www.npmjs.com/package/@sindresorhus/df with our own implementation which calls the df command in a more locale safe way.

@d19dotca ext4 is the filesystem type in this case from your root / partition and ext4 has a feature of reserved blocks for the root user. Other disks may or may not be ext4 like for volumes or backup.

@girish It sure did. I thought it was a simple matter of brute forcing 16 characters. I’m glad that’s not the case. Thanks for the clarification!

@girish with help from vps and hosting it is been solved. thank you for replying here

@YoMaCloud thank you for the correction / update, useful to know.

Not sure why that slipped through. Is this sorted by now? We had a case where slow I/O caused the issue resulting in a timeout. Could this have been the case? https://forum.cloudron.io/topic/4780/postgresql-database-won-t-start/8

@girish said in Incorrect error when removing an obsolete alias for a service: Did you happen to set this up manually? Hmm, I don't actually know. It's not impossible I guess... Good to know though, I'll work on cleaning DNS up

@Jonaz said in You are seeing this page because the DNS record of x.x.x.x is set to this server's IP but Cloudron has no app configured for this domain.: I updated DNS, and my.cloudron works but not cloudron. which is fine with me. Thanx As @subven said, wildcard DNS entry does not include the bare domain. So, you have to put cloudron separately in DNS and not just *.cloudron

@jdaviescoates said in How to cancel an update?: @vladimir-d said in How to cancel an update?: FTR, "Retry update task" and then "Restart App" have sorted the issue. And then revert to previous backup? @jdaviescoates It would be yes if there was a recent backup copy.

@dominikjannis Do you think you can send me the IP address to support@cloudron.io ? I can test it out from my test instance.

This has helped me in version Cloudron v7.3.2

@nebulon awesome! Thank you so much!

OK, this got sorted out on support. Basically, the configs got lost somehow. Putting back the vanilla configs from the package brings them back.

@subven wordwrap!!! the problem was staring me in the face! But I could not see it because i did not scroll to the right... Thanks for the help!!!! I took a cert and key file from another server, and renamed the default cert to be whatever the error wanted. first thedomain.com.cert, then thedomain.com.key. and so-forth until it loaded. It is working now! .

@perler Have you seen https://docs.cloudron.io/apps/#cron already? This will run the job in the context of a container. I am happy to add other "meta" patterns, if none of those fit your use case

@CBCUN any decent hoster can upload with a speed of 10MB/s so for a 600GB backup it should take 16-18 hours. My Cloudron backup is ~80GB TGZ and it takes 35-45 minutes to backup from a Netcup RS to a Hetzner storage box. Either your source/target system is slow as hell or something else is bottlenecking. What method do you use? I found TGZ to be way faster because of the many many small files. If you have larger files, maybe RSYNC is the way to go. A good solution would be a (maybe self hosted) S3 Storage together with RSYNC. I use Minio for one of my backup instances and the backup from Cloudron is blazing fast as most of the work is done by the target machine.

@Linda-Mendez Not easily. I guess you can hack on the dashboard code to come up with something but this will get overwritten during updates.