Solved Error loading fsmetadata.json

[3246]

Trying to restore Cloudron to a new VM today (from locally mounted drive) and got this error:

Error loading fsmetadata.json:ENOENT: no such file or directory, open '/home/yellowtent/boxdata/fsmetadata.json'

Looking in the ../boxdata location reveals this file (nor a symlink) exists.

I installed Cloudron with --version 5.4.0 to restore this backup.

Any ideas what I can try? Duckduckgoing reveals nothing

[nebulon]

Ths file should be part of the backup itself. Can you look into the backup storage and verify it is there?

[3246]

Thanks @nebulon, my bad! #usererror

I omitted part of the path to the backup location - d'oh!

[yusf]

Getting something very similar:

External Error: Error loading fsmetadata.json:ENOENT: no such file or directory, open '/home/yellowtent/appsdata/APP-ID/fsmetadata.json'

I was performing an app cloning. When hitting the Retry cloning button it worked.

For context, I just switched backup bucket because the old one stopped responding.

It still lists an old backup, which doesn't exist anymore:

Now I wonder if that has something to do with the error I'm given. (I'm also not 100% sure that the new one is a full backup given the persistence of the old backup despite performing a Cleanub Backups action.

[nebulon]

Possibly there was a download error from the backup storage on first attempt?

Regarding the backup cleanup. Generally the listing (coming from the db) may get stale since the code does not periodically check the backup storage if the related backup is actually still there.

[yusf]

@nebulon Right.

Can I trust the new backup to be a full one and not some incremental one based on the nonexisting old one? If in doubt, how can I verify? Size?

[yusf]

Every cloning I get the same error again on the first try.

[nebulon]

that sounds like a bug then. Is this a backup storage where you have set some concurrency level in the settings? If so, maybe reduce to 1 so we can rule that out.

[yusf]

@nebulon No, I’m only using default settings Spaces on Digital Ocean.

I’ve a sense it all started with that old backup storage going awol.

[girish]

@yusf said in Error loading fsmetadata.json:

I’ve a sense it all started with that old backup storage going awol.

Did you remove/edit the snapshot directory by any chance. If so, that would mean the backups will be corrupt. Our backup code relies on the snapshot directory not be tampered by external sources.

Maybe you can just start the backup cycle "afresh". Go to Backups -> change the format (different from whatever you have now). Then Save. Then, change the backup format back. Then do a full backup. That should make the backup proper. After that, clone should work. I would do all this anyway, even if you didn't touch the snapshot directory, just to be 100% sure of the backups.

[yusf]

@girish I don’t think I’ve tampered with anything there, no.

Very good, as long as there’s some mechanism to reliably start over I’m happy to do that. Thanks! In the longer term maybe some kind of ”Start over” mechanism doing this same thing can be exposed to the backup page…