Docker-openldap: Container fail to start with mounted volumes

[Dealus]

Hello,

Using this service:

  ldap_data:
        user: root
        image: busybox:1.24.2
        container_name: ldap_data
        environment:
          - "constraint:node==af-repo"
        networks:
            - appfactory_overlay
        volumes:
            - /c/Users/docker_volumes/ldap/slapd.d:/etc/ldap/slapd.d
            - /c/Users/docker_volumes/ldap/ldap:/var/lib/ldap
            - /c/Users/docker_volumes/ldap/certs:/container/service/slapd/assets/certs/

And this docker-compose file:

    ldap:
      user: root
      image: osixia/openldap:1.1.6
      container_name: ldap
      volumes_from:
          - container:ldap_data:rw
      ports:
          - "389:389"
          - "636:636"
      networks:
          - appfactory_overlay
      environment:
          - "constraint:node==af-repo"

The container fails to start with error:

ldap    | *** CONTAINER_LOG_LEVEL = 3 (info)
ldap    | *** Search service in CONTAINER_SERVICE_DIR = /container/service :
ldap    | *** link /container/service/:ssl-tools/startup.sh to /container/run/startup/:ssl-tools
ldap    | *** link /container/service/slapd/startup.sh to /container/run/startup/slapd
ldap    | *** link /container/service/slapd/process.sh to /container/run/process/slapd/run
ldap    | *** Set environment for startup files
ldap    | *** Environment files will be proccessed in this order :
ldap    | Caution: previously defined variables will not be overriden.
ldap    | /container/environment/99-default/default.yaml
ldap    | /container/environment/99-default/default.startup.yaml
ldap    |
ldap    | To see how this files are processed and environment variables values,
ldap    | run this container with '--loglevel debug'
ldap    | *** Running /container/run/startup/:ssl-tools...
ldap    | *** Running /container/run/startup/slapd...
ldap    | Database and config directory are empty...
ldap    | Init new ldap server...
ldap    | invoke-rc.d: policy-rc.d denied execution of stop.
ldap    |   Creating initial configuration... done.
ldap    |   Creating LDAP directory... failed.
ldap    | Loading the initial configuration from the ldif file () failed with
ldap    | the following error while running slapadd:
ldap    |     58134894 bdb(dc=example,dc=org): BDB0126 mmap: Invalid argument
ldap    |     58134894 hdb_db_open: database "dc=example,dc=org" cannot be opened, err 22. Restore from backup!
ldap    |     58134894 bdb(dc=example,dc=org): BDB1566 txn_checkpoint interface requires an environment configured for the transaction subsystem
ldap    |     58134894 bdb_db_close: database "dc=example,dc=org": txn_checkpoint failed: Invalid argument (22).
ldap    |     58134894 backend_startup_one (type=hdb, suffix="dc=example,dc=org"): bi_db_open failed! (22)
ldap    |     slap_startup failed
ldap    | *** /container/run/startup/slapd failed with status 1
ldap    |
ldap    | *** Killing all processes...

While removing the volume /c/Users/docker_volumes/ldap/ldap:/var/lib/ldap works fine !

[osixia]

This happend on Windows ?

[Dealus]

It did indeed, using docker-machine on virtualbox hosts.

[mateusmedeiros]

Same thing happened to me on Windows before and is also happening now on an Amazon Linux container created with an Amazon ECS service.

It has a mounted volume for the database (and the mounted volume is also an NFS mount on the host).

EDIT:

Ok, it happens at this line https://github.com/osixia/docker-openldap/blob/1ed91b47cd1602ba679b696a232255c09e8b5502/image/service/slapd/startup.sh#L91, in the dpkg reconfigure.

I'm not entirely sure if the windows problem and the amazon linux problem are the same yet, this is debugging on my amazon linux machine. The errors I had mounting a windows path were basically the same, though.

EDIT 2:

From what I understand, in the case of my Amazon Linux instance, the NFS volume really seems to be the one to blame. The problem with Windows may be related, though not exactly the same. I'm guessing it has something to do with the way those drives are mounted on Windows, but I don't know for sure.

Anyway, I resolved my problem with the Amazon Linux instance by changing those NFS volumes to normal storage volumes.

[blackknight36]

Anyway, I resolved my problem with the Amazon Linux instance by changing those NFS volumes to normal storage volumes.

Although this issue is a few years old there is still a problem with running openldap on top of an NFS backed data directory. Any attempt to run a container using a volume backed by NFS causes the container to fail to start. Gluster backed volumes do not exhibit this behavior but they do cause problems with postgresql images.

[fc-dan]

I am running into the same issue on AWS with not being able to start the container with existing volumes for /etc/ldap/slapd.d and /var/lib/ldap. Is this being worked on?

[obourdon]

All, sorry to say so but the problem might not be within the docker container but with the way NFS server/service is configured and, if not using NFS, with user permissions that the mounted volumes effectively support (I even sometimes have the same kind of issue on MacOSX). Indeed, as the container is trying to chown/chmod some files (config or data, it does not matter) so that the OpenLDAP service can properly access them and so that there as few security issues as possible, these permissions might very well not be mapped to the underlying volume. There is no magic in that process, it can not work transparently and in all cases if the criteria are not met.

Using docker volumes, which can be mapped to EBS/EFS or other underlying platform resilient storage engines should prevent this kind of issue to occur.

Just wondering ....

[blackknight36]

Even outside of a container slapd will not work with data stored on an NFS volume. I've ran into this issue a few times over the last few years and the only solution is to move the /var/lib/ldap directory to a local disk.

[piwo1984]

I also had this issue while using vagrant and synced_folders where the data lifes in.
I changed my vagrantfile and added mount_options to overcome this:

config.vm.synced_folder "/d/folder/on/windows/system", "/folder/on/vm",  mount_options: ["dmode=775,fmode=777"]