A Docker did this in 2020, but I don’t think an issue was opened on it:
I don’t run Docker, so get lost quite easily in it. Whose Docker is this, and what is the PUID PGID plan?
Would a test as in the above-cited topic be possible? And what are these chown rights. Try them here?
Running on non-Docker Linux as a user, checking the restore-permissions box gives a warning where it would otherwise do a genuine change of user when running as root. That’s Linux – only root can do that unless root is also limited. High security systems have ways to trim root down from its usual high power.
Maybe some fiddling around inside Docker in a shell could test if a chown like Duplicati would do works.
Or if a vanilla (meaning no SELinux, AppArmor, etc.) non-Docker Linux is available, you could test that.
I’m kind of bothered by the differences in the permissions scrambling. Some went to R from RW on user, some didn’t. I wonder if it’s consistent or variable from run to run? For a small backup, it’s possible to get permissions from the dblock .zip files by hand. For tiny enough test backup, it’s just a couple of blocks.
Example of actual metadata block stored as a file (its name is the Base64 of its hash) inside one dblock
{“unix:uid-gid-perm”:“2000-2000-511”,“CoreAttributes”:“Normal”,“CoreLastWritetime”:“638112452291582755”,“CoreCreatetime”:“638112452291582755”}
is one where I forced file to UID 2000 which does not exist. I also wanted to test where it can’t find name, because inside a container the outside-the-container names might not be available, e.g. in /etc/passwd.
In a more normal situation, one would also have "unix:owner-name" and "unix:group-name" present.