Restore with wrong UID/GID 65532

[DrZoidberg09]

Description

Hi there,

I am new to k8up and actually very impressed how it works. So far everything fine with backups.

However, if I want to restore the backups everything that is not owned by root will end up with UID or GID of 65532.

If I restore to S3 and extract the archive, the ownership is correct. However, if I restore directly to PVC, it will end up like this above.

Additional Context

No response

Logs

2023-04-03T21:28:40Z	INFO	k8up	Starting k8up…	{"version": "2.7.0", "date": "2023-03-30T12:16:39Z", "commit": "8f203d75eaa6826405e0c288d2d0915fa6c53e79", "go_os": "linux", "go_arch": "amd64", "go_version": "go1.19.7", "uid": 65532, "gid": 0}
2023-04-03T21:28:40Z	INFO	k8up.restic	initializing
2023-04-03T21:28:40Z	INFO	k8up.restic	setting up a signal handler
2023-04-03T21:28:40Z	INFO	k8up.restic.restic	using the following restic options	{"options": [""]}
2023-04-03T21:28:40Z	INFO	k8up.restic.restic.RepoInit.command	restic command	{"path": "/usr/local/bin/restic", "args": ["init", "--option", ""]}
2023-04-03T21:28:40Z	INFO	k8up.restic.restic.RepoInit.command	Defining RESTIC_PROGRESS_FPS	{"frequency": 0.016666666666666666}
2023-04-03T21:28:40Z	INFO	k8up.restic.restic.unlock	unlocking repository	{"all": false}
2023-04-03T21:28:40Z	INFO	k8up.restic.restic.unlock.command	restic command	{"path": "/usr/local/bin/restic", "args": ["unlock", "--option", ""]}
2023-04-03T21:28:40Z	INFO	k8up.restic.restic.unlock.command	Defining RESTIC_PROGRESS_FPS	{"frequency": 0.016666666666666666}
2023-04-03T21:28:41Z	INFO	k8up.restic.restic.unlock.restic.stderr	successfully removed locks
2023-04-03T21:28:41Z	INFO	k8up.restic.restic.snapshots	getting list of snapshots
2023-04-03T21:28:41Z	INFO	k8up.restic.restic.snapshots.command	restic command	{"path": "/usr/local/bin/restic", "args": ["snapshots", "--option", "", "--json"]}
2023-04-03T21:28:41Z	INFO	k8up.restic.restic.snapshots.command	Defining RESTIC_PROGRESS_FPS	{"frequency": 0.016666666666666666}
2023-04-03T21:28:42Z	INFO	k8up.restic.restic.restore	restore initialised
2023-04-03T21:28:42Z	INFO	k8up.restic.restic.restore	loading all snapshots from repositoy
2023-04-03T21:28:42Z	INFO	k8up.restic.restic.snapshots	getting list of snapshots
2023-04-03T21:28:42Z	INFO	k8up.restic.restic.snapshots.command	restic command	{"path": "/usr/local/bin/restic", "args": ["snapshots", "--option", "", "--json"]}
2023-04-03T21:28:42Z	INFO	k8up.restic.restic.snapshots.command	Defining RESTIC_PROGRESS_FPS	{"frequency": 0.016666666666666666}
2023-04-03T21:28:43Z	INFO	k8up.restic.restic.restore	folder restore	{"restoreDir": "/restore", "trimPath": true, "linkedDir": "/tmp/restore", "restoreFilter": "", "snapshotID": "9c6ca2199d86d0cdf0859e0a2cbf2957b6e40ce8548a776e384eb1b8530ad2ac"}
2023-04-03T21:28:43Z	INFO	k8up.restic.restic.restore.command	restic command	{"path": "/usr/local/bin/restic", "args": ["restore", "--option", "", "9c6ca2199d86d0cdf0859e0a2cbf2957b6e40ce8548a776e384eb1b8530ad2ac", "--target", "/tmp/restore"]}
2023-04-03T21:28:43Z	INFO	k8up.restic.restic.restore.command	Defining RESTIC_PROGRESS_FPS	{"frequency": 0.016666666666666666}
2023-04-03T21:28:44Z	INFO	k8up.restic.restic.restore.restic.stdout	restoring <Snapshot 9c6ca219 of [/data/nextcloud] at 2023-04-02 19:57:16.232558687 +0000 UTC by @nextcloud> to /tmp/restore

Expected Behavior

It should restore and maintain the UID/GID as it is in the source PVC.

Steps To Reproduce

Backup and restore as described in the docs

Version of K8up

v.2.7.0

Version of Kubernetes

1.24

Distribution of Kubernetes

Rancher

[Kidswiss]

@DrZoidberg09 can you try running the restore with UID 0?

2023-04-03T21:28:40Z INFO k8up Starting k8up… {"version": "2.7.0", "date": "2023-03-30T12:16:39Z", "commit": "8f203d75eaa6826405e0c288d2d0915fa6c53e79", "go_os": "linux", "go_arch": "amd64", "go_version": "go1.19.7", "uid": 65532, "gid": 0}

Checking your log I see that the restore runs with GUID 65532, so it probably doesn't have permission to set the UID to anything else

You can set the podsecurity context for restores, see the docs: https://k8up.io/k8up/2.7/references/api-reference.html#k8s-api-github-com-k8up-io-k8up-v2-api-v1-runnablespec

[DrZoidberg09]

This is the restore job I used (with runAsUser 0):

apiVersion: k8up.io/v1
kind: Restore
metadata:
  name: restore-test2
  namespace: nextcloud
spec:
  snapshot: 9c6ca2199d86d0cdf0859e0a2cbf2957b6e40ce8548a776e384eb1b8530ad2ac
  restoreMethod:
    folder:
      claimName: nextcloud-nfs
  backend:
    podSecurityContext:
      runAsUser: 0
    repoPasswordSecretRef:
      name: backup-repo
      key: password
    s3:
      accessKeyIDSecretRef:
        key: username
        name: s3-secret
      bucket: k8up-nextcloud
      endpoint: *s3-provider*
      secretAccessKeySecretRef:
        key: password
        name: s3-secret

However, it leads to what I described above. Is this the wrong way to run it as UID 0?

[Kidswiss]

The podSecurityContext should go under spec, not under backend.

apiVersion: k8up.io/v1
kind: Restore
metadata:
  name: k8up-restore
  namespace: k8up-e2e-subject
spec:
  podSecurityContext:
    runAsUser: 0
  backend:
    ...

[DrZoidberg09]

Perfect, thank you! This did the trick. Maybe that could be something to include in the documentation? Or at least make it a little more prominent?

But now it works really nicely. Great tool!