chown: changing ownership of '/data/db': Operation not permitted

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

I am running the pod with MongoDB. Getting the error

chown: changing ownership of '/data/db': Operation not permitted .

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

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

Solution 1:

chown: changing ownership of '/data/db': Operation not permitted .

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

Approach #1:

containers:
- name: mongo
  image: mongo:something
  securityContext:
    runAsUser: 0

(which may require altering your cluster's config to permit such a thing to appear in a PodSpec)

Approach #2 (which is the one I use with Elasticsearch images):

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

Solution 2:

/data/db is a mountpoint, even if you don't explicitly mount a volume there. The data is persisted to an overlay specific to the pod. Kubernetes mounts all volumes as 0755 root.root, regardless of what the permissions for the directory were intially. Of course mongo cannot chown that.

If you mount the volume somewhere below /data/db, you will get the same error.

And if you mount the volume above at /data, the data will not be stored on the NFS because the mountpoint at /data/db will write to the overlay instead. But you won't get that error anymore.