I just tried a restore on a different Linux system than the one where the backup was created. I noticed afterwards that files silently became owned by the user under which I did the restore. In retrospect that makes sense because the user didn’t have permission to create files with arbitrary uid/gid combinations. It works when the restoring process has the capability to chown file ownership (sudo setcap "cap_dac_read_search+ep cap_chown+ep" ~/restic).
But isn’t that something that restic should at least warn about?
I’m now running with --verbose and perhaps because of that I do get more warnings. But what does this mean?
ignoring error for <xxxxx>: UtimesNano: no such file or directory
I should add that I am trying to restore as normal users because root cannot read the repository, which is on a NFS share with root_squash , i.e. root doesn’t have the right to override access control.
My current set of additional permissions are cap_chown,cap_dac_read_search,cap_fowner,cap_fsetid,cap_sys_admin,cap_setfcap+ep.
Something I just remembered: Backing up privileged files - #3 by fd0
In case this is relevant.
Regarding your error message: is there more text other than that?
I don’t think so. tar -x doesn’t warn about this either, does it?
Indeed. If the goal is to be similar to that, then it makes sense. I guess I was expecting something that is more aimed towards exact system restore. rather than “retrieve some files”.
I’m still not sure about which capabilities are needed to run the restore as non-root. Perhaps arestic restore --strict mode where every single permission problem is reported would help - or I was simply missing some warning. I don’t have the full output anymore.
To be fair, tar was the standard way to do exactly this for awhile, and still can be used for this purpose. Before I used restic, incremental tar is the way I did system backups.
I would not be opposed to adding an option that makes restic report more errors.