Description of problem:

OADP + restic restore files with `root` user ownership instead of the original user id ownership, in NFS server with `no_root_squash`

Version-Release number of selected component (if applicable): OADP 1.1 - 1.3

How reproducible: inconcsistent, if the restore is repeated (deleted the pvcs and namespaces beforehand) then it somehow resolved the problem

Steps to Reproduce:
1. do backup, including persistentvolumes with restic uploader
2. do restore to different cluster
3.

Actual results:
OADP + velero + restic restore directory as root

Expected results: OADP + velero + restic should restore and change ownership to the original user id, similar as restic repository

Additional info:

related public issue: https://www.ibm.com/support/pages/node/7149126
on restore some of the directory restored by OADP's velero with restic integration seems to have `root` as owner and has caused problem for any jobs or pods to continue to use the data (in this screenshot it's `_global_` and `.scripts`)

we worked around it by changing the directory permission manually

This has occurred across OADP version 1.1 - 1.3, and it's hard to pinpoint what is the problem

some of related issues with velero and restic

• https://github.com/vmware-tanzu/velero/discussions/3609
• https://github.com/restic/restic/issues/2447#issuecomment-546045614
• https://github.com/restic/restic/issues/2563

restic repositories shows correct userid mapping (`1000700000` instead of `root`)

restic -r s3:http://minio-velero.apps.wmlrtpl414501fnsybar02.cp.fyre.ibm.com/velero/cpdbackup/restic/cpd-instance ls 3c6136e1 --long
repository 15967d68 opened (version 2, compression level auto)
snapshot 3c6136e1 of [/host_pods/3dc6684b-479d-47ab-abc3-cd925f88ed14/volumes/kubernetes.io~nfs/pvc-7c0b3499-a96a-49d3-b2eb-735fe4bdc0c4] filtered by [] at 2024-06-26 17:31:59.013094697 +0000 UTC):
drwxrwxr-x 1000700000 103000      0 2024-06-17 17:09:29 /_global_