From d54d88dec9183d7b94ec7c05321c84a175afea58 Mon Sep 17 00:00:00 2001 From: Xun Jiang/Bruce Jiang <59276555+blackpiglet@users.noreply.github.com> Date: Fri, 27 Jun 2025 08:50:50 +0800 Subject: [PATCH] Add Kopia repository ownership issue in troubleshooting.md (#9039) Signed-off-by: Xun Jiang --- site/content/docs/main/troubleshooting.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/site/content/docs/main/troubleshooting.md b/site/content/docs/main/troubleshooting.md index 6010b45a5..e61eb0d7e 100644 --- a/site/content/docs/main/troubleshooting.md +++ b/site/content/docs/main/troubleshooting.md @@ -222,6 +222,20 @@ Follow the below troubleshooting steps to confirm that Velero is using the corre Ensure that the key exists within the secret's data by checking the output from `kubectl -n velero describe secret $BSL_SECRET` or `kubectl -n velero describe secret $VSL_SECRET`. If it does not exist, follow the instructions for [editing a Kubernetes secret][12] to add the base64 encoded credentials data. +## Kopia repository files' ownership mismatch + +Velero sets the files' ownership created in the Kopia repository to `default@default`. + +If users need to use Kopia CLI to connect to the Velero created Kopia repositories, please use the following CLI as an example to avoid overwriting the ownership by accident. +``` bash +kopia repository connect <--read-only> --bucket= --override-username=default --override-hostname=default +``` + +If the ownership conflict error(`maintenance must be run by designated user`) already happens, +Velero doesn't handle the conflict by design. +To resolve it, please use Kopia maintenance CLI to set the ownership correctly, e.g. `kopia maintenance set --owner=default@default`. + +Please refer to [Issue 9007](https://github.com/vmware-tanzu/velero/issues/9007) for more information. [1]: debugging-restores.md [2]: debugging-install.md