<p>On the host, everything in the mounted directory (<code>/opt/testpod</code>) is owned by uid=0 gid=0. I need those files to be owned by whatever the container decides, i.e. a different gid, to be able to write there. Resources I'm testing with:</p>
<pre><code>---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv
  labels:
    name: pv
spec:
  storageClassName: manual
  capacity:
    storage: 10Mi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: &quot;/opt/testpod&quot;

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
spec:
  storageClassName: manual
  selector:
    matchLabels:
      name: pv
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Mi

---
apiVersion: v1
kind: Pod
metadata:
  name: testpod
spec:
  nodeSelector:
    foo: bar
  securityContext:
    runAsUser: 500
    runAsGroup: 500
    fsGroup: 500
  volumes:
  - name: vol
    persistentVolumeClaim:
      claimName: pvc
  containers:
  - name: testpod
    image: busybox
    command: [ &quot;sh&quot;, &quot;-c&quot;, &quot;sleep 1h&quot; ]
    volumeMounts:
    - name: vol
      mountPath: /data
</code></pre>
<p>After the pod is running, I <code>kubectl exec</code> into it and <code>ls -la /data</code> shows everything still owned by gid=0. According to some Kuber docs, <code>fsGroup</code> is supposed to chown everything on the pod start but it doesn't happen. What am I doing wrong please?</p>

<p>The  <code>hostpath</code> type PV doesn't support security context.  You have to be root for the volume to be written in.  It is described well in this <a href="https://github.com/kubernetes/minikube/issues/1990" rel="nofollow noreferrer">github issue</a> and this docs  about <a href="https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/storage/volumes/#hostpath" rel="nofollow noreferrer">hostPath</a>:</p>
<blockquote>
<p>The directories created on the underlying hosts are only writable by root. You either need to run your process as root in a  <a href="https://unofficial-kubernetes.readthedocs.io/en/latest/docs/user-guide/security-context" rel="nofollow noreferrer">privileged
container</a>  or modify the file permissions on the host to be able to write to a
<code>hostPath</code>  volume</p>
</blockquote>
<p>You may also want to check this <a href="https://github.com/kubernetes/kubernetes/pull/39438" rel="nofollow noreferrer">github request</a> describing why changing permission of host directory is dangerous.</p>
<p>The workaround people describe that it appears to be working is to grant your user sudo privileges but that actually makes the idea of running container as non root user useless.</p>
<p>Security context appears to be working well with emptyDir volume (described well in the k8s docs <a href="https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" rel="nofollow noreferrer">here</a>)</p>
