"Operation not permitted" during restic restore

[aacebedo]

For one of volumes I am trying to restore I am facing a permission issue.
In the logs of the pod restoring value I see a lot of operation not permitted errors, see below:

Starting container
VolSync restic container version: v0.11.0+62a903d
restore
restic 0.17.0 compiled with go1.22.9 on linux/amd64
Testing mandatory env variables
=== Check for dir initialized ===
ID Time Host Tags Paths Size
-------------------------------------------------------------------------
cf4d9e41 2025-02-07 00:02:47 volsync /data 305.075 MiB
297fb381 2025-02-08 00:01:44 volsync /data 313.269 MiB
-------------------------------------------------------------------------
2 snapshots
=== Starting restore ===
/data /
Selected restic snapshot with id: 297fb381
restoring snapshot 297fb381 of [/data] at 2025-02-08 00:01:44.016785237 +0000 UTC by root@volsync to .
ignoring error for /backup/autobackup: lchown /data/backup/autobackup: operation not permitted
ignoring error for /backup: lchown /data/backup: operation not permitted
ignoring error for /db/WiredTiger: lchown /data/db/WiredTiger: operation not permitted
ignoring error for /db/WiredTiger.lock: lchown /data/db/WiredTiger.lock: operation not permitted
ignoring error for /db/WiredTiger.turtle: lchown /data/db/WiredTiger.turtle: operation not permitted
ignoring error for /db/WiredTiger.wt: lchown /data/db/WiredTiger.wt: operation not permitted
ignoring error for /db/WiredTigerLAS.wt: lchown /data/db/WiredTigerLAS.wt: operation not permitted
ignoring error for /db/_mdb_catalog.wt: lchown /data/db/_mdb_catalog.wt: operation not permitted
ignoring error for /uidb.json: lchown /data/uidb.json: operation not permitted
[other lines ignored]
Summary: Restored 392 / 397 files/dirs (313.269 MiB / 313.269 MiB) in 0:00
Fatal: There were 397 errors
[restic]

I already tried to change the security context of the ReplicationDestination to set the fsGroup, runAsGroup and runAsUser to 0 without
success.

Here is the replicationDestination object

apiVersion: volsync.backube/v1alpha1
kind: ReplicationDestination
metadata:
  annotations:
    meta.helm.sh/release-name: unifi
    meta.helm.sh/release-namespace: network-system
  name: unifi-data-backup-dest
  namespace: network-system
spec:
  restic:
    accessModes:
      - ReadWriteOnce
    cacheCapacity: 10Gi
    capacity: 1Gi
    cleanupCachePVC: true
    cleanupTempPVC: false
    copyMethod: Snapshot
    moverSecurityContext:
      fsGroup: 0
      runAsGroup: 0
      runAsUser: 0
    repository: unifi-data-volsync-backup
    storageClassName: longhorn-non-redundant
    volumeSnapshotClassName: snapshot-controller-longhorn
  trigger:
    manual: restore-once

Any idea how to solve this?

Regards

[aacebedo]

Found a solution by making the mover privileged using the annotation

[tesshuflower]

@aacebedo if you don't want to run in privileged, you can also take a look at the docs here: https://volsync.readthedocs.io/en/stable/usage/permissionmodel.html

If you don't specify a moverSecurityContext, this means your mover pods will run as whatever is the default in your cluster, which may be uid 0 - in this case, restic will assume it has permission to do things like chown to change the UID/GIDs to match what was on the original source side (and fail if this doesn't work). When in fact when you're not in privileged mode you don't actually have permission.

Normally you would want to use a moverSecurityContext that matches what you'll give your application, so the files would be written with privileges that match what your app will use.