Installing carrot2 plugin inside an elasticsearch docker container results in AccessControlException
See original GitHub issueI am using the following software versions
- docker v1.9.1
- elasticsearch v2.1.1
- elasticsearch-carrot2 v2.1.1
I am trying to create a docker container running elasticsearch with the carrot2 plugin. Assuming you have docker installed, the following is what I do.
- mkdir /var/data/es
- docker pull elasticsearch:2.1.1
- docker run -d -v /var/data/es:/usr/share/elasticsearch/data --name=es -p 9200:9200 -p 9300:9300 elasticsearch:2.1.1 elasticsearch -Des.cluster.name=elasticsearch
- docker exec es plugin install org.carrot2/elasticsearch-carrot2/2.1.1
- docker restart es
The docker container es
dies. Then I type in docker logs -f es
and the following is what I see.
Exception in thread "main" ElasticsearchException[Could not start Carrot2 controller.]; nested: AccessControlException[access denied ("java.io.FilePermission" "src/main/config" "read")]; Likely root cause: java.security.AccessControlException: access denied ("java.io.FilePermission" "src/main/config" "read") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at sun.nio.fs.UnixPath.checkRead(UnixPath.java:795) at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:49) at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144) at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99) at java.nio.file.Files.readAttributes(Files.java:1737) at java.nio.file.Files.isDirectory(Files.java:2192) at org.carrot2.elasticsearch.ControllerSingleton.doStart(ControllerSingleton.java:66) at org.elasticsearch.common.component.AbstractLifecycleComponent.start(AbstractLifecycleComponent.java:68) at org.elasticsearch.node.Node.start(Node.java:242) at org.elasticsearch.bootstrap.Bootstrap.start(Bootstrap.java:221) at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:287) at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35) Refer to the log for complete error details.
I then take a look at ControllerSingleton at https://github.com/carrot2/elasticsearch-carrot2/blob/master/src/main/java/org/carrot2/elasticsearch/ControllerSingleton.java#L66. Why is this clazz looking for src/main/config
?
The directory src/main/config
does not exists in the docker container, as verified by, docker exec es ls -l
.
I used to work with elasticsearch v1.5.2 and elasticsearch-carrot2 v1.8.0, and creating the docker container and installing the carrot2 plugin the way I described above worked. Any ideas?
Issue Analytics
- State:
- Created 8 years ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
In case anybody still have the issue, we had the same problem with version 2.3.2 and 2.3.4. The solution is not elegant but apparently works.
If we just install the plugin with the other in the container carrot2 is installed by the configuration files are not there.
adding an additional RUN command to remove an install again the plugin does retain the config file in the plugin directory, but the carrot2 expects to see them in the config directory, so we added an other RUN command to copy them where they are expected. these are the Dockerfile lines for the fix.
Would be nice to understand what is going on there, and have docker supported…
You should report this problem to ElasticSearch’s docker maintainers. The problem is that the default ES container is created on top of an existing (Debian?) distribution.
After starting the container the configuration files are in
/usr/share/elasticsearch
, but theplugin
script shipped with ES is incorrect – it sets it to/etc/elasticsearch
(and this folder contains some junk unused config files too).The result of this is that the installed plugin’s configuration files get copied to an incorrect location under
/etc/elasticsearch
and are then not found at runtime.A workaround is to specify CONF_DIR manually when installing the plugin:
I just checked with version 2.3.2 and everything started just fine.