Description of problem: Fsgroup does not work for gitrepo volume Version-Release number of selected component (if applicable): openshift v3.1.1.911 kubernetes v1.2.0-alpha.7-703-gbc4550d etcd 2.2.5 How reproducible: Always Steps to Reproduce: 1.Create a pod oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/persistent-volumes/gitrepo/gitrepo-selinux-fsgroup-test.json 2.Check pod status NAME READY STATUS RESTARTS AGE gitrepo 1/1 Running 0 3h 3. /mnt/git $ id uid=1000050000 gid=0(root) groups=123456 /mnt/git $ ls -lrt total 0 drwxr-xr-x 3 root root 48 Mar 8 02:41 gitrepoVolume /mnt/git $ touch gitrepoVolume/file1 touch: gitrepoVolume/file1: Permission denied Actual results: group is root in the pod gitrepo Expected results: group id should be 123456 in the pod gitrepo Additional info:
The gitrepo volume does not support ownership management. This works as expected.
my mistake.. it should work
Just a comment related to fsGroup: 123456, and I'm not sure if the ceph-rbd plugin I used to test this supports changing the container's GID, but: When I define fsGroup in the pod spec which uses a ceph-rbd block volume, the resulting container's GID is 0 and the fsGroup is added to the container's supplemental gids.
Can't reproduce in kubernetes 1.3 looks like it was fixed by https://github.com/kubernetes/kubernetes/pull/22995
I think this bug has been fixed a long time ago, at least I cannot reproduce it in atomic-openshift-node-3.4.1.42-1.git.0.e775fe2.el7.x86_64. Moving to QA to verify it in 3.6.
It is passed on oc v3.6.153 kubernetes v1.6.1+5115d708d7
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1716