libapparmor.so.1: cannot open shared object file: No such file or directory

[kstenerud]

Not sure if this rates as a samba, docker, or ubuntu issue, but:

# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
2c93025ecbcf        ubuntu:latest       /bin/bash           11 seconds ago      Up 11 seconds                           grave_sammet     
# docker run --rm -v $(which docker):/docker -v /var/run/docker.sock:/docker.sock svendowideit/samba grave_sammet
/docker: error while loading shared libraries: libapparmor.so.1: cannot open shared object file: No such file or directory

Yet apparmor does exist:

# ldconfig -v|grep apparmor
    libapparmor.so.1 -> libapparmor.so.1.1.0

Running on Ubuntu server 14.04.

[cdancy]

Have the same issue, using the same container, trying to pass the docker binary to the container. Have you found a workaround?

[cdancy]

I can confirm that testing under CentOS 7 (as host machine with ubuntu 14.04 as container) I get a similar issue though it's 'libdevmapper.so.1.02' that can't be loaded.

[clzhao]

@cdancy Have you got a solution for this problem ("I can confirm that testing under CentOS 7 (as host machine with ubuntu 14.04 as container) " ) , or you have tried other ways to do so? Hoping for your response. Thanks a lot !

[cdancy]

@carlye566 no longer using centos7. Switched to arch linux, which is always updating to the latest version of docker, and have never seen this problem. I use RedHat7 at work, which should loosely mirror centos7, and I don't see the issue there either.

[clzhao]

@cdancy OK. Thank you all the same!

[tomfotherby]

I get this problem with Ubuntu 15.04 and docker v1.7.1 since I changed getting docker from the lxc-docker repo to the docker-engine repo (following the latest blog post (NEW APT AND YUM REPOS))

I can reproduce it using this command:

$ docker run --rm -it \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/bin/docker:/usr/bin/docker \
ubuntu docker --version

> error while loading shared libraries: libapparmor.so.1: cannot open shared object file: No such file or directory

(This runs a docker --version command but from within a ubuntu docker container that shares the docker binary and the docker socket from the host)

[tomfotherby]

I found a workaround (but the fix is specific to Ubuntu 15.04). I can get my docker commands working if I bind-mount the missing library using -v /lib/x86_64-linux-gnu/libapparmor.so.1:/lib/x86_64-linux-gnu/libapparmor.so.1. Example:

$ docker run --rm -it \
-v /:/h \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/bin/docker:/usr/bin/docker \
-v /lib/x86_64-linux-gnu/libapparmor.so.1:/lib/x86_64-linux-gnu/libapparmor.so.1 \
ubuntu docker --version

> Docker version 1.8.1, build d12ea79

(The host location of the libapparmor.so will vary depending on the host OS, Ubuntu 15.04 is different from 14.04 for example). On 14.04 use -v /usr/lib/x86_64-linux-gnu/libapparmor.so.1.1.0:/lib/x86_64-linux-gnu/libapparmor.so.1

[cuongtransc]

If you are using ubuntu 14.04, I need mount libapparmor.so.1.1.0 on physical to libapparmor.so.1 on docker. Because, on physical server, libapparmor.so.1 symbol link to libapparmor.so.1.1.0. Example:

docker run -it --rm \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/bin/docker:/usr/bin/docker \
    -v /usr/lib/x86_64-linux-gnu/libapparmor.so.1.1.0:/usr/lib/x86_64-linux-gnu/libapparmor.so.1 \
    ubuntu:14.04 docker --version

[ryuheechul]

this volume mounting below worked with me on ubuntu host.

-v /usr/lib/x86_64-linux-gnu/libapparmor.so.1.1.0:/lib/x86_64-linux-gnu/libapparmor.so.1

[rocktavious]

The above volume mounting worked for me too on ubuntu 14.04 with docker 1.8.1

[jverdeyen]

:+1: Worked for me

[chrisskilton]

Just hit this in docker (1.8.2) running on Debian (wheezy).

Running: docker run -v /usr/lib/x86_64-linux-gnu/libapparmor.so.1.1.0:/lib/x86_64-linux-gnu/libapparmor.so.1 -v "$(which docker):$(which docker)" ubuntu docker --version;

yields:

docker: error while loading shared libraries: /lib/x86_64-linux-gnu/libapparmor.so.1: cannot read file data: Error 21

Even with the volume mount the error still occurs. Will there be a fix for this or is it going to be handled with a workaround? Any ideas why the workaround isn't working for me? Note: I don't seem to hit this problem from OSX (via boot2docker)

[ghost]

try install lxc

[michaeljs1990]

For anyone else who runs into this installing lxc on your box will fix this.

[arpheno]

i just tried to fix this by running apt-get install lxc on jessie, but no success.

[michaeljs1990]

@arpheno did you install on the machine running the docker daemon or on the actual container?

[MichaelMackus]

I just did an apt-get install lxc on trusty (host running the daemon). Also tried restarting the daemon with no success.

This run command is working for me:

docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v $(which docker):/bin/docker -v /usr/lib/x86_64-linux-gnu/libapparmor.so.1.1.0:/lib/x86_64-linux-gnu/libapparmor.so.1 ubuntu bash

