Elasticsearch on docker: Volume mounted as root user leading to permission issue

Elastic Stack Elasticsearch
1

Hi,
I am trying to bring up an ES cluster on docker by following the instructions given here.

I am using named volume to provide persistence for the data. However docker-compose up fails due to permission issue. I see that it is mounted as root instead of 'elasticsearch' user.

docker-compose.yml:

version: '2.2'
services:
  es-docker-master1:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.3.0
    container_name: es-docker-master1
    environment:
      - cluster.name=es-prod-docker-cluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms4g -Xmx4g"
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    volumes:
      - es-master1:/data/es-data
      - "./es/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml"
    ports:
      - 9201:9200
    networks:
      - esnet
  es-docker-data1:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.3.0
    container_name: es-docker-data1
    environment:
      - cluster.name=es-prod-docker-cluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms14g -Xmx14g"
      - "discovery.zen.ping.unicast.hosts=es-docker-master1"
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    volumes:
      - es-data1:/data/es-data
      - "./es/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml"
    ports:
      - 9301:9300
    networks:
      - esnet

volumes:
  es-master1:
    driver: local
  es-data1:
    driver: local

networks:
  esnet:

Here's the folder permission on one of the container:

[root@adfe78904e50 elasticsearch]# ls -lrt /data/
total 0
drwxr-xr-x. 2 root root 6 Jun 21 10:03 es-data

What is the right way to mount it so that the folder has correct permissions?

The folder has ownership for UID:GID - 1000:1000 (which incidentally also happens to be the UID/GID of a local user on the host machine)

[airvana@es-data-host es-docker]$ cd /data/
[airvana@es-data-host data]$ ll
total 24
drwxrwxr-x. 4 airvana airvana 4096 Jun 21 18:15 es-data
drwxrwxr-x. 3 airvana airvana 4096 Jun 21 18:18 es-logs
[airvana@es-data-host data]$ id
uid=1000(airvana) gid=1000(airvana) groups=1000(airvana),10(wheel),372(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c
Thanks.

2

Could you format your docker-compose.yml with "triple ticks" ( ``` ) please? Then I can copy-paste it and try to reproduce the error.

Thanks.

3

Updated.
To add more details, in the elasticsearch.yml, I give

path.data: /data/es-data

It works if instead of named volume I use bind mounting.
i.e.

volumes:
  - "/data/es-data:/usr/share/elasticsearch/data"

But I read that named volume should be preferred over bind mounting so would like to get it to work with that. Thanks.

4

Thanks. I think you are experiencing a variant of this issue:

In short, the image has a strong expectation that you will mount your data volume at /usr/share/elasticsearch/data (and not set path.data).

Does it work for you if you mount your named volume at /usr/share/elasticsearch/data?

5

Thanks for your replies Toby.

volumes

  • es-master1:/usr/share/elasticsearch/data

If I add the volume info as above, then elasticsearch instances run but they are not using host filesystem for persistence. It is using /usr/share/elasticsearch/data on the container.
As I mentioned earlier, the only way I can get it to work is if I use bind mount as below:

volumes

  • "/data/es-data:/usr/share/elasticsearch/data"

Is there any drawback to use it in this manner?
Will go through the above thread. Thanks.

6

There's no drawback that I'm aware of.

Our recommendation is that you always mount your data folder at /usr/share/elasticsearch/data regardless of which Docker storage driver is providing the underlying storage. Elasticsearch doesn't know or care what the storage driver is, it just cares about the mountpoint.

7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.