Setting User/Group failed

[alsimfer]

Hi,

TLDR:
Can I skip setting of original user:group ids during rustic restore?

Longer read:
We use restic for backups in K8S. Other than for complete restores, we want also to use those backups to keep QA envs updated with the data created in Prod. So we basically want delta migrations which restic doesnt support. Special tnx for this feature in rustic! Now the issue: during restore the rustic seem to try setting original user:group permissions on all files. It takes long, is not needed and only produces errors, because the target containers are running under different users

[aawsome]

You can tell rustic to set uid/gid instead of user/group. See the option --numeric-id.
Also, I can easily add an option to not set these at all, please open an issue for this if you need it.

[aawsome]

@LeonardoMantovani I finally found the time to try to reproduce your behavior - unfortunately, I couldn't.
I have a file info.txt in my backup with UID/GID 1004 - which is not present in this system:

rustic ls -l --numeric-uid-gid <SNAP>:/<PATH>/info.txt
   1004     1004       129 15 Nov 20:45 "info.txt" 

after I run rustic restore --numeric-id <SNAP>:/<PATH>/info.txt test/, I see this file:

ls -al test/
insgesamt 12
drwxrwxr-x  2 alex-dev alex-dev 4096 Feb  2 06:32 .
drwxr-x--- 19 alex-dev alex-dev 4096 Feb  2 06:32 ..
-rw-r--r--  1     1004     1004  129 Nov 15  2016 info.txt

Note that I ran the restore command with root.

Running it with user permissions gave the [WARN] restore "info.txt": setting UID/GID failed. and the user/group was not set. But in this case, chown also returned an error and wasn't able to set ownership.

Can you please re-test if there really is a problem restoring non-existing UID/GID? Can you try the latest rustic version or the nightly version?

[aawsome]

@LeonardoMantovani Can you please also provide information about the environment you are using? Could be something OS- or platform-specific, too...

[LeonardoMantovani]

Thank you for taking the time to investigate on this, I really appreciate it.
I'm running NixOS 23.11 with rustic 0.6.1.

The issue is probably that, since I was executing the backups as the normal user, I didn't thought that it would have been required to be root user to execute the restore.
But now I tried and you're right, if the restore command is done by the root user permissions are restored correctly.
And this makes sense, since as you were saying the chown command returns an error if executed as standard user and the restic restore command behaves exactly the same way.

My bad that I didn't notice it before, and sorry for bothering you with that!

[aawsome]

no worries - better to get a bug report which turns out to be no bug than to not get a bug report of a real problem :-)

[simonsan]

I opened rustic-rs/docs#58 to clarify that in the docs for the future. 👍🏽

[aawsome]

The option --no-ownership is now available in the latest beta builds.

[aawsome]

(Unfortunately there is so far no rustic ls --numeric-ic or something like this)

I opened #1019 to add --numeric-uid-gid to rustic ls.

[LeonardoMantovani]

Hey, thank you for addressing the issue that quickly!
So now from the next release (I guess rustic 0.6.2) I should be able to restore non-existing UIDs ang GIDs properly by using rustic -r <my_repo> restore latest . --numeric-uid-gid, right?
And, if so, any idea about approximately when this next release will be available?

[simonsan]

The next release will be a release containing breaking changes, so it will be 0.7.0. And we can't give any estimations on upcoming release dates, as we are doing that all in our spare time. But it shouldn't be too far away. It's most likely happening in February, but no promises. :)

[LeonardoMantovani]

Thank you! And don't worry, I totally understand, I was asking just because of curiosity.
Good luck with 0.7.0 and thank you for all your work on this project

[aawsome]

So now from the next release (I guess rustic 0.6.2) I should be able to restore non-existing UIDs ang GIDs properly by using rustic -r <my_repo> restore latest . --numeric-uid-gid, right?

No. So far I only added the possibility to examine the uid/gid using the rustic ls command.
I wasn't able to work on reproducing your issue so far, unfortunately. My priorities are currently on the upcoming release.