CODEWITHSUNDEEP
kubernetesnfspersistent-volumes
Sathwik Matsa
Sathwik Matsa

Reputation: 43

Unexpected subPath Behavior in Kubernetes: Auto-Created Directories with Root Ownership and Permission Issues

I’m observing unexpected behavior when using subPath in a Kubernetes Pod’s volume mount.

Pod Definition:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: main-container
    image: busybox
    command: ["sh", "-c", "while true; do echo Running; sleep 60; done"]
    securityContext:
      runAsUser: 1001
      runAsGroup: 20
    volumeMounts:
    - mountPath: /work-dir
      name: workdir
      subPath: app/data/my-pod-data
  volumes:
  - name: workdir
    persistentVolumeClaim:
      claimName: nfspvc

Note: app/data directory already exists in the Persistent Volume.

Observed Behavior:

If my-pod-data does not exist, it is automatically created—but with root ownership:

drwxr-xr-x. 2 root root   0 Mar  1 18:56 my-pod-data

This was observed from another pod (Let's call it other-pod) mounting app/data from the same PV. I cannot create files within my-pod-data from either my-pod or other-pod, which is expected since write permissions are only available to the root user. However, I can delete my-pod-data from other-pod, even though it is running with a non-root security context.

Nested Directories Behavior:

If the subPath includes multiple non-existent nested directories (e.g., app/data/a/b/c), the behavior changes. This time, I cannot delete a, b, or c from other-pod.

This behavior is confusing, and I couldn’t find much documentation about it: https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath

Can someone clarify why this happens?

Upvotes: 0

Views: 17

Answers (0)

Related Questions