@vieira请重新启动机器，如果仍有问题，请告知我们。

即使重新启动机器，上述步骤仍可重现。

@alexlarsson能请你看看吗？ 似乎与devicemapper有关

问题似乎与devicemapper有关。 我认为这确实是另一回事。
我试过了，问题是“停止泊坞窗”部分。 如果我只是ctrl-c docker守护程序，它将尝试正确停止容器，但似乎永远无法成功停止容器。 因此，我再次按ctrl-c强制docker死亡。

此时容器（尾部）仍在运行，因此将安装设备映射器设备，这意味着我们无法再次安装或删除它。 这就是这些操作失败的原因。

@alexlarsson您知道发生错误时清理系统的简便方法吗？

好吧，如果您发现失控的容器过程，则可以强制将其杀死。

您可以卸载@vieira ：
卸载/ var / lib / docker / devicemapper / mnt / c39206003c7ae8992a554a9ac2ea130327fc4af1b2c389656c34baf9a56c84b5

并再次启动容器，它应该可以工作

我可以看到我的docker是从-d和-r启动的。 首先，重新启动docker时，容器不会重新启动。 然后，发生上述错误（尝试启动容器时）。

我的centos 6.5仍然从epel中获得1.0.0.6。 是否曾经在1.0中将其识别为错误并在1.1中得到修复？ 可以请人确认吗？

谢谢

大家好，仍未在1.1.1中修复。
原始帖子中的步骤仍然适用。

Error response from daemon: Cannot start container 5e9bde9b409b: 
Error getting container 5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d 
from driver devicemapper: 
Error mounting '/dev/mapper/docker-253:0-267081-5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d' 
on 
'/var/lib/docker/devicemapper/mnt/5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d': 
device or resource busy

我也得到了很多，但是从某种意义上说，它确实确实删除了该容器（因为我可以启动一个具有相同名称的新容器）

有没有解决此问题的方法？

也在寻找解决方法。

好像在docker守护程序修复该问题之前停止所有容器。

我已将这个pre-stop块添加到我的新贵工作中，作为一种解决方法：

pre-stop script
    /usr/bin/docker ps -q | xargs /usr/bin/docker stop
end script

这是我的调试步骤的要点： https :

@rochacon感谢您的解决方法。 我将在今天或明天使用1.2进行测试（似乎您已经使用1.1.1进行了测试，对吧？）。 希望它能工作。

@vieira我也尝试了1.2.0，结果相同。

运行4周后，我的一个容器停了下来。。。不知道为什么。如何找到根本原因？

无论如何，我遇到了同样的问题...通过@aroragagan的建议解决了：umount，

root<strong i="8">@pppdc9prd3ga</strong> mdesales]# docker start federated-registry
Error response from daemon: Cannot start container federated-registry: Error getting container 4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946 from driver devicemapper: Error mounting '/dev/mapper/docker-253:0-394842-4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946' on '/var/lib/docker/devicemapper/mnt/4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946': device or resource busy
2014/10/17 21:04:33 Error: failed to start one or more containers

[root<strong i="9">@pppdc9prd3ga</strong> mdesales]# docker version
Client version: 1.1.2
Client API version: 1.13
Go version (client): go1.2.2
Git commit (client): d84a070/1.1.2
Server version: 1.1.2
Server API version: 1.13
Go version (server): go1.2.2
Git commit (server): d84a070/1.1.2

[root<strong i="10">@pppdc9prd3ga</strong> mdesales]# umount /var/lib/docker/devicemapper/mnt/4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946

[root<strong i="11">@pppdc9prd3ga</strong> mdesales]# docker start federated-registry
federated-registry

现在，在从12.04升级到14.04的EC2 Ubuntu系统上，我们在1.3.0上看到了这一点。 我的开发实例是直接安装到Vagrant的14.04，没有这个问题。 卸载然后重新启动容器似乎可以工作，但这无法实现将它们配置为在实例重新启动或docker重新启动时自动重新启动的目的。 让我知道我是否可以提供有关支持软件包等版本的更多信息，因为我有一个可用的系统和不可用的系统。

在具有Linux内核3.13或3.14的docker 1.3 Ubuntu 14.04上看到相同的问题。

@srobertson是指“守护程序重新启动时容器未重新启动”吗？ 您是否正在使用新的_per-container_ restart-policy？ 因为在Docker 1.2中已经删除了整个守护程序-r / --restart=true

CLI参考中介绍了新的（每个容器）重新启动策略

+1，在带有3.17.2-1-ARCH内核的docker 1.3 @ ArchLinux x86_64上出现此问题。

$ docker --version
Docker version 1.3.1, build 4e9bbfa

Umount解决了这个问题。

umount是一种解决方法，我不会说它可以解决问题。 只需在运行容器的情况下重新启动守护程序即可重现该问题。

umount适用于以下Docker版本：

atc@li574-92> docker --version
Docker version 1.3.1, build 4e9bbfa

我先停止了docker守护程序，然后：

umount /dev/mapper/docker-202\:0-729439-a7c53ae579d02aa7bb3aeb2af5f2f79c295e1f5962ec53f16b73896bb3970635 

@ mlehner616是的，您是对的。 抱歉，这当然是解决方法，而不是解决方案。 那只是措辞不好。

我也希望看到此修复，ofc。 =）

fyi，unmounten对我没有用。 我收到一个错误，在/ etc / mtab中找不到挂载
Docker版本1.0.0，在RHEL 6.5上构建63fe64c / 1.0.0

我已经通过在docker守护程序返回时自动卸载任何旧的挂载来解决此问题。 我不想修补ubuntu的大/etc/init/docker.conf ，所以我在/etc/default/docker放了一小行：

cat /proc/mounts | grep "mapper/docker" | awk '{print $2}' | xargs -r umount

