Permission errors are being seen when subPath is used in the deployment

[asn1809]

We are having a usecase of using volsync to copy the pvc data from one cluster to another. I have the following workload:

1. Create a PVC
2. Create a deployment with subPath:

        volumeMounts:
        - mountPath: /var/log
          subPath: ramen.log
          name: varlog
      volumes:
      - name: varlog
        persistentVolumeClaim:
          claimName: busybox-pvc

3. When we create a ReplicationSource for the same, volsync-tls-src pod fails with the following error:

find: '/data': Permission denied
Skipping sync of empty source directory
rsync: [sender] opendir "/data/." failed: Permission denied (13)
IO error encountered -- skipping file deletion

Any idea or hints on how this can be done?

[tesshuflower]

@asn1809 in your application deployment, what securityContext are you using? You generally will want to match this on your ReplicationSource, so that the moverPod has access to the files on the PVC. See: https://volsync.readthedocs.io/en/stable/usage/permissionmodel.html#mover-s-security-context

Note: if you happen to be using OpenShift, the securityContext most likely is done automatically for you - ensure you're not using the default namespace as it has a non-standard setup.

[asn1809]

Thanks @tesshuflower for reply. I'm using openshift which uses scc per ns. In the workload I used, I haven't set any security context. But, I am sure openshift will add security context. If you want, I can share the RS and other resources.

[tesshuflower]

Thanks @tesshuflower for reply. I'm using openshift which uses scc per ns. In the workload I used, I haven't set any security context. But, I am sure openshift will add security context. If you want, I can share the RS and other resources.

@asn1809 thanks for this context - in OpenShift, normally you shouldn't have to set any moverSecurityContext, as it will be picked up automatically from the namespace. Again, make sure you're not using the namespace called default.

Do you do something to override it in your application deployment? First thing to check is if the running pods have matching moverSecurityContext (for your app pods and the volsync mover pod).

[asn1809]

In the pod(workload), following is the security context:

securityContext:
seLinuxOptions:
level: 's0:c30,c10'
fsGroup: 1000890000
seccompProfile:
type: RuntimeDefault

In the volsync pod:

securityContext:
seLinuxOptions:
level: 's0:c30,c10'
fsGroup: 1000890000
seccompProfile:
type: RuntimeDefault

Which are identical.

Please note that this happens only if subPath is used in the volume mounts in Deployment. Else, it works fine.