Change:
} parentFD = childFD childFD = -1 <del> } // Everything was created. mkdirat(..., perm) above was affected by current // umask and we must apply the right permissions to the last directory // (that's the one that will be available to the container as subpath) // so user can read/write it. This is the behavior of previous code. // TODO: chmod all created directories, not just the last one. // parentFD is the last created directory. </del> <ins> // Everything was created. mkdirat(..., perm) above was affected by current // umask and we must apply the right permissions to the all created directory. // (that's the one that will be available to the container as subpath) // so user can read/write it. // parentFD is the last created directory. </ins> <del> // Translate perm (os.FileMode) to uint32 that fchmod() expects kernelPerm := uint32(perm & os.ModePerm) if perm&os.ModeSetgid > 0 { kernelPerm |= syscall.S_ISGID } if perm&os.ModeSetuid > 0 { kernelPerm |= syscall.S_ISUID } if perm&os.ModeSticky > 0 { kernelPerm |= syscall.S_ISVTX } if err = syscall.Fchmod(parentFD, kernelPerm); err != nil { return fmt.Errorf("chmod %q failed: %s", currentPath, err) </del> <ins> // Translate perm (os.FileMode) to uint32 that fchmod() expects kernelPerm := uint32(perm & os.ModePerm) if perm&os.ModeSetgid > 0 { kernelPerm |= syscall.S_ISGID } if perm&os.ModeSetuid > 0 { kernelPerm |= syscall.S_ISUID } if perm&os.ModeSticky > 0 { kernelPerm |= syscall.S_ISVTX } if err = syscall.Fchmod(parentFD, kernelPerm); err != nil { return fmt.Errorf("chmod %q failed: %s", currentPath, err) } </ins> } return nil }

Discussion:
What happened: Adding a VolumeMount to a container with a multi-part subpath results in only the leaf directory having 777 permissions. If you define e.g. then within the volume, and will have permissions, whereas will have permissions. This means that if you want to remove and eventually from within a pod, you will need to use a privileged pod. If the sub-directories already exist, their permissions are unchanged, and the order in which these subpaths are created appears to be the order in which they appear within the spec -- if we see first, then will be created with 755 permissions and will be created with 777 permissions, even if there's another volumeMount for further down. What you expected to happen: Sub-directories created to support a volumeMount should all have the same permissions as the leaf directory. How to reproduce it (as minimally and precisely as possible): the yaml below. The first example has volume mounts so that is created before ; the second example has volume mounts in reversed order, so is encountered before , which results in being unwritable. <details<summaryThis pod will complete</summary</details<details<summaryThis pod will fail</summary</detailsAnything else we need to know?: I believe this is the return of Environment: Reproduces on minikube and a (OpenShift) development cluster I have access to Kubernetes version (use ): minikube: OpenShift cluster: output: Cloud provider or hardware configuration: Minikube: v1.15.1; docker driver; hostpath volumes (all default) OpenShift cluster: AWS, EBS volumes OS (e.g: ): Minikube: Fedora 32 OpenShift cluster: RHEL 8.2 Kernel (e.g. ): Minikube: OpenShift cluster: Install tools: minikube v1.15.1 / Not sure Network plugin and version (if this is a network-related bug): N/A Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
/sig storage
/assign
GitHub didn't allow me to assign the following users: mengjiao-liu. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign