"pelias elastic start" command is successful only for user 1001

[limal]

Please state in the README.md that it's not possible to run pelias commands unless you're a default user, i.e. 1001.

Once I switched from user 1002 back to 1001 below exception stopped occurring and I was able to run pelias elastic wait successfully.

ElasticsearchException[failed to bind service]; nested:
AccessDeniedException[/usr/share/elasticsearch/data/nodes];

[missinglink]

This certainly isn't true as the default UID on most Linux systems is 1000 and 501 on MacOS, both of which work.

We've made a fairly decent attempt at detecting the correct permissions but it's impossible to cover every situation, you can always 777 the directories if you prefer.

https://github.com/pelias/docker/blob/master/lib/env.sh

[missinglink]

When you first run the elastic container it checks for a directory and, if that doesn't exist, it creates it with permissions for the current user.

If you subsequently change user to another user which doesn't have permissions to use that directory, then it will fail as expected.

Use of sudo is explicitly discouraged and we detect the underlying user instead.

If you're interested in reporting a bug which isn't covered by this behavior you'll need to include information about your system.

[Phu2]

I think that the current approach of trying to enforce the same UID on the host and in the container does not work in cases where the host and the container are using different user namespaces.

For example, on my host machine i have created a user pelias with UID 1067. After executing pelias elastic wait i'm running into the same AccessDeniedException as mentioned earlier. If i change the permissions of the data dir to 777 the elasticsearch container starts properly. The created sub directories and files belong to 101067! Why is that?

In my setup (using sysbox) all containers are created in the namespace 100000.100000. The container's UID mapping:

me@mylaptop$ docker exec f8b080d6bec2 cat /proc/self/uid_map
         0     100000      65536

This means that UID 1067 in the container becomes UID 101067 on the host !

In order to avoid such mismatch i go like this:

• create a host user myuser with UID/GID 101000
• this user owns the directory which is mounted into the container
• add line containing myuser:100000:65536 to /etc/subuid and /etc/subgid on the host
• tell docker to use this UID/GID mapping (/etc/docker/daemon.json)
• use the (first/default) user with UID/GID 1000 in the container

This way the container user (uid=1000) is able to write to the mounted directory.

See also https://ilya-bystrov.github.io/posts/docker/docker-daemon-remapping=.html