Ibexa DXP Discussions

Community discussion forum for developers working with Ibexa DXP

Install eZ Platform 2.2 with eZ Launchpad

Good evening guys,

I am trying to install the latest version of ez Platform through eZ LunachPad (ez init)

Apparently there is a problem with solr. problem of rights !!!

ez logs display

solr_1 | mkdir: cannot create directory ‘/ezsolr/server/ez’: Permission denied
solr_1 | cp: cannot create regular file ‘/ezsolr/server/ez’: Permission denied
solr_1 | cp: target ‘/ezsolr/server/ez/template’ is not a directory
solr_1 | sed: can’t read /ezsolr/server/ez/template/solrconfig.xml: No such file or directory
solr_1 | sed: can’t read /ezsolr/server/ez/template/solrconfig.xml: No such file or directory
solr_1 | sed: can’t read /ezsolr/server/ez/template/solrconfig.xml: No such file or directory
solr_1 |
solr_1 | Solr home directory /ezsolr/server/ez not found!

I find it strange that it works for others and for solr no (right case)

Thank you

I’ve experienced this. The core data files were being stored on the dev machines so my pull request to change that location was accepted. I’m trying to remember the details.

You mentioned platform.sh so you are going to run into some things with your project. First multi-core isn’t ready for ez+p.sh. I do have single core working. With your solr core settings you have to move them inside the .platform folder in the root of your project so instead of using the default ezlaunchpad docker-compose path you will have to modify that OR keep two copies of your solr core configs sync by some method. This is because platform.sh needs to know where your solr core config files live since p.sh rebuilds on each commit the first thing p.sh has is what’s inside the .platform folder. So that’s 100% what you will need to do. Also a note if you are an enterprise subscription any of these solr config changes HAVE to be submitted as a support ticket to p.sh for a p.sh engineer to handle the deployment. That hit us as a surprise that there are parts that need p.sh to handle. In my opinion that’s crazy to have to wait for a ticket to be completed but that’s the reality and I want you to know that up front because it took us by surprise.

Here is my .platform/services.yaml

    type: solr:6.6
    disk: 1024
        # single core
                conf_dir: !archive "solr/mycores/main/conf"
                core: main

So essentially I stopped using the shared volume of /ezsolr/server/ez . I decided to embrace the original docker solr container and use the /opt/solr/server/solr for running my solr server. I think I even deleted the solr/entrypoint.bash file. You can manually get the ez solr core templates from that bundle so you can create your solr cores by hand.

Our Setup:


my docker-compose.yml (provisioning/dev/docker-compose.yml)

        image: solr:6.6
            - '${PROJECTCOMPOSEPATH}/.platform/solr/mycores:/opt/solr/server/solr/mycores:rw'
            - '${PROJECTCOMPOSEPATH}/.platform/solr/solr.xml:/opt/solr/server/solr/solr.xml:rw'
            - 'engine:rw'
            - engine
            - SOLR_HOME=/opt/solr/server/solr
            - '${PROJECTPORTPREFIX}983:8983'

The docker solr container being used is smart enough to detect any cores being in a shared volume and will auto-import them into solr. There are a ton of permission errors when it comes to docker so welcome to the docker permissions issue club.

The BIG issue was p.sh handled the location of the solr_home environment variable. You will need to update your solrconfig.xml file for each of your cores on line 101 to <dataDir>${solr.solr.home}/${solr.core.name}</dataDir> This will work for p.sh and local dev on docker. I still need to work with Sebastien to get all this implemented so it works automatically. We are telling each core to store it’s index data file to be kept out of the shared volume and only live inside the container. That should solve the permissions since solr is being run and the uid doesn’t match your dev user I’m assuming.

I ran into so many docker permissions issues not just for ezlaunchpad but personal projects. I have a nodejs project that is using something called fixuid. It’s kinda what Sebastien does in the entrypoint.bash files for making sure the uid’s match. Check out my provisioning stuff in this repo. https://github.com/raupie/nodejs-sandbox It could be nice to implement this package into ezlaunchpad someday.

Hope this helps. Sorry it’s lengthy!

1 Like

My hope is to have a pull request for refactoring the way ezlaunchpad deals with solr. I have a good start but ran into a few issues with trying to understand how ezlaunchpad works. I needed to add some steps in the init/create process and couldn’t figure out where to do that or what the best way is.

1 Like


Thank you for your reply

I’m sorry for the delay.

It was just a personal project. I did not understand everything that had to be done. at the end I took the solr file of another project and paste it on instance then launch an ez create and it worked

By cons I think we must review the command ez init it never worked for me dice the first time.

Actually, on the project files I told you, they made the change in the solrconfig.xml file

Thank you for your repo :slight_smile:



ez init is working and it is part of the Travis build then we are always sure it is working.

Solr config on platform.sh is indeed a “TODO” thanks @travis.raup for the sharing.

@amine-betari make sure you are always using the last version of eZ Launchpad because a permission issue has been fixed here: https://github.com/ezsystems/launchpad/commit/0a669fe750dfc1bdbd4a48fe5c74b18e461de70c#diff-f2bce05603ebdee6ac263523ea4dd54a

Solr data are in the container now.

Regarding your issue:
/ezsolr/server/ez is a mount : https://github.com/ezsystems/launchpad/blob/master/payload/dev/docker-compose.yml#L26

So somehow the container could not write on the provisioning/dev/solr of your project. There is no real reason for that.
Please check the permissions of provisioning/dev/solr and it should fix your issue.