<p>In Kubernetes, I am having a directory permission problem.  I am testing with a pod to create a bare-bones elasticsearch instance, built off of an ElasticSearch provided docker image.  </p>

<p>If I use a basic .yaml file to define the container, everything starts up.  The problem happens when I attempt to replace a directory created from the docker image with a directory created from mounting of the persistent volume.   </p>

<p>The original directory was</p>

<pre><code>drwxrwxr-x  1 elasticsearch root   4096 Aug 30 19:25 data
</code></pre>

<p>and if I mount the persistent volume, it changes the owner and permissions to</p>

<pre><code>drwxr-xr-x  2 root          root   4096 Aug 30 19:53 data
</code></pre>

<p>Now with the elasticsearch process running a the elasticsearch user, this directory can longer be accessed.</p>

<p>I have set the pod's security context's fsGroup to 1000, to match the group of the elasticsearch group. I have set the container's security context's runAsUser to 0.  I have set various other combinations of users and group, but to no avail.  </p>

<p>Here is my pod, persistent volume claim, and persistent volume definitions.</p>

<p>Any suggestions are welcome.</p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: elasticfirst
  labels:
    app: elasticsearch

spec:
  securityContext:
    fsGroup: 1000

  containers:
  - name: es01
    image: docker.elastic.co/elasticsearch/elasticsearch:7.3.1
    securityContext:
      runAsUser: 0
    resources:
      limits:
        memory: 2Gi
        cpu: 200m
      requests:
        memory: 1Gi
        cpu: 100m
    env: 
      - name: node.name
        value: es01
      - name: discovery.seed_hosts
        value: es01
      - name: cluster.initial_master_nodes
        value: es01
      - name: cluster.name
        value: elasticsearch-cluster
      - name: bootstrap.memory_lock
        value: "true"
      - name: ES_JAVA_OPTS
        value: "-Xms1g -Xmx2g"
    ports:
    - containerPort: 9200
    volumeMounts:
    - mountPath: "/usr/share/elasticsearch/data"
      name: elastic-storage2
  nodeSelector:
    type: compute

  volumes:
  - name: elastic-storage2
    persistentVolumeClaim:
      claimName: elastic-storage2-pvc 



apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: elastic-storage2-pvc
spec:
  storageClassName: local-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 512Mi


apiVersion: v1
kind: PersistentVolume
metadata:
  name: elastic-storage2-pv
spec:
  storageClassName: local-storage
  capacity:
    storage: 512Mi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /var/tmp/pv
</code></pre>

<p>Your question is a tiny bit confusing about what is happening versus what you want to be happening, but in general that problem is a common one; that's why many setups use an <code>initContainer:</code> to change the ownership of freshly provisioned PersistentVolumes (<a href="https://github.com/bitnami/charts/blob/2ba572d7ec51d5ff9ecd47f5748aab308aef693e/bitnami/cassandra/templates/statefulset.yaml#L62-L72" rel="nofollow noreferrer">as in this example</a>)</p>

<p>In such a setup, the <code>initContainer:</code> would run as root, but would also presumably be a very thin container whose job is only to <code>chown</code> and then exit, leaving your application container -- elasticsearch in your example -- free to run as an unprivileged user</p>

<pre><code>spec:
  initContainers:
  - name: chown
    image: busybox
    command:
    - chown
    - -R
    - "1000:1000"
    - /the/data
    volumeMounts:
    - name: es-data
      mountPoint: /the/data
 containers:
 - name: es
   # etc etc
</code></pre>