这似乎可以解决问题。 我将其与让新贵管理我的实际Docker容器的启动和重新生成结合起来，因此现在在service docker restart ，所有容器都将返回。

谢谢@jypma ，这对我也有帮助！

_review session_ with @unclejack

我们将使用此问题作为大多数“设备或资源繁忙”或EBUSY报告的跟踪器。

与其他问题一样，此问题可以通过适当处理docker守护程序的安装命名空间来缓解。 当前没有默认的mount名称空间处理，因此我们遇到类似EBUSY的问题。

当我们致力于处理官方解决方案时，您可以应用一些解决方法。 参见http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

确认我也使用股票freeipa图像遇到了这个问题。 我停止了docker服务，当我尝试使用w / ipa容器重新启动它时，得到以下信息。

$ docker start ipa
Error response from daemon: Cannot start container ipa: Error getting container 98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2 from driver devicemapper: Error mounting '/dev/mapper/docker-253:0-786581-98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2' on '/var/lib/docker/devicemapper/mnt/98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2': device or resource busy
2015/01/11 21:44:38 Error: failed to start one or more containers

卸载“ mount”解决了该问题，因此我可以重新启动容器。

$ umount /var/lib/docker/devicemapper/mnt/98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2

$ docker start ipa
ipa

使用以下内容：

$  docker version
Client version: 1.3.2
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): 39fa2fa/1.3.2
OS/Arch (client): linux/amd64
Server version: 1.3.2
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): 39fa2fa/1.3.2

$ lsb_release -i -d
Distributor ID: CentOS
Description:    CentOS release 6.6 (Final)

umount解决了我的问题

码头工人-版本
Docker版本1.3.2，内部版本39fa2fa

因此，以下变通方法对于我的用例来说是一个更永久的变通方法。
我严格使用Amazon linux（RedHat6-Like），所以我对init脚本进行了一些修改（如果docker被更新，它可能会被覆盖。）基本上，所有要做的就是正常停止docker，检查是否有剩余的docker mount ，如果有，它将卸载它们。 青年汽车

_ / etc / init.d / docker_
添加lib变量（第28行）

prog="docker"
exec="/usr/bin/$prog"
# Adding lib variable here
lib="/var/lib/$prog"
pidfile="/var/run/$prog.pid"
lockfile="/var/lock/subsys/$prog"
logfile="/var/log/$prog"

添加umount块以停止功能（〜77行）

stop() {
    echo -n $"Stopping $prog: "
    killproc -p $pidfile -d 300 $prog
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile

    # BEGIN UMOUNT BLOCK
    if [ $(df | grep $lib | awk '{print $1}' | wc -l) -gt 0 ]; then
        umount $(df | grep $lib | awk '{print $1}')
    fi
    # END UMOUNT BLOCK
    return $retval
}

我在使用设备映射器作为存储驱动程序的docker 1.4.1中遇到了相同的问题。 我能够通过其日志文件从Docker收集紧急堆栈跟踪。

环境

$ cat / etc / *版本
DISTRIB_ID = Ubuntu
DISTRIB_RELEASE = 14.04
DISTRIB_CODENAME =可信任
DISTRIB_DESCRIPTION =“ Ubuntu 14.04.1 LTS”
NAME =“ Ubuntu”
VERSION =“ 14.04.1 LTS，Trusty Tahr”
ID = ubuntu
ID_LIKE = debian
PRETTY_NAME =“ Ubuntu 14.04.1 LTS”
VERSION_ID =“ 14.04”
HOME_URL =“ http://www.ubuntu.com/ ”
SUPPORT_URL =“ http://help.ubuntu.com/ ”
BUG_REPORT_URL =“ http://bugs.launchpad.net/ubuntu/ ”

$泊坞窗版本
sudo：无法解析主机ip-172-30-0-39
客户端版本：1.4.1
客户端API版本：1.16
Go版本（客户端）：go1.3.3
Git提交（客户端）：5bc2ff8
操作系统/ Arch（客户端）：linux / amd64
服务器版本：1.4.1
服务器API版本：1.16
Go版本（服务器）：go1.3.3
Git提交（服务器）：5bc2ff8

