Restore with wrong UID/GID 65532 about k8up HOT 4 CLOSED

@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

from k8up.

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?

from k8up.

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:
    ...

from k8up.

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!

from k8up.