# Elastic/elasticsearch-docker not assigning permissions to data directory on run

**URL:** <https://discuss.elastic.co/t/elastic-elasticsearch-docker-not-assigning-permissions-to-data-directory-on-run/65812>\
**Category:** Elasticsearch\
**Created:** [November 11, 2016, 1:49pm UTC](https://discuss.elastic.co/t/elastic-elasticsearch-docker-not-assigning-permissions-to-data-directory-on-run/65812 "2016-11-11T13:49:53Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![dliappis](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dliappis/32/56174_2.png) [@dliappis](https://discuss.elastic.co/u/dliappis)\
**Post date:** [November 14, 2016, 9:50am UTC](https://discuss.elastic.co/t/elastic-elasticsearch-docker-not-assigning-permissions-to-data-directory-on-run/65812/2 "2016-11-14T09:50:58Z")

</div>

Hello Aleksandr,

Thank you for your interest in the Elasticsearch images.

There are a number of different issues you are having in your setup.  
The permission errors you are getting in your example are because you are using a **host dir** as a data volume that doesn't match the uid/gid of the elasticsearch user in the image. Details in 2).

###1) Tuning Elasticsearch configuration parameters

The way that you were thinking of running the image, i.e. **creating your own custom image** based on the Elastic one is fine, but you need to remember to `chown` the `ADD`'ed configuration files in your `Dockerfile` to the user/group `elasticsearch`. This is something done in the Elasticsearch Dockerfile right after copying `elasticsearch.yml`, as shown [here](https://github.com/elastic/elasticsearch-docker/blob/5.0/build/elasticsearch/Dockerfile#L29):

So your `Dockerfile` would then look like:

```auto
FROM docker.elastic.co/elasticsearch/elasticsearch:5.0.0

ADD jvm.options /usr/share/elasticsearch/config/
ADD elasticsearch.yml /usr/share/elasticsearch/config/
USER root
RUN chown elasticsearch:elasticsearch config/jvm.options config/elasticsearch.yml

USER elasticsearch
EXPOSE 9200 9300

```

For example, using a simple `elasticsearch.yml` file:

```auto
$ cat elasticsearch.yml 
cluster.name: "custom-cluster"
network.host: 0.0.0.0

```

and the same `jvm.options` as in the original image with a change of -Xms/-Xmx to 1G, a new image can be built using

`docker build -t myes .`

and running it with:

`docker run -ti -p 9200:9200 -v /usr/share/elasticsearch/data myes`

produces a working image with the right permissions under `config/`

_NOTE_: If you were to omit the `chown` commands `elasticsearch.yml/jvm.options` would be owned by `0:0` as documented in the [Dockerfile ADD section](https://docs.docker.com/engine/reference/builder/#/add) but it wouldn't be catastrophic for the Elasticsearch start as it would still have read access to those files. Still it's best practice to `chown` then files afterwards. I will update the documentation to warn about that for this configuration method.1

_NOTE2_: You should be using `FROM: docker.elastic.co/elasticsearch/elasticsearch:THEVERSION` as opposed to relying on latest. Right now we have `5.0.0` and soon we will be pushing `5.0.1` (docker image versions are matching the Elasticsearch ones). Please try not to rely on `:latest` as it may bring whatever staging build and indeed, going forward, we will be deprecating `:latest` to avoid customers ending up with broken configurations.

### 2) Data volumes versus local mounts for `/usr/share/elasticsearch/data`

As you correctly mentioned in the README we recommend the use of a **named volume**. With docker cli this is accomplished with `-v <nameofvolume>:/usr/share/elasticsearch/data`. This volume will be created if not already present and can be seen with `docker volume ls`. The volume will persist even if you destroy the container, unless you explicitly remove it with `docker volume rm <nameofvolume>`.

In your `docker-compose.yml` example, however, you are using a host mounted directory (`/data/elasticsearch1/`). This will result in `/usr/share/elasticsearch/data` having the same permissions as your local dir. Therefore unless `/data/elasticsearch/` is owned by `1000:1000` or chmod'ed to `777`, Elasticsearch won't be able to write there! 2  
So you will either need to make sure your local dir is `chown -R elasticsearch:elasticsearch /data/elasticsearch1` before running the container or use non-host based data volumes.

The `docker-compose.yml` syntax for data volumes looks like:

```auto
# ...
    volumes:
      - esdata1:/usr/share/elasticsearch/data
volumes:
  esdata1:
    driver: local

```

Alternatively, if you don't mind ending up with a randomly named volume you can use

```auto
# ...
    volumes:
      - /usr/share/elasticsearch/data

```

The difference between `data volumes` and `host mounted data volumes` are described in the [Docker Documentation](https://docs.docker.com/engine/tutorials/dockervolumes/).

### Notes:

1: The Docker documentation will very soon be part of the docs on the Elastic web site, so stay tuned! The documentation for Kibana on Docker is already there: [https://www.elastic.co/guide/en/kibana/current/install.html](https://www.elastic.co/guide/en/kibana/current/install.html)

2: There are number of Docker feature requests to add support for setting the uid/gid when mounting local dirs e.g. [https://github.com/docker/docker/issues/2259;](https://github.com/docker/docker/issues/2259;)

---

_[View the full topic](https://discuss.elastic.co/t/elastic-elasticsearch-docker-not-assigning-permissions-to-data-directory-on-run/65812)._