$ tail -f / var / log / upstart / docker
...
INFO [143413] -job execResize（3dfcbc075227d5b3f0115bd73a1fea4a56a2c0fc68190d84b6d88e93938b4121，37，130）
2015/01/22 22:29:22 http：紧急服务@：运行时错误：无效的内存地址或nil指针取消引用
goroutine 1932 [正在运行]：
网络/http.func·011（）
/usr/local/go/src/pkg/net/http/server.go:1100 + 0xb7
runtime.panic（0xbe5c40，0x127da13）
/usr/local/go/src/pkg/runtime/panic.c:248 + 0x18d
github.com/docker/docker/daemon.(_execConfig).Resize(0xc20989c800、0x25、0x82、0x0、0x0）
/go/src/github.com/docker/docker/daemon/exec.go:65 + 0x66
github.com/docker/docker/daemon.(_Daemon).ContainerExecResize(0xc208044f20，0xc20a836e00，0x1）
/go/src/github.com/docker/docker/daemon/resize.go:49 + 0x314
github.com/docker/docker/daemon._Daemon.ContainerExecResize·fm(0xc20a836e00，0x7f49bcd007d8）
/go/src/github.com/docker/docker/daemon/daemon.go:132 + 0x30
github.com/docker/docker/engine.(_Job).Run(0xc20a836e00，0x0，0x0）
/go/src/github.com/docker/docker/engine/job.go:83 + 0x837
github.com/docker/docker/api/server.postContainerExecResize(0xc208114fd0、0xc20a55db27、0x4、0x7f49bcd08c58、0xc209498320、0xc209e
621a0、0xc20a69c0c0、0x0、0x0）
/go/src/github.com/docker/docker/api/server/server.go:1170 + 0x2d1
github.com/docker/docker/api/server.func·002(0x7f49bcd08c58、0xc209498320、0xc209e621a0）
/go/src/github.com/docker/docker/api/server/server.go:1219 + 0x810
净/http.HandlerFunc.ServeHTTP(0xc2081b8280、0x7f49bcd08c58、0xc209498320、0xc209e621a0）
/usr/local/go/src/pkg/net/http/server.go:1235 + 0x40
github.com/gorilla/mux.(_Router).ServeHTTP(0xc2080a3cc0，0x7f49bcd08c58，0xc209498320，0xc209e621a0）
/go/src/github.com/docker/docker/vendor/src/github.com/gorilla/mux/mux.go:98 + 0x297
净/http.serverHandler.ServeHTTP(0xc208180480、0x7f49bcd08c58、0xc209498320、0xc209e621a0）
/usr/local/go/src/pkg/net/http/server.go:1673 + 0x19f
净/http.(_conn).serve(0xc20a836300）
/usr/local/go/src/pkg/net/http/server.go:1174 + 0xa7e
由net / http。（* Server）.Serve创建
/usr/local/go/src/pkg/net/http/server.go:1721 + 0x313

...

INFO [0056]删除/v1.16/containers/hoopla_docker_registry
INFO [0056] +职位rm（hoopla_docker_registry）
无法销毁容器hoopla_docker_registry：驱动程序devicemapper无法删除根文件系统6abcbfefe8bdd485dfb192f8926
3add895cda1ae28b578d4a0d9b23574dedc5c：设备忙
INFO [0066]-作业rm（hoopla_docker_registry）=错误（1）
ERRO [0066]删除处理程序/ containers / {名称：。 *}返回错误：无法销毁容器hoopla_docker_registry：驱动器
r devicemapper无法删除根文件系统6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c：设备正忙

ERRO [0066] HTTP错误：statusCode = 500无法销毁容器hoopla_docker_registry：驱动程序devicemapper无法删除根文件系统6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c：设备正忙

我在1.4.1的ubuntu 14.04（在ec2上）和1.5上都没有看到这一点。 这很奇怪，因为docker在Linux mint 17上看起来非常可靠，但在我们的带有ubuntu 14.04的构建服务器上却非常不可靠。

有没有一种方法可以不使用devicemapper，因为自0.9天以来似乎一直存在此问题？

这也可能与overlayfs一起发生。

好吧，我只是更改为aufs，到目前为止没有问题。

此问题的状态如何？ 我看到一些PR可能会合并在一起，但没有明确说明的解决方案。 这是生产中的一个主要问题，现在唯一的解决方法是修补init脚本以干净地卸载驱动器。

在再次审查之后，这并不是我们最初所说的EBUSY的理想示例。
这种情况与容器的pid不能更好地处理信号有关。

由于此处的复制情况tail -f /dev/null不在守护程序退出时在SIGQUIT退出，因此devmapper驱动程序无法正确拆卸（这不是devmapper独有的）。 在再次启动守护程序之前，您可以看到tail -f /dev/null仍在运行，即使docker没有运行。

这样的问题需要思考如何在docker退出时如何彻底处理容器中的pids ... @unclejack @crosbymichael的想法？

在Fedora 21 x86_64上进行了测试。 仅出于似乎不存在该问题的目的而提供信息以进行比较（不再？）。 使用centos：7或ubuntu：trusty图像的结果相同。

$ docker run -d centos:7 tail -f /dev/null
ec496f1a6738430972b79e5f3c9fdbf2527e55817d4638678e3b0dd486191203

$ systemctl stop docker

$ ps ax | grep tail
14681 ?        Ss     0:00 tail -f /dev/null
14738 pts/9    S+     0:00 grep --color=auto tail

$ systemctl start docker

$ docker ps -q

$ docker ps -a -q
ec496f1a6738

$ docker start ec496f1a6738
ec496f1a6738

$ docker rm ec496f1a6738
Error response from daemon: Conflict, You cannot remove a running container. Stop the container before attempting removal or use -f
FATA[0000] Error: failed to remove one or more containers 

$ docker stop ec496f1a6738
ec496f1a6738

$ docker rm ec496f1a6738
ec496f1a6738

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

系统信息：

$ uname -a
Linux localhost 3.18.9-200.fc21.x86_64 #1 SMP Mon Mar 9 15:10:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -q device-mapper docker-io
device-mapper-1.02.93-3.fc21.x86_64
docker-io-1.5.0-1.fc21.x86_64

$ docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef/1.5.0
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef/1.5.0

只需在Docker 1.5，Ubuntu 14.04上运行
root@ip-10-148-25-50:~# docker start service Error response from daemon: Cannot start container service: Error getting container f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 from driver devicemapper: Error mounting '/dev/mapper/docker-202:1-153948-f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774' on '/var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774': device or resource busy FATA[0000] Error: failed to start one or more containers

不过，运行umount /var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774有所帮助。

我在Docker 1.5.0，Centos7.0，

[vagrant<strong i="6">@localhost</strong> ~]$  sudo systemctl start docker
[vagrant<strong i="7">@localhost</strong> ~]$  sudo docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                        PORTS               NAMES
5189b16c0917        mongo:3             "/entrypoint.sh mong   35 minutes ago      Exited (128) 29 minutes ago                       mongod
[vagrant<strong i="8">@localhost</strong> ~]$ sudo docker inspect 5189b16c0917 | grep Error
        "Error": "Error getting container 5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6 from driver devicemapper: Error mounting '/dev/mapper/docker-253:1-134,

umount失败。

[vagrant<strong i="12">@localhost</strong> ~]$ sudo stat /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6
  File: `/var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6'
  Size: 6               Blocks: 0          IO Block: 4096   ディレクトリ
Device: fd01h/64769d    Inode: 201732136   Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-03-21 20:36:14.407505308 +0900
Modify: 2015-03-21 20:16:58.863146490 +0900
Change: 2015-03-21 20:16:58.863146490 +0900
 Birth: -
[vagrant<strong i="13">@localhost</strong> ~]$ sudo umount /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6
umount: /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6: not mounted
[vagrant<strong i="14">@localhost</strong> ~]$ grep docker /proc/mounts
(no results)

环境

[vagrant<strong i="18">@localhost</strong> ~]$ cat /etc/centos-release
CentOS Linux release 7.0.1406 (Core)
[vagrant<strong i="19">@localhost</strong> ~]$ uname -a
Linux localhost.localdomain 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[vagrant<strong i="20">@localhost</strong> ~]$ sudo docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef/1.5.0
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef/1.5.0

[vagrant<strong i="21">@localhost</strong> ~]$ rpm -qi docker
Name        : docker
Version     : 1.5.0
Release     : 1.el7
Architecture: x86_64
Install Date: 2015年03月21日 20時04分29秒
Group       : Unspecified
Size        : 27215826
License     : ASL 2.0
Signature   : (none)
Source RPM  : docker-1.5.0-1.el7.src.rpm
Build Date  : 2015年02月12日 05時10分39秒
Build Host  : c1bj.rdu2.centos.org
Relocations : (not relocatable)
Packager    : CBS <[email protected]>
Vendor      : CentOS
URL         : http://www.docker.com
Summary     : Automates deployment of containerized applications
Description :
Docker is an open-source engine that automates the deployment of any
application as a lightweight, portable, self-sufficient container that will
run virtually anywhere.

我是从CentOS7官方存储库通过docker 1.3.2复制它的。

$ rpm -qi docker
Name        : docker
Version     : 1.3.2
Release     : 4.el7.centos
Architecture: x86_64
Install Date: 2015年03月22日 02時44分58秒
Group       : Unspecified
Size        : 25505685
License     : ASL 2.0
Signature   : RSA/SHA256, 2014年12月11日 04時21分03秒, Key ID 24c6a8a7f4a80eb5
Source RPM  : docker-1.3.2-4.el7.centos.src.rpm
Build Date  : 2014年12月11日 04時15分49秒
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://www.docker.com
Summary     : Automates deployment of containerized applications

码头工人1.5.0有相同的错误
Error response from daemon: Cannot destroy container 485bf8d6502a: Driver devicemapper failed to remove root filesystem 485bf8d6502a6cf448075d20c529eb24f09a41946a5dd1c61a99e17

同样的问题在这里，容易重现

docker run -it --name busybox --rm busybox tail -f /dev/null

On another shell:

root<strong i="6">@staging5</strong>:/home/shopmedia #service docker stop
Stopping docker:                                           [  OK  ]
root<strong i="7">@staging5</strong>:/home/shopmedia #service docker start
Starting docker:                                           [  OK  ]
root<strong i="8">@staging5</strong>:/home/shopmedia #docker rm -f busybox
Error response from daemon: Cannot destroy container busybox: Driver devicemapper failed to remove root filesystem 124cd3329e0fafa6be2a284b36a75571666745436c601a702a4beedb75adc7c0: Device is Busy
FATA[0011] Error: failed to remove one or more containers

环境

docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8/1.4.1
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8/1.4.1

cat /etc/centos-release
CentOS release 6.6 (Final)

cat /proc/version
Linux version 2.6.32-504.8.1.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Jan 28 21:11:36 UTC 2015

rpm -q device-mapper
device-mapper-1.02.90-2.el6_6.1.x86_64

编辑：对我来说，唯一的解决方法（我未使用system.d）是使用unshare命令更新/etc/init.d/docker，第50行。 该修复程序已由@vbatts提供，谢谢btw
但是，此修复程序不可扩展。 我们不想更新我们拥有的每台机器+下次更新docker时，它将被删除。

1. 我的其他选择是什么？
2. 是否有修复的码头方出来？
3. 它会影响所有操作系统吗？
4. 它会影响所有内核吗？

谢谢

我认为https://github.com/docker/docker/pull/12400将解决此问题。 这是因为docker守护程序关闭将使正在运行的容器不被清理（如果容器在10秒内未被杀死，则容器的rootfs仍将被挂载），并且在下次启动守护程序时将无法将其删除。 （我在叠加层上进行测试）

谢谢@ coolljt0725 。

1）将实现什么版本的docker？
2）我还有其他选择吗？
3）是否影响所有操作系统？
4）是否影响所有内核？

谢谢

+1为umount解决方法。 发生在docker 1.6.0，build 4749651上。
服务docker restart无法解决。 卸载麻烦的“卷”修复它。

Docker 1.6.1（Ubuntu 14.04）仍然存在此问题。 umount有效。

Docker 1.6.2（Ubuntu 14.04） umount不起作用

Docker 1.7.0 Centos 6.5仍然存在相同的问题。

升级到Docker 1.7之后，我才在Centos 6.3上获得了它。 升级重新启动了docker（显然），当我重新启动容器时，我所有的node.js容器都重新启动了，但是运行uwsgi的容器给出了错误：

# docker start 48596c91d263
Error response from daemon: Cannot start container 48596c91d263: Error getting container 48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 from driver devicemapper: Error mounting '/dev/mapper/docker-8:17-262147-48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549' on '/local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549': device or resource busy

进行umount /local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549不能解决问题。

在Debian上也一样。 即使启动一个全新的Hello World图片，也无法启动任何容器。

root<strong i="6">@vamp1</strong>:~# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from hello-world
a8219747be10: Pull complete 
91c95931e552: Already exists 
hello-world:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provi
de security.
Digest: sha256:aa03e5d0d5553b4c3473e89c8619cf79df368babd18681cf5daeb82aab55838d
Status: Downloaded newer image for hello-world:latest
Error response from daemon: Cannot start container 69be8cff86828d1f4ca3db9eeeeb1a8891ce1e305bd07847108750a0051846ff: device or resource busy

Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64

PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"

@tnolet请提供docker info输出。

@unclejack我的主机的docker info

$ docker info
Containers: 24
Images: 128
Storage Driver: devicemapper
 Pool Name: docker-8:17-262147-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: 
 Metadata file: 
 Data Space Used: 2.897 GB
 Data Space Total: 107.4 GB
 Data Space Available: 104.5 GB
 Metadata Space Used: 7.918 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.14 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.81-1.el6.elrepo.x86_64
Operating System: <unknown>
CPUs: 4
Total Memory: 7.812 GiB
Name: radioedit-app101
ID: RY22:ODAC:5NT5:MSBZ:Y52X:L33V:UCHA:IOIL:SR23:YX3U:IILJ:J44R
WARNING: No swap limit support

红帽不再支持@tdterry RHEL 6和CentOS 6，不再与Docker一起使用。 请升级到RHEL 7或CentOS 7。

Docker正式支持Centos 6.5（https://docs.docker.com/installation/centos/）。 此外，我们已将内核更新为3.10。 其他人在这里报告该错误也存在于CentOS 7上。 似乎更像是devicemapper问题而不是CentOS版本问题。 我没有理由相信升级到CentOS 7会有什么不同。

我刚刚在CentOS 7，Docker版本1.6.0，使用devicemapper构建4749651中拥有了它。 我的15个集装箱全部坠毁。 我正在尝试删除一些悬空的图像，并得到相同的错误：

Error response from daemon: Cannot destroy container: Driver devicemapper failed to remove root filesystem : Device is Busy

Containers: 25
Images: 237
Storage Driver: devicemapper
 Pool Name: docker-253:2-8594920394-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 22.03 GB
 Data Space Total: 107.4 GB
 Data Space Available: 85.34 GB
 Metadata Space Used: 25.47 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.122 GB
 Udev Sync Supported: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.4.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 24
Total Memory: 141.5 GiB
Name: localhost.localdomain

@amalagaura守护程序已停止，运行mount | grep docker可能会显示几个已挂载的目录（如/dev/mapper/docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 on ... ）。 您可以先umount ，然后再次启动守护程序。 如果问题仍然存在，请dmsetup ls | grep docker并查看诸如docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 (253:5)类的条目。 您可以呼叫dmsetup remove docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0

@vbatts谢谢您的帮助。 我们真正的问题是我们的15台机器的生产集群刚刚消失。 这是一个不同的讨论，但是如果我们想在Docker上获得支持该怎么办？

升级到1.7后，我遇到了类似的问题，在elementaryOS上的1.​​6.2中它可以正常工作。

每当我启动任何容器时，我都会收到消息

来自守护程序的错误响应：无法启动容器560640442c770dff574f5af7b6cdcc8e86ba8a613db87bf90a77aea7f0db322a：设备或资源繁忙

我清除了docker，rm -rf / var / lib / docker，并且使用全新安装运行hello-world映像时仍然出现相同的错误。

我还注意到每次尝试失败后，文件夹都在/ var / docker / lib / aufs / mnt中堆积。

我经常遇到这个问题，而且我使用的是aufs，而不是devicemapper：

$ sudo docker info
Containers: 3
Images: 2278
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 2284
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.5.0-54-generic
Operating System: Ubuntu precise (12.04.2 LTS)
CPUs: 8
Total Memory: 7.725 GiB
Name: (omitted)
ID: DWS4:G2M5:XD2Q:CQKA:5OXF:I3RB:6M6F:GUVO:NUFM:KKTF:4RB2:X3HP

让我知道我是否还可以提供其他调试信息。

看到同样的问题。 umount不起作用，它表示未装入文件夹。 我在docker 1.5.0上观察到了这一点，然后以相同的效果更新到1.7.1。

$ docker info
Containers: 15
Images: 91
Storage Driver: devicemapper
 Pool Name: docker-202:1-149995-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: 
 Metadata file: 
 Data Space Used: 2.225 GB
 Data Space Total: 107.4 GB
 Data Space Available: 105.1 GB
 Metadata Space Used: 5.03 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.142 GB
 Udev Sync Supported: false
 Deferred Removal Enabled: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-40-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 1
Total Memory: 3.676 GiB
WARNING: No swap limit support

在Ubuntu 14.04上也一样

$ docker info
Containers: 6
Images: 537
Storage Driver: devicemapper
 Pool Name: docker-8:1-262623-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file:
 Metadata file:
 Data Space Used: 7.546 GB
 Data Space Total: 107.4 GB
 Data Space Available: 99.83 GB
 Metadata Space Used: 19.05 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.128 GB
 Udev Sync Supported: false
 Deferred Removal Enabled: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-52-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 2
Total Memory: 2.939 GiB
Name: test-app
ID: F5T4:5AIR:TDBZ:DGH4:WBFT:ZX6A:FVSA:DI4O:5HE2:CJIV:VVLZ:TGDS
WARNING: No swap limit support

$ docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64

我将要运行一个应用程序，并且该问题是否已解决，我无法在生产中使用docker，因为我已经遇到了一些容器崩溃的情况，并且如果不重新启动系统就无法删除它们，这在生产系统上很痛苦。

禁用了udev同步的@trompx devicemapper无法正常工作。
这是我们现在提供动态二进制文件（可解决同步问题）而不是静态二进制文件的部分原因。
我建议用apt.dockerproject.org存储库（和docker-engine软件包）替换get.docker.com（和lxc-docker软件包）中的仓库。
有关更多详细信息，请参见http://blog.docker.com/2015/07/new-apt-and-yum-repos/ 。

还有一个新的（ish）容器状态称为“失效”，当删除容器时出现问题时会设置该状态。 当然，这是解决此特定问题的方法，它使您可以调查为什么存在device or resource busy错误（可能是竞态条件），在这种情况下，您可以尝试再次删除，或尝试手动删除修复（例如，卸下所有剩余的安装架，然后将其卸下）。

在我们与fs进行某种竞争的情况下（例如，让它尝试再次卸载），也许graphdriver可以更具弹性。

@ cpuguy83谢谢您的信息。 我现在使用的是udev true的最新版本，但是当我尝试设置日志记录监视系统时，出现了一个问题，导致我的所有容器的状态均为“退出（137）”，然后变为“已死”，并试图将其删除删除它们“来自守护程序的错误响应：无法销毁容器9ca0b5642a55：驱动程序devicemapper无法删除根文件系统”。 所以我仍然有这个问题。

使用syslog驱动程序（尝试设置日志系统）时，我看不到发生了什么，所以我真的不知道发生了什么。 如果我解决这个问题，我会通知您。

@trompx如果这些内容在以前的安装中仍然存在，则可能会导致问题。
一旦容器处于“死”状态，您可以再次docker rm -f来将它们从docker中删除，并且它们不应再次出现。 文件很可能丢失，因此devicemapper找不到它。

我设法使它再次崩溃，但是那时日志驱动程序json已打开。 在检查完所有容器的日志之后，只有haproxy会返回一些有用的输入“ /run.sh：fork：无法分配内存”。 没有交换，我的内存有点低，我必须用完内存。 如果是这个原因，是否意味着Docker在内存不足时崩溃，从而退出所有容器？

@trompx当然，没有什么可以阻止Docker被OOM杀死。
如果Docker崩溃，容器不会退出，但是当Docker启动备份时，它会杀死所有正在运行的容器（并启动具有重启策略的容器）。

在Ubuntu 14.04上使用docker-compose 1.4.2和docker-engine 1.8.3时，我经常看到这种情况。

@superdump内核版本？

@gionn ：3.13.0-65-通用

@superdump @gionn同上版本的软件，内核3.13.0-67-generic

在AWS上使用EBS SSD

是否有人尝试过使用docker 1.9来查看它是否已修复？ 有一些与卷有关的工作...

卷（就将数据扩展到容器生命周期之外）是与此处所受影响不同的功能，不是吗？

如果取消共享挂载是解决这些问题的可行解决方案，则默认情况下，守护程序启动时docker无法执行该操作。
实施起来应该足够简单。

这很简单，并且有多种方法可以完成此任务。 的
维护者不想接受这样做的拉取请求，因为它
是一个“ hack”。
2015年11月27日星期五，上午6:49 Andreas Stenius [email protected]
写道：

如果取消共享挂载是解决这些问题的可行解决方案，则Docker无法执行
守护程序启动时的默认设置。
实施起来应该足够简单。

-
直接回复此电子邮件或在GitHub上查看
https://github.com/docker/docker/issues/5684#issuecomment -160153438。

这不是真的。 我们确实有此问题，并引起了问题，因此我们将其还原。 如果它不会给您带来任何问题，那么对您而言，这样做是微不足道的。

谢谢（你的）信息。 我们在几个节点上添加了取消共享的“ hack”，
看看进展如何...
11月27日 2015年 19:01 skrev Brian Goff [email protected] ：

这不是真的。 我们确实有此问题，并引起了问题，因此我们将其还原。
如果它不会给您带来任何问题，那么对您而言，这样做是微不足道的。

-
直接回复此电子邮件或在GitHub上查看
https://github.com/docker/docker/issues/5684#issuecomment -160182860。

你好

使用Docker时出现上述问题。

Failed to remove container (da3b06dc0723): Error response from daemon: Unable to remove filesystem for da3b06dc072328112eec54d7b0e00c2c355a8ef471e1ba3c82ab3ffb8e93891f: remove /var/lib/docker/containers/da3b06dc072328112eec54d7b0e00c2c355a8ef471e1ba3c82ab3ffb8e93891f/shm: device or resource busy
Failed to remove container (99cfba26be16): Error response from daemon: Unable to remove filesystem for 99cfba26be16bf7b475aaa4ed3d50f7fca3179082decc60f1418d22745f5a855: remove /var/lib/docker/containers/99cfba26be16bf7b475aaa4ed3d50f7fca3179082decc60f1418d22745f5a855/shm: device or resource busy
Failed to remove container (c34922906202): Error response from daemon: Unable to remove filesystem for c34922906202713a573a45f18f8db45ad6788bde2255f75b0f0e027800721b26: remove /var/lib/docker/containers/c34922906202713a573a45f18f8db45ad6788bde2255f75b0f0e027800721b26/shm: device or resource busy

我的Docker版本信息如下：
客户：
版本：1.10.2
API版本：1.22
Go版本：go1.5.3
Git提交：c3959b1
建造时间：2016年2月22日星期一21:37:01
操作系统/ Arch：linux / amd64

服务器：
版本：1.10.2
API版本：1.22
Go版本：go1.5.3
Git提交：c3959b1
建造时间：2016年2月22日星期一21:37:01
操作系统/ Arch：linux / amd64

必须指出，我是最近才遇到此问题的。 我已经与Docker合作了将近一年。

你好
只是想提一下，在重新启动计算机后，我发现以前未删除的容器已被删除。 这确实解决了眼前的问题，但是积聚容器并且总是必须重新引导操作系统会很烦人。

@chirangaalwis +1。 您是否注意到容器运行了一段时间后会发生这种情况，还是在启动容器后立即发生这种情况？

你好
据我所记得，自容器启动以来，我经历了相当长的时间。 很长时间以后才要精确。

顺便说一句，如果有人可以详细解释此问题的原因，那将是很好的。 我对容器化的概念还比较陌生。

@chirangaalwis您是否检查了此问题： https :

+1。 是的，即使我的内核版本是3.13。 是的，我还将对此进行检查，并与我所报告的内容进行映射。

@chirangaalwis @kabobbob ...我使用的是RHEL 7.2和3.10内核。

[root<strong i="7">@pe2enpmas301</strong> npmo-server]# uname -a
Linux pe2enpmas301.corp.intuit.net 3.10.0-327.3.1.el7.x86_64 #1 SMP Fri Nov 20 05:40:26 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

在使用docker-compose停止和启动容器时，我不断收到此错误...。

Recreating npmoserver_policyfollower_1
ERROR: Driver devicemapper failed to remove root filesystem 3bb07965510f2c398c0fc99c3e0ce4696914f710efabc47f2df19ecf85725021: Device is Busy

唯一的解决方法是停止并等待几秒钟，然后重试。 问题是重启不能保证能正常工作。 我有时会尝试多次重新启动。

@chirangaalwis @marcellodesales我能够将服务器升级到内核3.16，并尝试了容器停止和rm。 一切似乎都运作良好。 将需要工作，看看问题是否解决。

@kabobbob请在几天后报告，如果证明效果更好...我将尝试升级预生产环境并报告。

在rhel 7.2上进行了此操作-yum更新&& systemctl重新启动修复了它。

使用直接LVM和Docker 1.9.1版

我也有这个问题。 我的设置：Ubuntu 14.04，更新为内核“ 3.19.0-58-generic＃64〜14.04.1-Ubuntu”。 Docker版本1.11.0，内部版本4dc5990。 “ docker-compose版本1.7.0，内部版本0d7bf73”。

当docker-compose up -d由于新映像而重新启动容器时，它通常因无法删除已停止的容器而终止。

只有重新启动才能帮助启动容器。 然后问题不是100％可重现的，但它经常发生。 因此，我不得不频繁地重新引导主机:-(

$ docker rm 5435d816c9a3_dockercomposeui_docker-compose-ui_1
Error response from daemon: Driver devicemapper failed to remove root filesystem 5435d816c9a35c63a5a636dc56b7d9052f1681ae21d604127b1685dab3848404: Device is Busy

和

# docker ps -a | grep dockercomposeui
5435d816c9a3        c695fdb43f7a                          "/env/bin/python /app"   2 days ago          Dead                                                                                                                   5435d816c9a3_dockercomposeui_docker-compose-ui_1

@dsteinkopf从1.10升级到1.11后是否遇到了这个问题？ 您在Ubuntu上使用devicemapper的任何原因？ 总体而言，默认设置（aufs）应该可以为您提供更好的性能。 在内核3.19上，覆盖甚至可能是一个更好的选择

不，使用docker 1.10和默认的ubuntu 14.04-kernel（我认为约为3.10）并使用aufs已经存在问题。 然后，我逐步升级了存储驱动程序，内核和泊坞窗。 遇到的问题没有重大变化...

您是否认为，值得对此问题进行覆盖？ （在我看来，性能并不是大问题。）

@thaJeztah我之前和之后都从未见过此问题

从1.10升级到1.11后是否遇到了这个问题

我有这个问题:(

还是这样
RHEL 7.2内核-3.10.0-327.el7.x86_64
Docker版本1.9.1，内部版本78ee77d / 1.9.1
device-mapper-libs-1.02.107-5.el7_2.1.x86_64

也有问题：

docker rm agent4 Error response from daemon: Driver aufs failed to remove root filesystem 16a3129667975c411d0084b38ba512761b64eaa7853f3452a7f8e4f2898d1175: rename /var/lib/docker/aufs/diff/76125e9141ec9de7c12e20d41b00cb44826b19bedf98bd9c650cb7a7cc07913a /var/lib/docker/aufs/diff/76125e9141ec9de7c12e20d41b00cb44826b19bedf98bd9c650cb7a7cc07913a-removing: device or resource busy

码头工人版本

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:26:49 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:26:49 2016
 OS/Arch:      linux/amd64

码头工人信息

Containers: 9
 Running: 8
 Paused: 0
 Stopped: 1
Images: 80
Server Version: 1.11.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 193
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.45 GiB
Name: chell
ID: BXX3:THMK:SWD4:FP35:JPVM:3MV4:XJ7S:DREY:O6XO:XYUV:RHXO:KUBS
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support

优名

Linux chell 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux

这是不同问题的混合。 我认为我们需要解决这个问题。 没有最新报告的病例像OP。

@guenhter我怀疑这与将/ var / run安装到容器（主机上的任何其他容器）或安装/ var / lib /

@guenhter记录＃21969

同样，许多1.11之前的“设备或资源繁忙”类型错误都可能是由于杀死守护程序（不合常规地）然后启动它而导致的。
这会导致将存储驱动程序挂载上的内部引用计数重置为0，同时挂载本身仍处于活动状态。
1.11解决了这种情况。

由于上述原因而关闭。

抱歉-我不确定我是否理解这一点。 您的意思是“最新报告的案件都不是OP”？
我（以及其他遇到此问题的人）应该怎么做？ 打开另一个案例？

@dsteinkopf是的，提供了尽可能多的详细信息（组成文件，守护程序日志等）。

您好，请注意我之前指定的问题，我已将内核版本升级至4.4.0-21-generic，而docker版本信息如下：
客户：
版本：1.11.0
API版本：1.23
Go版本：go1.5.4
Git提交：4dc5990
建成：2016年4月13日星期三18:38:59
操作系统/ Arch：linux / amd64

服务器：
版本：1.11.0
API版本：1.23
Go版本：go1.5.4
Git提交：4dc5990
建成：2016年4月13日星期三18:38:59
操作系统/ Arch：linux / amd64

先前报告的问题似乎已经停止发生。 通过升级内核版本在相当长的时间内使用了Docker，并且它似乎已经停止了。

找到了解决该问题的方法，至少在与docker-compose一起使用时，请参见https://github.com/docker/docker/issues/3786#issuecomment -221601065

无法重启的容器存在相同的问题。

Ubuntu 14.04
内核：3.13.0-24泛型
Docker版本：

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

错误：

Error response from daemon: Driver aufs failed to remove root filesystem 
802f3a6eb28f8f16bf8452675a389b1d8bf755e59c827d50bec9372420f4194a: 
rename /var/lib/docker/aufs/diff/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f /var/lib/docker/aufs/diff/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f-removing: 
device or resource busy

卸载失败：

umount: /var/lib/docker/devicemapper
/mnt/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f is not mounted 
(according to mtab)

这仍然是我们的问题（在Ubuntu 14.04.4 LTS（带有KVM）（3.13.0-88-generic）上使用1.11.2）。

我可以订阅任何公开票以获得更新吗？

@GameScripting请参阅＃21704

Linux zk1 3.10.0-327.28.3.el7.x86_64（centos 7）
Docker版本1.12.1，内部版本23cf638

来自守护程序的错误响应：驱动程序devicemapper无法删除根文件系统228f2c2da3de4d5abd3881184aeb330a4c18e4311ecf404e2fb8cd4ffe15e901：devicemapper：运行DeleteDevice dm_task_run的错误失败

刚遇到这个。 /etc/init.d/docker restart帮助了，我很高兴这不是在生产机器上...😢

$ docker --version
Docker version 1.11.1, build 5604cbe

仍然得到这个

$ docker --version
Docker version 1.12.2, build bb80604

同样的问题，已经在许多版本的Docker中发生。 我使用docker-compose重新创建容器。 有时它可以干净地工作，有时却不能。 重新启动docker守护进程或重新启动服务器会清理坏的容器。

Arch Linux； ext4 FS上的devicemapper容器。

$ docker version
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.7.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 19:42:59 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.7.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 19:42:59 2016
 OS/Arch:      linux/amd64
$ docker info
Containers: 24
 Running: 22
 Paused: 0
 Stopped: 2
Images: 56
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-8:3-13500430-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 9.394 GB
 Data Space Total: 107.4 GB
 Data Space Available: 78.15 GB
 Metadata Space Used: 24.82 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.123 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.135 (2016-09-26)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.7.2-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 30.85 GiB
Name: omega
ID: IR7W:NSNN:F2B3:YP32:YTQJ:OFEB:2XLK:HHCK:HJ33:5K3O:KEHI:SDUB
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8
$ df -T
Filesystem     Type     1K-blocks      Used Available Use% Mounted on
dev            devtmpfs  16169500         0  16169500   0% /dev
run            tmpfs     16173076      2712  16170364   1% /run
/dev/sda3      ext4     447260560 371064976  53453004  88% /
tmpfs          tmpfs     16173076         0  16173076   0% /dev/shm
tmpfs          tmpfs     16173076         0  16173076   0% /sys/fs/cgroup
tmpfs          tmpfs     16173076      1144  16171932   1% /tmp
/dev/sda1      ext4        289293     45063    224774  17% /boot
tmpfs          tmpfs      3234612         8   3234604   1% /run/user/1000
/dev/sdb2      ext4     403042160  15056296 367489480   4% /run/media/ivan/backup
/dev/sda4      ext4     480580312 320608988 135536228  71% /run/media/ivan/ARCHIVES
/dev/sdb3      ext4     225472980   1473948 212522604   1% /run/media/ivan/data

如果有帮助...

我相信我在这里也有相同/相似的问题。 如果使用compose up -d部署服务，然后在compose.yaml中将映像名称更新为其他名称，然后执行另一个compose up -d，则compose失败，并会出现关于devicemapper的错误：

错误
错误：<>驱动程序devicemapper无法删除根文件系统216c098e0f051407863934c27111bd1e9b7561dff1c4d67c0f0d45a99505fa70：设备正忙

版本信息：
码头工人版本
客户：
版本：1.12.1
API版本：1.24
Go版本：go1.6.3
Git提交：23cf638
内置：
操作系统/ Arch：linux / amd64

服务器：
版本：1.12.1
API版本：1.24
Go版本：go1.6.3
Git提交：23cf638
内置：
操作系统/ Arch：linux / amd64

作为临时的解决方法，我在重新启动之前先添加了docker-compose down --rmi。

我在Docker版本中也有同样的问题：1.12.3

我很确定其他遇到此问题的人都与＃27381相关

我在CentOs 7的docker 1.12.3中看到了这一点

dc2-elk-02：/ root / staging / ls-helper $ docker --version
Docker版本1.12.3，内部版本6b644ec
dc2-elk-02：/ root / staging / ls-helper $ uname -a
Linux dc2-elk-02 3.10.0-327.36.3.el7.x86_64＃1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02：/ root / staging / ls-helper $ docker rm ls-helper
来自守护程序的错误响应：驱动程序devicemapper无法删除根文件系统e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830：设备正忙

PS我不使用码头工人组成。

在主机空间不足后被咬。
任何影响挂载点的命令都会挂起（包括“ docker ps”，“ sync”，“ ls“，...）

我有类似的问题，我在/ var / log / syslog文件中看到了以下错误提示：
Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627417173+05:30" level=error msg="Failed to load container mount 00d7b9d64ff6c465276e67f5a5e3642ebacd9616c7602d4361b3a7fab038510a: mount does not exist" Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627816711+05:30" level=error msg="Failed to load container mount fb108b942f8ed87a9e1affb6480ed477a8f5f823b2639e36348cde4a97924c5e: mount does not exist"
我尝试搜索/var/lib/docker/volumes下的挂载点，但未找到任何挂载点
终于重启系统解决了这个问题