Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kstenerud opened this issue Sep 15, 2014 · 29 comments

Comments

@kstenerud
Copy link

commented Sep 15, 2014

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

This comment has been minimized.

Copy link

commented Oct 14, 2014

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

@cdancy

This comment has been minimized.

Copy link

commented Oct 14, 2014

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

This comment has been minimized.

Copy link

commented Jul 16, 2015

@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

This comment has been minimized.

Copy link

commented Jul 16, 2015

@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

This comment has been minimized.

Copy link

commented Jul 16, 2015

@cdancy OK. Thank you all the same!

@tomfotherby

This comment has been minimized.

Copy link

commented Jul 27, 2015

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

This comment has been minimized.

Copy link

commented Jul 27, 2015

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

This comment has been minimized.

Copy link

commented Aug 7, 2015

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 comment has been minimized.

Copy link

commented Aug 10, 2015

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

This comment has been minimized.

Copy link

commented Aug 27, 2015

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

@jverdeyen

This comment has been minimized.

Copy link

commented Sep 10, 2015

👍 Worked for me

@chrisskilton

This comment has been minimized.

Copy link

commented Sep 11, 2015

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

This comment has been minimized.

Copy link

commented Sep 11, 2015

try install lxc

@michaeljs1990

This comment has been minimized.

Copy link

commented Oct 26, 2015

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

@arpheno

This comment has been minimized.

Copy link

commented Nov 2, 2015

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

@michaeljs1990

This comment has been minimized.

Copy link

commented Nov 2, 2015

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

@MichaelMackus

This comment has been minimized.

Copy link

commented Nov 5, 2015

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

This comment has been minimized.

Copy link

commented Nov 5, 2015

@MichaelMackus just install lxc on the actual docker container.

@MichaelMackus

This comment has been minimized.

Copy link

commented Nov 5, 2015

Doh! Thanks @michaeljs1990 that worked :)

@ghostsquad

This comment has been minimized.

Copy link

commented Dec 2, 2015

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

@AlexTelon

This comment has been minimized.

Copy link

commented Feb 6, 2016

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: version DM_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

This comment has been minimized.

Copy link

commented Feb 6, 2016

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

This comment has been minimized.

Copy link

commented Feb 7, 2016

@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

This comment has been minimized.

Copy link

commented Feb 7, 2016

@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

This comment has been minimized.

Copy link

commented Feb 24, 2016

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

This comment has been minimized.

Copy link

commented Feb 25, 2016

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
#17 (comment)
.

Thanks,
Wes

@titpetric

This comment has been minimized.

Copy link

commented Mar 31, 2016

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

This comment has been minimized.

Copy link

commented Jun 3, 2016

@titpetric

This comment has been minimized.

Copy link

commented Jun 3, 2016

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? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.