Would be nice to have this working without the (ugly) libapparmor mount, but it works!

[michaeljs1990]

@MichaelMackus just install lxc on the actual docker container.

[MichaelMackus]

Doh! Thanks @michaeljs1990 that worked :)

[ghostsquad]

fix for centos7: include -v /usr/lib64/libdevmapper.so.1.02:/usr/lib64/libdevmapper.so.1.02

[AlexTelon]

Trying to set up so a container can run docker without having docker-in-docker as proposed here.

So when running: docker run -v /var/run/docker.sock:/var/run/docker.sock -v $(which docker):/bin/docker -it lxc bash I get this error:

docker: /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1: versionDM_1_02_97' not found (required by docker)`

lxc img is built with following Dockerfile

FROM ubuntu:14.04
RUN apt-get update && apt-get install -y lxc

And host is running ubuntu 15.10

(ugly) solution

The ugly way (and only that I've found now) is to add -v /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1:/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 to your docker run command.

This only solves the symptom and not the problem so I tried to figure out how to get the proper lib to the container.

My attempt at a nicer solution

It seems from this that the issue might be that installing lxc through apt-get does not get a sufficiently new version of the lib. This would explain why installing lxc worked before but now now.

Host > docker version

Client:
 Version:      1.10.0
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   590d5108
 Built:        Thu Feb  4 18:41:30 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.0
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   590d5108
 Built:        Thu Feb  4 18:41:30 2016
 OS/Arch:      linux/amd64

I tried to update to a newer version of lxc hoping that that would bring the correct version of the lib file with it but to no avail. (from ppa:ubuntu-lxc/daily). Maybe /stable or something would work but I gave up here.

[cdancy]

I don't understand why folks still try to do a docker-in-docker. There are numerous libraries, seemingly for every language, to work with dockers remote API.

[ghostsquad]

@cdancy I think the point is that we want to enable apps, scripts, etc to use docker without reinventing the wheel. A good example of this is a build server agent. The agent can be built from a dockerfile, and anything running inside should be able to use docker commands the way they are used natively.

Docker remote api is still very cool, and enables interesting remote management solutions. I'm not trying to discredit that.

[cdancy]

@ghostsquad We do that very thing with Bamboo agents inside a docker container and have been very successful thus far. We've not had any situation where we needed the docker binary mounted within the container.

I get that we'd like apps/scripts/etc to be able to invoke the binary as if it were available on the command line inside the container but I'm not sure that is realistic in the long run. Take for example the docker-in-docker context: how deep, and/or how many nested containers, should docker support? I'm sure you already know but you end up with situations where mapping volumes is no longer feasible without some ridiculous hacks. Because the industry is moving towards a more http oriented service model for programs, and seeing as how there is no shortage of them available for docker, IMO it seems the time would be better spent building those libraries instead of trying to make the docker-in-docker-in-docker-in-docker work.

I'm not trying to take a shot at you, or anyone else in this situation, I just see this conversation come up all over the place and I think we as the greater community should start pushing folks to use the remote API instead of coming up with more and more clever hacks where docker, though never said publicly, does not appear they want to support such a thing. Didn't mean to get on a rant I just see so many great tools available, some that I developer myself, and wish more folks would jump on and support us ;)

[josephearl]

I believe the generic solution to this (docker-from-docker) is to install the Docker binary in the Dockerfile for your container with curl -fsSL https://get.docker.com/ | sh (or by other means). Don't start the Docker service in the container.

Or use the API client libs in your tests/code as @cdancy suggested. Although IMO for simple use cases learning a new library could be overkill.

Then mount the socket but not the docker binary from the host when running the container.

[ghostsquad]

That makes sense

On Wed, Feb 24, 2016 at 2:54 PM Joseph Earl notifications@github.com wrote:

I believe the generic solution to this is to install the Docker binary in the Dockerfile for your container with curl -fsSL https://get.docker.com/ | sh (or by other means). No need to start the Docker service.

Then mount the socket but not the docker binary from the host when running the container.

— Reply to this email directly or view it on GitHub https://github.com/SvenDowideit/dockerfiles/issues/17#issuecomment-188496908 .

Thanks, Wes

[titpetric]

Putting this in docker arguments works for me with debian:jessie:

BIND_LIBS=`ldd /usr/bin/docker | grep /lib/ | awk '{print $3}' | egrep '(apparmor|libseccomp|libdevmap )'`
ARGS_LIBS=""
for LIB in $BIND_LIBS; do
        ARGS_LIBS="$ARGS_LIBS -v $LIB:$LIB"
done

Seems the culprit with DM_ issue @AlexTelon reported is in the libdevmap library. I suspect that it's because of some version mismatch between host and container, so -v solves it.

[alexejsailer]

On Ubuntu 14.04 this worked for me: https://gist.github.com/alexejsailer/671b18c26eb929e2c1bdf38daa23fe72

[titpetric]

FYI, the recommended way to do it today is to use the jpetazzo/dind if you need a base image. Otherwise @JosephEarl has the correct answer. Suggesting to close this issue before I feel the need to ask why people want to forward docker.sock/docker binary to the samba docker container? :)