title: Kubernetes: fsGroup has different impact on hostPath versus pvc and different impact on nfs versus cifs
body: <p>Many of my workflows use pod iam roles. As documented <a href="https://github.com/aws/amazon-eks-pod-identity-webhook/issues/8" rel="nofollow noreferrer">here</a>, I must include fsGroup in order for non-root containers to read the generated identity token. The problem with this is when I additionally include pvc’s that point to cifs pv’s, the volumes fail to mount because they time out. Seemingly this is because Kubelet tries to chown all of the files on the volume, which takes too much time and causes the timeout. Questions…</p>
  <ol>
  <li>Why doesnt Kubernetes try to chown all of the files when hostPath is used instead of a pvc? All of the workflows were fine until I made the switch to use pvcs from hostPath, and now the timeout issue happens.</li>
  <li>Why does this problem happen on cifs pvcs but not nfs pvcs? I have noticed that nfs pvcs continue to mount just fine and the fsGroup seemingly doesn’t take effect as I don’t see the group id change on any of the files. However, the cifs pvcs can no longer be mounted seemingly due to the timeout issue. If it matters, I am using the native nfs pv lego and <a href="https://github.com/Azure/kubernetes-volume-drivers/blob/a4386b750afd32685e6cc353c206a8c0e583148c/flexvolume/smb/deployment/smb-flexvol-installer/smb" rel="nofollow noreferrer">this cifs flexVolume plugin</a> that has worked great up until now.</li>
  </ol>
  <p>Overall, the goal of this post is to better understand how Kubernetes determines when to chown all of the files on a volume when fsGroup is included in order to make a good design decision going forward.  Thanks for any help you can provide!</p>
  <p><em><strong>Kubernetes Chowning Files References</strong></em></p>
  <p><a href="https://docs.microsoft.com/en-us/azure/aks/troubleshooting" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/azure/aks/troubleshooting</a></p>
  <blockquote>
  <p>Since gid and uid are mounted as root or 0 by default. If gid or uid
  are set as non-root, for example 1000, Kubernetes will use chown to
  change all directories and files under that disk. This operation can
  be time consuming and may make mounting the disk very slow.</p>
  </blockquote>
  <p><a href="https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods</a></p>
  <blockquote>
  <p>By default, Kubernetes recursively changes ownership and permissions
  for the contents of each volume to match the fsGroup specified in a
  Pod's securityContext when that volume is mounted. For large volumes,
  checking and changing ownership and permissions can take a lot of
  time, slowing Pod startup.</p>
  </blockquote>