Can't install readOnlyREST - "NoSuchFileException"

I am installing readOnlyREST version 1.33.1 for elasticsearch version 7.12.0 on Centos 7.9.

I have confirmed that I am running elasticsearch 7.12.0 and that the readOnlyREST plugin version that I have is for elasticsearch 7.12.0.

I obtained the plugin from Download - ReadonlyREST and chose ‘Free Elasticsearch plugin’ for version 7.12.0.

I have placed the plugin in /tmp (on one of my es nodes) for install and am running the following command:
bin/elasticsearch-plugin install file:///tmp/

I get the error:
→ Installing file:///tmp/
→ Downloading file:///tmp/
[==================] 100%
→ Failed installing file:///tmp/
→ Rolling back file:///tmp/
→ Rolled back file:///tmp/
Exception in thread “main” java.nio.file.NoSuchFileException: /usr/share/elasticsearch/plugins/.installing-10979668457297620804/
at java.base/sun.nio.fs.UnixException.translateToIOException(
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(
at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(
at java.base/java.nio.file.Files.newByteChannel(
at java.base/java.nio.file.Files.newByteChannel(
at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(
at java.base/java.nio.file.Files.newByteChannel(
at org.elasticsearch.plugins.PluginInfo.readFromProperties(
at org.elasticsearch.plugins.InstallPluginCommand.loadPluginInfo(
at org.elasticsearch.plugins.InstallPluginCommand.installPlugin(
at org.elasticsearch.plugins.InstallPluginCommand.execute(
at org.elasticsearch.plugins.InstallPluginCommand.execute(
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(
at org.elasticsearch.cli.MultiCommand.execute(
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(
at org.elasticsearch.cli.Command.main(
at org.elasticsearch.plugins.PluginCli.main(

If I unzip the file I can see that there is a file in there and the file contains the version numbers that I would expect to see.

I’ve tried watching the /usr/share/elasticsearch/plugins/ directory during the install process to verify that the “.installing-10979668457297620804” directory is actually being created, but it’s not clear to me whether it is or not,

I’ve ensured that there are no permissions issues with the file or the plugin directory.

I’m out of ideas now, I’ve found a few similar issues online but the solutions don’t apply to my situation (i.e. the problem is usually to do with having the wrong plugin version or trying to install the plugin from the wrong directory etc).

(Edit: just to add (because I have seen this being a solution in other similar forum posts), I only have one version of elasticsearch installed on this server and it was installed from fresh as 7.12.0, I didn’t go through an es upgrade process.)

(Edit again: I have set up a completely separate fresh server with a fresh install of elasticsearch 7.14.0 and had a go at installing the corresponding readOnlyREST plugin - I have the exact same error - so this is baffling.)

Hi @joemo2023 thanks for reaching out!
The file name is not what it should be, normally I would expect something along the lines of “”.

Are you sure the download process went all right? It should be a zip file that definitely contains a property files.

$ jar -ft |grep properties

What does your file contain?

Hi @sscarduzio

$ jar -ft | grep properties

As soon as I saw the output of that command I realised what had happened…my zip file contains a directory as opposed to just the files, which is why it couldn’t find the properties file during installation. I’m not sure how that happened…I suspect at some point it was unzipped into a directory and then rezipped (which would also explain the abnormal zip name).

I created a new zip file containing just the files and it is now working.

Thanks for pointing me in the right direction.

1 Like

Yes, and the re-zip must have happened somewhere on your side, because otherwise I can’t explain the “__MACOSX” directory coming out of our CI pipeline :grinning_face_with_smiling_eyes:

Yeah definitely something that happened on my end, it all worked perfectly once the zip was restored to it’s original downloaded state.
Many thanks

1 Like