File and Folder Ownership in /yellowtent/boxdata

[michaelpope]

Hey, can anybody confirm for me if all files in /yellowtent/boxdata should have an owner and group id of 998?

Reason I'm asking is because on restore, some of my mail ended up as 1000, and I think it's preventing a proper backup, but I'm not 100% sure on that.

Thanks.

[girish]

I wouldn't pay much attention to permissions because the user ids on the host system and ids on the containers don't always match.

1000 is the id of the cloudron user inside all our containers. As for 998, this is probably user id of the yellowtent user. It could also happen if you copied files from another disk . In that case, 998 was probably the uid of your old linux system.

What's the exact backup error? Usually, when the containers restart, they fix the permissions of the files...

[michaelpope]

@girish That's the weird part. There wasn't an error, just an incomplete backup. Let me retry it and see if I can get it to happen again.

I think I might have figured it out. This Log line:

box:backuptask checkPreconditions: total required =551342991586 available=undefined

I don't think it's supposed to be undefined. I'm going to have to wait a bit to do any fixes though.

[girish]

@michaelpope because of all this permissions mess, cloudron runs the backup "uploader" part (i.e the part that reads the files and creates a tarball or equivalent) as root user (via a sudo script to limit permissions). So, just to help to debug this further, it's most likely not related to permissions.

That undefined doesn't look correct indeed. We parse the output of du -Dsb <backup_file_path> . Can you check if that output is correct ? Could it be it has some incorrect locale?

[michaelpope]

@girish I don't think so... locale seems correct. But it is reporting a very small amount.

1109207166      /email_backup

(which would be around 1 GB... which seems small enough).

I wonder if the backup disk is having issues...

I'll work on this a bit more and get back to you.

EDIT: It turns out it was undefined because that was the 'source' folder, not the 'destination' folder.

[michaelpope]

Okay, I figured out what my problem was.

I had some failed backups from yesterday, when I tried to get hardlinking working (and I also had a permission issue with the MySQL dump). As of such, I cleared the backup disk manually, and then triggered a backup cleanup in the Cloudron UI. Then I tried to back up again, however, I believe that Cloudron keeps an index of files it has already backed up to keep things speedy (which is nice). As of such, even though the other files no longer existed, it was only backing up the changes.

To solve it, I just changed the backup method to a different method, and then changed it back again, which cleared the index.

Thanks for all your help on this :).