# fsGroup has different impact on hostPath versus pvc and different impact on nfs versus cifs **URL:** \ **Category:** General Discussions\ **Created:** [July 20, 2020, 7:52pm UTC](https://discuss.kubernetes.io/t/fsgroup-has-different-impact-on-hostpath-versus-pvc-and-different-impact-on-nfs-versus-cifs/11939 "2020-07-20T19:52:51Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Howard\_Roark](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/howard_roark/32/5845_2.png) [@Howard\_Roark](https://discuss.kubernetes.io/u/Howard_Roark)\ **Post date:** [July 20, 2020, 7:52pm UTC](https://discuss.kubernetes.io/t/fsgroup-has-different-impact-on-hostpath-versus-pvc-and-different-impact-on-nfs-versus-cifs/11939/1 "2020-07-20T19:52:51Z")
Many of my workflows use pod iam roles. As documented [here](https://github.com/aws/amazon-eks-pod-identity-webhook/issues/8), 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 Kubernetes (Kubelet?) tries to chown all of the files on the volume, which takes too much time and causes the timeout. Questions… 1. 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. 2. 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 this cifs flexVolume plugin that has worked great up until now: [https://github.com/fstab/cifs/blob/master/cifs](https://github.com/fstab/cifs/blob/master/cifs) 3. Can someone elaborate on or point to the block of code that shows how Kubernetes determines when to chown all of the files on a volume when fsGroup is included? Does it always try to chown all of the files when it’s included? Thanks for any help you can provide! ---
**Author:** ![Howard\_Roark](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/howard_roark/32/5845_2.png) [@Howard\_Roark](https://discuss.kubernetes.io/u/Howard_Roark)\ **Post date:** [July 27, 2020, 7:43pm UTC](https://discuss.kubernetes.io/t/fsgroup-has-different-impact-on-hostpath-versus-pvc-and-different-impact-on-nfs-versus-cifs/11939/2 "2020-07-27T19:43:49Z")
Just following up on this. I could really use the Community’s help here! Thanks Mike ---
**Author:** ![stephendotcarter](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/stephendotcarter/32/4528_2.png) [@stephendotcarter](https://discuss.kubernetes.io/u/stephendotcarter)\ **Post date:** [July 27, 2020, 9:14pm UTC](https://discuss.kubernetes.io/t/fsgroup-has-different-impact-on-hostpath-versus-pvc-and-different-impact-on-nfs-versus-cifs/11939/3 "2020-07-27T21:14:53Z")
I suspect hostPath assumes a shared local directory so changing permissions could break things. A pvc is theoretically dedicated. But that’s just a guess. The only suggestion I have is here: > **[Configure a Security Context for a Pod or Container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)** > > A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to: > Discretionary Access Control: Permission to access an object, like a file, is based on user ID (UID)... ```auto fsGroupChangePolicy = OnRootMismatch ``` It’s an alpha feature. I’ve never used it but may avoid it always trying to set permissions. Kind regards, Stephen ---
**Author:** ![Howard\_Roark](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/howard_roark/32/5845_2.png) [@Howard\_Roark](https://discuss.kubernetes.io/u/Howard_Roark)\ **Post date:** [July 28, 2020, 2:54am UTC](https://discuss.kubernetes.io/t/fsgroup-has-different-impact-on-hostpath-versus-pvc-and-different-impact-on-nfs-versus-cifs/11939/4 "2020-07-28T02:54:13Z")
Thanks for sharing Stephen. I remember seeing that feature, but I think it’s for 1.18. We are currently on EKS 1.15 and hopefully soon to be EKS 1.16 (it is actually a huge hassle to jump from 1.15 to 1.16 because many of the valid resource apis changed). So, I don’t think we will get to 1.18 for many moons even when AWS offers it. I think this PR might be the official fix [https://github.com/kubernetes/enhancements/pull/1598](https://github.com/kubernetes/enhancements/pull/1598) I guess that will be out in 1.19. Until then I need to come up with some sort of scalable workaround or abandon pod iam roles altogether. I did come up with a way to have an init container change the permissions of the token, but it’s not really scalable and will only work in one off projects. Mike