Cloudron Forum

I had this for a while, with an instance of PeerTube, I think. But then the problem went away. Edit: nope, it was The Lounge, and possibly it went away because of this.

Good to know, thanks Girish. It never happened again, only once so I guess it was transient in nature.

Maybe search for "Hetzner" and "EACCES" - and thou shalt find....

I don't think there is any backup option out there which can do what you are hoping can be done. The one exception is if you are manually extracting the data to be restored, and putting them in different locations. I just say this so you don't go feeling like this is some sort of weakness of Cloudron. Backups rely on timestamps and exact conditions. You couldn't restore the second backup because it would look for the time slot from which it was built, in the records, and those records aren't going to be in the currently restored backup. But if it is the media you want, then the fact you do have separate sets of backups does mean you can at least navigate through the backup and find that media, and then as @nebulon said, manually add them back to your Mastodon. But I gotta say, why do you need to have this media? I mean, Mastodon IS social media, and it's meant to be ephemeral. If there is some info you like, then screenshot it, or click the link and bookmark it, print it out to PDF, or follow the poster (to then check them out post-restore to see that specific post) etc. But saving it and keeping it to be viewable only within your Mastodon seems like a use even Mastodon wasn't really meant for. Anyway, good to hear you are back up and running. Hope the new year remains happier. I'm @shane@social.futurnumerique.com if you want to expand your follow/followers!

Sure, I'll write you there.

@daixiwen Even better, they HAVE already allowed for specific backup persistence: [image: 1745912539127-704862fe-911a-4719-960b-94f162df1e64-image.png] I'm going to go try that out. The wording definitely makes it sound like at least one backup, "the latest backup", should be available, but my point still stands. As perfect as Cloudron is, I've bumped into hiccups with backups myself, too. And so I pay close attention to them. In the situation you mentioned, you can either let your stopped app backups keep disappearing while you wait for a solution, or you can realize it needs a bit of your help. EDIT: I see you wrote " I'll now try having at least one manual backup set up as persistent and see in two says if it's still there, but ideally this should occur automatically." so good on you for taking it into your own hands. Let us know what happens!

I have updated the screenshot

Again: https://forum.cloudron.io/post/79353

@dylightful there is a bug when setting up Linode Object Storage (it's already fixed in next release). For now, you have to choose S3 compatibly Storage in the Storage provider combo box and input the values. It's the same thing internally, the Linode Object Storage is merely a convenience that fills out some fields like the endpoints.

This is fixed in master as well now.

Yeah, thanks. I thought thats posible, but i will do it like our adivise

Closed due to inactivity

Thank you, Girish, for diagnosing and solving this bug so quickly! Backups are working again. If somebody else has this issue and needs to do the patch, you would go to the operating system for your server and find the file there and edit it. Cloudron also have a support tool inside Cloudron which enables you to temporarily grant ssh access to your server, which would let Cloudron's brilliant team patch it for you.

To answer the original question: I think root user is the first/admin user that you signed up with Wasabi. If you create users after that, they are called sub-users. Depending on your setup, you have to create a key for the root user or sub user. I guess you can just create the key for root user if you are not using sub-users. See https://docs.wasabi.com/docs/creating-a-user-account-and-access-key

Might not be limited to „lock“ files: Today I had a similar error (first time ever!) du error: Command failed: du -Dsb "/home/yellowtent/boxdata/mail" du: cannot access '/home/yellowtent/boxdata/mail/vmail/[REDACTED]/mail/dovecot.list.index.log.2': No such file or directory

@jayonrails https://forum.cloudron.io/post/47122

aw. well, it told me witch post, but it didn't say witch post in particular in this particular topic. unless you can upvote the topic itself

@robi said in Backup failed: ENOENT: no such file or directory, open '/mnt/cloudronbackup/my.uniteddiversity.coop-netcup/snapshot/app_08388b1d-12c7-42c2-b6bd-a5c5be5cfcbb.tar.gz': It's odd that backups ran fine until they didn't with that same default all this time. What would make backups use more memory over time? It would be interesting to know a little more about that, indeed.

Hello @shrey This is expected. Each Cloudron release and update has to treat every system the same and can not respect changes made by the user. Changes made to the core services need to be managed by the user manually.