SOLVED permissions issue with fsmetadata.json

[robi]

While looking at ~yellowtent/boxdata I noticed:
-rw-r--r-- 1 root root 118 Oct 15 13:00 fsmetadata.json

Crosschecking another older Cloudron this isn't owned by root.
Bug in new version?

[nebulon]

Indeed this should be owned by yellowtent user. Was this Cloudron restored or so from a backup?

[robi]

Negative.
New install to 5.6.2 and upgraded to 5.6.3

[girish]

The permission is fine, I think it changed in 5.5 when we fixed the backup job to be systemd based. I guess you are seeing this with rsync backups? The file is created by a root process.

[robi]

@girish it's set to local .tgz

every other Cloudron box I check has yellowtent as owner.

Could it be something pre-mail config vs post mail config?

[girish]

@robi The fsmetadata.json is only used in rsync backups. It's used to keep track of empty directories and 'x' bit of files when using rsync mode. We do this because object storage services (like s3, gcs and friends) cannot track this since they are not a filesystem but an object store.

This is not needed in tgz because tgz format can encode this information inside the tarball.

In essence, fsmetadata.json is usually owned by root. If it's owned by yellowtent, it's probably because maybe you restored the Cloudron in the past or something. The restore logic changes the permission of all files to yellowtent after downloading so that restore can continue as non-root user.