Elasticsearch 1.7.0 fails to start on docker4mac 1.11.1-beta10

This was reported in Can’t start elasticsearch with mounted data directory - [f]stat[v]fs family of functions but the topic is now closed and I can’t comment there. On April 8, davetucker mentionned

The [f]stat[v]fs family of functions is not yet supported by the Docker for Mac file-sharing solution, osxfs. We have plans to implement the necessary functionality to support both querying file system metadata and sharing the OS X mount table with bind-mounting containers. This support should arrive within the next 2 to 3 weeks so keep watching the changelog, updating your installation, and trying again once more mount point support lands!

I combed the release notes since april 8 but it is unclear to me if this is supposed to be fixed by now or not.
Topic Unable to access volumes using osxfs ("/Mac: Socket not connected") - [f]stat[v]fs family of functions seems related (as it has the same tags fstat,statvfs) and the last comment says fixed in beta 9… but elasticsearch still doesn’t work.

So what’s the status on this ?


Steps to reproduce the behavior

mkdir -p /tmp/esdata mkdir -p /tmp/esconfig docker run -v /tmp/esdata:/usr/share/elasticsearch/data -v /tmp/esconfig:/usr/share/elasticsearch/config -p 9200:59200 elasticsearch:1.7.0

Expected behavior

log4j:WARN No appenders could be found for logger (node). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

Actual behavior

log4j:WARN No appenders could be found for logger (node).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
{1.7.0}: Initialization Failed …

  • ElasticsearchIllegalStateException[Failed to created node environment]
    FileSystemException[/usr/share/elasticsearch/data: Function not implemented]
    org.elasticsearch.ElasticsearchIllegalStateException: Failed to created node environment
    at org.elasticsearch.node.internal.InternalNode.(InternalNode.java:167)
    at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:159)
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:77)
    at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:245)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32)
    Caused by: java.nio.file.FileSystemException: /usr/share/elasticsearch/data: Function not implemented
    at sun.nio.fs.UnixException.translateToIOException(UnixException.java:91)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
    at sun.nio.fs.UnixFileStore.readAttributes(UnixFileStore.java:111)
    at sun.nio.fs.UnixFileStore.getTotalSpace(UnixFileStore.java:118)
    at org.elasticsearch.monitor.fs.JmxFsProbe.getFSInfo(JmxFsProbe.java:61)
    at org.elasticsearch.env.NodeEnvironment.maybeLogPathDetails(NodeEnvironment.java:201)
    at org.elasticsearch.env.NodeEnvironment.(NodeEnvironment.java:176)
    at org.elasticsearch.node.internal.InternalNode.(InternalNode.java:165)
    … 4 more


$ pinata diagnose -u OS X: version 10.11.3 (build: 15D21) Docker.app: version v1.11.1-beta10 Running diagnostic tests: [OK] docker-cli [OK] Moby booted [OK] driver.amd64-linux [OK] vmnetd [OK] osxfs [OK] db [OK] slirp [OK] menubar [OK] environment [OK] Docker [OK] VT-x Docker logs are being collected into /tmp/20160510-092122.tar.gz Most specific failure is: No error was detected Your unique id is: B8782C83-6640-4473-A217-C9C74348F192 Please quote this in all correspondence.
OSX 10.11.3

Does it work if you use an implicit volume for the Elasticsearch data store? The image declares a VOLUME "/usr/share/elasticsearch/data" so if you leave off the docker run -v option using a host directory there you’ll get an automatically created volume, or you can use explicit named volumes in current versions of Docker.

(Elasticsearch is on a list of things that have never worked with host directories for their data store for me on a Mac, on Docker Machine because the permissions were always wrong, and so I just switched my Mac development workflow to using the automatically created volume and never had trouble with it.)

Thanks for your suggestion. It looks like ES uses special calls on the data directory not on the confi directory so :

docker run -v app1-esdata:/usr/share/elasticsearch/data -v /tmp/esconfig:/usr/share/elasticsearch/config -p 59200:9200 elasticsearch:1.7.0

works and I still have direct access to the config files to tweak them. I don’t really need direct access to the data files.

Just to confirm, this hasn’t been fixed yet. It’s on our bug tracker as (#3099) and that should show up as fixed in the changelog once this has been implemented. Thanks for the feedback and for participating in the beta


Looking forward to this fix. However can you please advise where to find the change log? Sorry if it is obvious, but I’ve DoSed Google trying to find it!

This was fixed in Beta 14 but wasn’t well marked. See https://beta.docker.com/docs/mac/release-notes/ for the changelog.

Thanks for participating in the Docker for Mac Beta!