<p>Can we use nfs volume plugin to maintain the High Availability and Disaster Recovery among the kubernetes  cluster?</p>

<p>I am running the pod with MongoDB. Getting the error </p>

<blockquote>
  <p>chown: changing ownership of '/data/db': Operation not permitted .</p>
</blockquote>

<p>Cloud any body, Please suggest me how to resolve the error? (or)</p>

<p>Is any alternative volume plugin is suggestible to achieve HA- DR in kubernetes cluster?</p>

BSG
<blockquote>
  <p>chown: changing ownership of '/data/db': Operation not permitted .</p>
</blockquote>

<p>You'll want to either launch the mongo container as <code>root</code>, so that you <em>can</em> <code>chown</code> the directory, or if the image prohibits it (as some images already have a <code>USER mongo</code> clause that prohibits the container from escalating privileges back up to <code>root</code>), then one of two things: supersede the user with a <code>securityContext</code> stanza in <code>containers:</code> or use an <code>initContainer:</code> to preemptively change the target folder to be the mongo UID:</p>

<p>Approach #1:</p>

<pre><code>containers:
- name: mongo
  image: mongo:something
  securityContext:
    runAsUser: 0
</code></pre>

<p><em>(which may require altering your cluster's config to permit such a thing to appear in a <code>PodSpec</code>)</em></p>

<p>Approach #2 (which is the one I use with Elasticsearch images):</p>

<pre><code>initContainers:
- name: chmod-er
  image: busybox:latest
  command:
  - /bin/chown
  - -R
  - "1000"  # or whatever the mongo UID is, use string "1000" not 1000 due to yaml
  - /data/db
  volumeMounts:
  - name: mongo-data  # or whatever
    mountPath: /data/db
containers:
- name: mongo  # then run your container as before
</code></pre>
