moby: Creating fail with Could not find container for entity id after upgrading to 1.9.0


Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:43:42 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:43:42 UTC 2015
 OS/Arch:      linux/amd64

Linux gt-xps 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8 10:21:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Containers: 1
Images: 37
Server Version: 1.9.0
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.0-31-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 4
Total Memory: 7.372 GiB
Name: gt-xps
ID: 2562:2TQM:TR3I:CDFJ:T6JP:WXBN:AV4F:LZYT:HIAX:ZFYC:MMWD:Q7AN
Username: gionn
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

Before I was using 1.8.3 with aufs storage driver.

$ docker run --rm -it --name cloudesire_broker_1 ubuntu
Error response from daemon: Could not find container for entity id 72845af4d9964d42eab55fd84c1a2cc25d7b32b8c587ed47b766d9a7a8fe5396

$ docker inspect cloudesire_broker_1
Error: No such image or container: cloudesire_broker_1
[]

$ docker inspect 72845af4d9964d42eab55fd84c1a2cc25d7b32b8c587ed47b766d9a7a8fe5396
Error: No such image or container: 72845af4d9964d42eab55fd84c1a2cc25d7b32b8c587ed47b766d9a7a8fe5396
[]

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

First debug happened in compose issue tracker since it appeared related to it: https://github.com/docker/compose/issues/2316

I’ve a feeling that has something to do with containers that was existing before the upgrade to 1.9.0 from 1.8.3, with the contextual switch from storage driver aufs to overlay.

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 42 (11 by maintainers)

Commits related to this issue

tackled issue https://github.com/docker/docker/issues/17691#issuecomment-165269707 — committed to niccokunzmann/dockerfiles by niccokunzmann 9 years ago
Attempt to solve error "Could not find container for entity id" See GitHub issue: https://github.com/docker/docker/issues/17691 for details. Solution is in: https://github.com/docker/docker/pull/160... — committed to southerngs/docker by cpuguy83 9 years ago

Most upvoted comments

For people using docker in more of a production-like environment and don’t want to rm the world, I just did this and it worked:

sudo sqlite3 /var/lib/docker/linkgraph.db delete from edge where entity_id = '<conflicting-entity-id-sha-1>'; delete from entity where id = '<conflicting-entity-id-sha-1>';

Where <conflicting-entity-id-sha-1> is the entity id causing you trouble like: 33f6f30a91eb31a86e9c715a1fba4cc28c8031ab62826d93c799e3849c341d26

+29

raimille1 on Feb 2, 2016

For anyone who is still encountering this issue, this is a workaround:

Remove rm -f /var/lib/linkpgraph.db (or if you modified graphdb=/opt/docker : rm -rf /opt/docker/linkgraph.db)
Remove rm -rf /var/lib/containers/
Restart docker daemon : (for Ubuntu) sudo service docker restart

ikor on Dec 2, 2015

The only way I could fix this issue was by deleting the contents of /var/lib/docker/containers and also deleting the /var/lib/docker/linkgraph.db file. Thanks @cpuguy83.

abhas on Nov 9, 2015

We hit the same issue with 1.9.0. But deleting all containers was not an option for us. So did a very hacky workaround by going in to modifying the record on the edge table using sqllite cli.

 sqlite3 linkgraph.db 

update edge set name='some-random-container-name' where name='failing-container-name';

Hope this helps.

iwidanalage on Dec 11, 2015

@gionn Hmm, yes I think this is probably it. Maybe remove all containers, and then remove /var/lib/docker/linkgraph.db. Not sure if this is feasible for your setup. There’s a PR to namepsace these link graphs per graph driver.

cpuguy83 on Nov 4, 2015

For me a simple restart of docker service helped.

UPDATE: …or sometimes I also had to do rm -Rf /var/lib/docker/* before (thanks, @Yajo !)

gdubicki on Jun 8, 2016

I actually use Docker in production for multiple projects, and it works well in a very basic configuration. My suggestion would be in maintaining a LTS version, focusing in more stability than new features. As Docker is a project with several years of development, we should have a production-ready and stable version, which I didn’t found since the beginning.

Docker, Inc. offers a commercially supported version of docker (“Docker CS”), https://www.docker.com/products/overview, that you may be interested in.

thaJeztah on Feb 13, 2016

Welcome @thaJeztah… but @estevaoam’s perspective is definitely not invalid either; many people have to decide whether or not some technology is mature enough for wide-scale adoption into organizations; Docker’s pace (evolution, I suppose? … 1 giant step forward, 3 new major bugs backward) is indeed enough of a frightening prospect to pitch as a viable solution if his/her task is to evaluate the readiness of using it as a reliable day-to-day tool (or not, perhaps in his case).

mikeatlas on Feb 11, 2016