Docker Error removing intermediate container

I get this error during a docker build using docker versions 1.9.1 and 1.10 as given in docker-1-9-1-is-available and docker-1-10-support.

Error removing intermediate container d1eae450392f: rmdriverfs: Driver btrfs failed to remove root filesystem <volume id>: Failed to destroy btrfs snapshot /var/lib/docker/btrfs/subvolumes for <volume id>: operation not permitted

1 Like

Unfortunately, in our tests, docker-compose run does not return the correct exit code from the run command/script without the --rm flag (screenshot attached (tried with 1.6-1.7).

Has there been any progress on this. I’m seeing this same error while evaluating CircleCI and I’m unable to build a simple Java HelloWorld Spring Boot app and build a container.

Due to the way that Docker works inside of an unprivileged LXC container there is nothing that we can except the listed workaround.

Seemingly this is not high up on the priority list. Travis CI, however has worked flawlessly with Docker, allowing it to remove containers as and when required.

Also, seeing this when building an image. Am not using --rm.

1 Like

Thanks, I see the same thing when building an image as well. It is safe to ignore for most cases. If your image is failing to build it is very likely causes by some other issue.

Just wanted to chime in. I’m seeing the same issue when building an image but it seems to build correctly.

Also seeing this when trying to build images. It’s causing errors in the built images.

Getting docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime error: not a directory". from the docker daemon when trying to run the images.

Removing intermediate container would be to my understanding mandatory in builds where you want to smoke test your Docker images before pushing them into registry.

When I’m trying to run a container from the image I’ve built during build process I get error because the intermediate container is reserving the port that the smoke test container is also trying use.

I’m still running into this error when clearly the problem is not with the build script or the building, but with CircleCI. Exact same error, cannot remove intermediate containers.

Please see this previous response. This is a known issue and will likely never be fixed on our SaaS solution since it requires us to run unprivileged LXC containers.

Still running into issue … by simple "docker build -t "

Docker recently changed the default docker build behavior to --rm=true by default, so you just need to switch your docker build command to docker build --rm=false

3 Likes

Hi everyone, I think an issue I have with Docker builds may also be related:

However - I am not docker runing anything, so the workaround doesn’t work for me, my issues are on the docker build itself.

I just need some clarity on this issue. I too see these errors in the logs:

Error removing intermediate container d9506c265c8d: rmdriverfs: Driver btrfs failed to remove root filesystem d9506c265c8d342f23e3150a1a0c4e363186f504a1d9d22dcf83486037692540: Failed to destroy btrfs snapshot /var/lib/docker/btrfs/subvolumes for d9506c265c8d342f23e3150a1a0c4e363186f504a1d9d22dcf83486037692540: operation not permitted

Error removing intermediate container d9506c265c8d: nosuchcontainer: no such id: d9506c265c8d342f23e3150a1a0c4e363186f504a1d9d22dcf83486037692540

I’m executing the docker build by way of a Maven Plugin. It completes the Docker Image build successfully despite the errors.

What I need to know is does this error in any way affect the Docker Image Build? Will the contents of the image be any different if I built it on my local machine? I need to have confidence that what I build locally is exactly the same as what CircleCI will build.

Thanks!

Please see https://circleci.com/docs/docker-btrfs-error/ for the details on why you see this error. It does not affect your Docker build in any way.

2 Likes

I think the confusion here is that somehow on CircleCI --rm is getting set anyways (even if the user hasn’t set it). This makes things unintuitive hence this long discussion about why this error is happening and what it means. Admittedly yes users could override this behavior by disabling --rm explicitly, I guess the question is why should one need to do this at all? Shouldn’t the default configuration of docker on CircleCI be one such that --rm is not supplied by default? It might save further discussion on this point. Just something to think about.

This is not a possibility since your builds run in a shared environment in an unprivileged LXC container.

The best solution going forward for people who need full docker functionality is to run inside of a VM on 2.0

The tradeoff here is that the VM takes a bit longer to spin up.