# docker --version
Docker version 1.10.3, build 99b71ce

# docker info
Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 29
Server Version: 1.10.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 99
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.13.0-83-generic
Operating System: <unknown>
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 125.9 GiB
Name: dev34-devc
ID: VKMX:YMJ2:3NGV:5J6I:5RYM:AVBK:QPOZ:ODYE:VQ2D:AF2J:2LEM:TKTE
WARNING: No swap limit support

我还应该表明docker没有列出任何容器，卷或图像：

$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

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

$ docker volume ls
DRIVER              VOLUME NAME

奇怪的; 特别是因为

Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 29

与docker images / docker ps的输出不匹配。

您正在运行什么操作系统？

Operating System: <unknown>

@tonistiigi有什么想法吗？

那是事后。 我想与此同时开始了一些进程。

我所指的状态（我现在有）是：

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0

而且我还有：

$ sudo du -hs /var/lib/docker/aufs/diff/a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
296M    /var/lib/docker/aufs/diff/a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea

我们使用已升级的内核的Ubuntu Lucid = /

$ uname -a
Linux dev34-devc 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 10.04.1 LTS
Release:        10.04
Codename:       lucid

这似乎是一个有趣的问题。
是否有办法复制它？ @bukzor

当然可以，但是我不知道如何。
请尝试在您的活动Docker主机之一上运行以下脚本，然后查看剩余内容。
在我们的案例中，总是会留下很多差异。

``＃！bash

！/ bin / bash

设置-eu

echo“警告::这将停止所有docker进程并删除所有docker映像。”
阅读-p“继续（y / n）吗？”
如果[“ $ REPLY”！=“ y”]; 然后
回显“正在中止”。
1号出口
科幻

xdocker（）{exec xargs -P10 -r -n1 --verbose docker“ $ @”; }

设置-x

取出容器

泊坞窗ps -q | xdocker停止
docker ps -aq | xdocker rm

删除标签

泊坞窗图片| sed 1天| grep -v'^'| col 1 2 | sed's / /：/'| xdocker rmi

删除图像

泊坞窗图像-q | xdocker rmi
泊坞窗图像-aq | xdocker rmi

删除卷

docker卷ls -q | xdocker卷rm
```

我看到这种情况的一种可能方法是，如果在卸载aufs时出现错误。 例如，如果有EBUSY错误，则可能之前已经删除了映像配置。

@bukzor如果有一个复制器从一个空的图形目录开始，拉入/运行图像，并使它进入运行脚本后无法完全清除的状态，那将非常有意思。

那会很有趣，但是听起来像是一整天的工作。
我不能承诺。

以下是有关上面（任意选择的）麻烦的diff a800的更多数据。

```＃！sh
$ docker-find a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea | 须藤xargs -n1 wc -l | 排序-rn

• 须藤查找/ nail / var / lib / docker'（'-path'/ nail / var / lib / docker / aufs / diff / '-o -path'/ nail / var / lib / docker / aufs / mnt / '' ）'-修剪-o-打印
• grep a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
• 须藤查找/ nail / var / lib / docker'（'-path'/ nail / var / lib / docker / aufs / diff / '-o -path'/ nail / var / lib / docker / aufs / mnt / '' ）'-修剪-o -type f -print0
• 须藤xargs -0 -P20 grep -l a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  15 / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
  14 / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579-init
  13 / nail / var / lib / docker / aufs / layers / 993e4988c510ec3ab4f6d139740a059df40585576f8196817e573a9684554c5c
  12 / nail / var / lib / docker / aufs / layers / cf9fd1c4a64baa39b6d6d9dac048ad2fff3c3fe13924b07377e767eed230ba9f
  11 / nail / var / lib / docker / aufs / layers / 4e6afb958b5ee6dea6d1a886d19fc9c780d4ecc4baeebfbde31f9bb97732d10d
  10 / nail / var / lib / docker / aufs / layers / 23ce5a473b101d85f0e9465debe5a0f3b8a2079b99528a797b02052d06bc11d8
  9 / nail / var / lib / docker / aufs / layers / 95e68d59a8704f2bb52cc1306ca910ddb7af8956eb7c57970fcf7d8b3d9baddb
  8 / nail / var / lib / docker / aufs / layers / ac6b8ff4c0e7b91230ebf4c1caf16f06c1fdceff6111fd58f4ea50fc2dd5050b
  7 / nail / var / lib / docker / aufs / layers / fd895b6f56aedf09c48dba97931a34cea863a21175450c31b6ceadde03f7b3da
  6 / nail / var / lib / docker / aufs / layers / d5bbef5adf2efb6f15d4f96c4bee21beb955255d1ec17baf35de66e98e6c7328
  5 / nail / var / lib / docker / aufs / layers / 9646360df378b88eae6f1d6288439eebd9647d5b9e8a471840d4a9d6ed5d92a4
  4 / nail / var / lib / docker / aufs / layers / a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  0 / nail / var / lib / docker / image / aufs / layerdb / sha256 / d1c659b8e3d0e893e95c8eedc755adcb91a1c2022e1090376b451f7206f9b1c0 / cache-id

So we see there's a chain of child layers, with `f3286009193` as the tip.

$ docker-find f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579'$'

• 须藤查找/ nail / var / lib / docker'（'-path'/ nail / var / lib / docker / aufs / diff / '-o -path'/ nail / var / lib / docker / aufs / mnt / '' ）'-修剪-o-打印
• grep --color'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
• 须藤查找/ nail / var / lib / docker'（'-path'/ nail / var / lib / docker / aufs / diff / '-o -path'/ nail / var / lib / docker / aufs / mnt / '' ）'-修剪-o -type f -print0
• sudo xargs -0 -P20 grep --color -l'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id

So that layer was used in mount `eb809c0321`. I don't find any references to that mount anywhere:

$ docker-find eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e

• 须藤查找/ nail / var / lib / docker'（'-path'/ nail / var / lib / docker / aufs / diff / '-o -path'/ nail / var / lib / docker / aufs / mnt / '' ）'-修剪-o-打印
• grep --color eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / init-id
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / parent
• 须藤查找/ nail / var / lib / docker'（'-path'/ nail / var / lib / docker / aufs / diff / '-o -path'/ nail / var / lib / docker / aufs / mnt / '' ）'-修剪-o -type f -print0
• sudo xargs -0 -P20 grep --color -l eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  ```

有什么方法可以找到用于安装的容器吗？
医生只说挂载ID不再等于容器ID，这不是很有帮助。
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

@bukzor eb809c0321是容器ID。 docs的意思是aufs id（在您的情况下为f3286009193f ）不是容器ID。

/ cc以及@dmcgowan

@tonistiigi好的。

显然，安装座的寿命已经超过了它的容器。

在容器生命周期的什么时候清理支架？
这是用于运行/停止容器的临时可写auf吗？

@bukzor （rw）挂载在删除容器时被删除。 卸载在容器进程停止时发生。 Diff文件夹是存放各个图层内容的地方，无论图层是否已安装都无关紧要。

@bukzor aufs ID和容器ID之间的链接可以在image/aufs/layerdb/mounts/<container-id>/mount-id 。 从仅知道aufs id以来，找到容器ID的最简单方法是grep image/aufs/layerdb目录。 如果未找到任何内容，则说明清理没有完全完成。

遇到类似的问题。

我们正在docker守护程序服务器中运行每日CI。 / var / lib / docker / aufs / diff占用了大量的磁盘容量，这是不应该的。

尽管如此2gb的aufs/diff乱投医合理的建议在这里或在相关的线程（包括@bukzor的bash脚本以上）之后。

如果没有适当的解决方法，是否有任何直接的方法可以删除剩余的安装而不同时删除所有其他映像？ （如果当前没有容器在运行，我想应该没有安装了，对吗？）

我遇到了同样的问题。 我正在使用这台机器测试很多容器，然后提交/删除。 我的/ var / lib / docker / aufs目录当前重7.9G。 我将不得不将该目录移动到另一个挂载点，因为该目录上的存储空间有限。 :(

# du -sh /var/lib/docker/aufs/diff/
1.9T    /var/lib/docker/aufs/diff/

@mcallaway aufs/diff内容都将是在容器中执行的fs写操作。

我有同样的问题。 我拥有的所有容器都处于运行状态，但是有许多aufs diff目录与这些容器无关，而与旧的已删除容器有关。 我可以手动删除它们，但这不是一个选择。 应该有这种行为的原因。

我使用k8s 1.3.5和docker 1.12。

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc运行得到了帮助。

我有同样的问题。 我正在将Gitlab CI与Dind（docker中的docker）一起使用。

恕我直言，当注册表中的映像在同一标签中更新并被拉出，然后重新启动了相关容器，除非运行spotify/docker-gc否则不会对旧容器和映像进行GC处理。

别人可以确认吗？

@kayrus正确，泊坞窗不会自动假定“未标记”图像也应_removed_。 容器可能仍在使用该映像，并且您仍可以从该映像启动新容器（通过其ID引用它）。 您可以使用docker rmi $(docker images -qa -f dangling=true)删除“悬空”的图像。 此外，docker 1.13将获得数据管理命令（请参阅https://github.com/docker/docker/pull/26108），使您可以更轻松地清理未使用的图像，容器等。

@thaJeztah /var/lib/docker/aufs/diff/实际包含“未标记”图像吗？

@kayrus是的，它们是图像的一部分（已标记和未标记）

遇到类似的问题，没有容器/图像/卷，〜13Gb的差异

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 1030
 Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 3.13.0-32-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.861 GiB
Name: gitrunner
ID: GSAW:6X5Z:SHHU:NZIM:O76D:P5OE:7OZG:UFGQ:BOAJ:HJFM:5G6W:5APP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

$ docker volume ls
DRIVER              VOLUME NAME
$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
$

$ df -h
Filesystem                                 Size  Used Avail Use% Mounted on
...
/dev/mapper/gitrunner--docker-lib--docker   18G   15G  2.6G  85% /var/lib/docker

/var/lib/docker# sudo du -sm aufs/*
13782   aufs/diff
5       aufs/layers
5       aufs/mnt

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: xfs
 Dirs: 1122

同样的问题在这里。 我知道1.13可能会获得数据管理命令，但与此同时，我只想安全删除该目录的内容，而不会杀死Docker。

在这一点上，这是相对阻塞的。

同样在这里。 还是没有官方的解决方案？

我在（Docker社区）Slack中提出了几次不同的建议。 每次有少数人浏览垃圾收集脚本/ cmds的列表时，我都应该作为解决方案来运行。

尽管这些措施在此期间有所帮助（阅读：尚未解决-空间仍在逐渐趋于饱和），但我认为我们都可以认为这不是理想的长期解决方案。

@jadametz 1.13具有docker system prune 。
除此之外，我不确定Docker还可以提供哪些帮助（建议公开）。 图像不仅可以自己进入系统，还可以通过拉取，构建等方式进入系统。

对于实际的孤立层（系统上没有引用它们的图像），我们需要单独解决。

我有完全一样的问题！

docker info Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 0 Server Version: 1.12.1 Storage Driver: aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 2501 Dirperm1 Supported: false Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host null overlay Swarm: inactive Runtimes: runc Default Runtime: runc Security Options: apparmor Kernel Version: 3.13.0-96-generic Operating System: Ubuntu 14.04.2 LTS OSType: linux Architecture: x86_64 CPUs: 8 Total Memory: 14.69 GiB Name: ip-172-31-45-4 ID: R5WV:BXU5:AV6T:GZUK:SAEA:6E74:PRSO:NQOH:EPMQ:W6UT:5DU4:LE64 Docker Root Dir: /var/lib/docker Debug Mode (client): false Debug Mode (server): false Registry: https://index.docker.io/v1/ WARNING: No swap limit support Insecure Registries: 127.0.0.0/8

没有图像，容器或卷。 42Gb的Aufs / diff

任何有助于安全清除此目录的操作都将非常有用！ 尝试了该线程中的所有操作，但未成功。 谢谢。

@adamdry仅第三方脚本： https :

感谢@kayrus，我确实做了尝试，它稍微增加了我的磁盘总使用量，并且似乎对aufs / diff目录没有任何作用。

我还尝试docker system prune未运行的docker rmi $(docker images -qa -f dangling=true) ，但找不到要删除的图像。

对于有兴趣的人，我现在使用它来清理所有容器，图像，卷和旧的auf：

### FYI I am a Docker noob so I don't know if this causes any underlying issues but it does work for me - use at your own risk ###

许多灵感来自于此： http :

docker rm -f $(docker ps -a -q) && docker rmi -f $(docker images -q) && docker rmi -f $(docker images -a -q)
service docker stop
rm -rf /var/lib/docker/aufs
rm -rf /var/lib/docker/image/aufs
rm -f /var/lib/docker/linkgraph.db
service docker start

@adamdry在执行rm / rmi时最好不要使用-f ，因为它会隐藏删除中的错误。
我确实考虑了当前情况... -f隐藏了一个错误，然后我们留下了一些对用户完全不可见的剩余状态...作为一个错误。

我还在全新的，毫不奇怪的安装中看到了这一点：

root<strong i="6">@builder</strong>:/var/lib/docker# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.4
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 63
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay host null bridge
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.625 GiB
Name: builder
ID: 2WXZ:BT74:G2FH:W7XD:VVXM:74YS:EA3A:ZQUK:LPID:WYKF:HDWC:UKMJ
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
Insecure Registries:
 127.0.0.0/8
root<strong i="7">@builder</strong>:/var/lib/docker# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
root<strong i="8">@builder</strong>:/var/lib/docker# docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
root<strong i="9">@builder</strong>:/var/lib/docker# du -hd2
4.0K    ./swarm
6.0M    ./image/aufs
6.0M    ./image
4.0K    ./trust
28K ./volumes
4.0K    ./containers
276K    ./aufs/layers
292K    ./aufs/mnt
1.5G    ./aufs/diff <-------------------------
1.5G    ./aufs
4.0K    ./tmp
72K ./network/files
76K ./network
1.5G    .
root<strong i="10">@builder</strong>:/var/lib/docker# 

@robhaswell看到它是新安装的，您要尝试这个吗？ https://github.com/docker/docker/issues/22207#issuecomment -266784433

@adamdry我已经删除了/var/lib/docker/aufs因为它阻止了我的工作。 您期望您的指示能达到什么目的？ 如果他们阻止问题在将来再次发生，那么我可以尝试重新创建问题并尝试您的指示。 但是，如果目的只是释放空间，那么我已经实现了。

@robhaswell是的，这是为了释放磁盘空间，但是在尝试重建映像时遇到了后续问题，但是通过遵循该脚本中的所有步骤，它解决了这些问题。

在构建期间，如果构建过程在层构建过程（也包含要复制的Blob）期间中断，然后停止容器，它将在/ var / lib / docker / aufs / diff /中留下数据。 它出现了晃来晃去的图像。 清理它也没有释放空间。 是否可以将其作为docker system prune的一部分包含在内？ 仅删除此文件夹中的Blob数据可以释放空间，我不确定这是否会引起任何问题。

Docker版本：1.13.0-rc1

在构建过程中，如果构建过程在层构建过程中中断（该过程也包含要复制的Blob），然后停止容器，则它将留下数据

这也可能是我遇到问题的原因-我打断了很多版本。

在docker pull期间，观察到以下两种情况：

1. 如果该进程在显示“下载”（下载/ var / lib / docker / tmp /中的图像层）时中断，它将清除该文件夹中的所有数据
2. 如果该过程在说提取时中断（我想是从tmp提取层到/ var / lib / docker / aufs / diff /），它将清除tmp和diff blob数据。

在图像构建过程中，

1. 在“将构建上下文发送到docker守护程序中”（在我的情况下将blob数据复制到/ var / lib / docker / tmp /中）中中断该过程时，它永远存在，并且不能通过任何命令清除，除非手动删除它。 我不确定如何处理apt中的图像更新。
2. 在构建包含blob数据的层（例如，大型软件设置）的过程中，如果进程中断，则docker容器将继续在映像上工作。 在我的情况下，只有1层Blob数据（已在tmp文件夹中提供）构成了整个图像。 但是，如果使用docker stop命令停止了容器，则会发生两种情况：
   一种。 如果挂载过程仍在进行，它将把数据保留在tmp和diff文件夹中。
   b。 如果将数据复制到diff文件夹中，它将从tmp文件夹中删除数据，并将数据保留在diff文件夹中，甚至可能在mount文件夹中。

我们有一个自动化的构建过程，需要一个控件来优雅地停止任何构建过程。 最近，由于配置低的机器上的内存不足错误，进程被内核杀死。

如果要由2层构建一个映像，则要构建1层并中断第2层，则Docker系统修剪似乎为被中断并停止的层的容器清除数据。 但是它不会在发生中断的情况下清除前几层的数据。 另外，它没有反映要求保护的总磁盘空间。 在带有aufs文件系统的AWS，ubuntu 14.04，x86_64位系统上运行这些测试。 使用docker 1.13.0 rc3和docker 1.12运行docker prune测试

@thaJeztah
如果我误解了任何内容，请告诉我。

我打开了一个/var/lib/docker/tmp文件没有清理的问题； https://github.com/docker/docker/issues/29486

Docker系统修剪似乎为被中断并已停止的层的容器清除了数据。 但是它不会在发生中断的情况下清除前几层的数据。

我试图重现这种情况，但是用一个简单的案例却看不到它。

从全新安装为空的/var/lib/docker ，为创建一个大文件
测试和一个Dockerfile;

mkdir repro && cd repro
fallocate -l 300M bigfile

cat > Dockerfile <<EOF
FROM scratch
COPY ./bigfile /
COPY ./bigfile /again/
COPY ./bigfile /and-again/
EOF

开始docker build ，并在构建时取消，但是_after_构建
上下文已发送；

docker build -t stopme .
Sending build context to Docker daemon 314.6 MB
Step 1/4 : FROM scratch
 --->
Step 2/4 : COPY ./bigfile /
 ---> 28eb6d7b0920
Removing intermediate container 98876b1673bf
Step 3/4 : COPY ./bigfile /again/
^C

检查/var/lib/docker/aufs/

du -h /var/lib/docker/aufs/
301M    /var/lib/docker/aufs/diff/9127644c356579741348f7f11f50c50c9a40e0120682782dab55614189e82917
301M    /var/lib/docker/aufs/diff/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084/again
301M    /var/lib/docker/aufs/diff/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084
601M    /var/lib/docker/aufs/diff
8.0K    /var/lib/docker/aufs/layers
4.0K    /var/lib/docker/aufs/mnt/9127644c356579741348f7f11f50c50c9a40e0120682782dab55614189e82917
4.0K    /var/lib/docker/aufs/mnt/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084
4.0K    /var/lib/docker/aufs/mnt/b6ffb1d5ece015ed4d3cf847cdc50121c70dc1311e42a8f76ae8e35fa5250ad3-init
16K /var/lib/docker/aufs/mnt
601M    /var/lib/docker/aufs/

运行docker system prune命令清理图像，容器；

docker system prune -a
WARNING! This will remove:
    - all stopped containers
    - all volumes not used by at least one container
    - all networks not used by at least one container
    - all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:253b2968c0b9daaa81a58f2a04e4bc37f1dbf958e565a42094b92e3a02c7b115
deleted: sha256:cad1de5fd349865ae10bfaa820bea3a9a9f000482571a987c8b2b69d7aa1c997
deleted: sha256:28eb6d7b09201d58c8a0e2b861712701cf522f4844cf80e61b4aa4478118c5ab
deleted: sha256:3cda5a28d6953622d6a363bfaa3b6dbda57b789e745c90e039d9fc8a729740db

Total reclaimed space: 629.1 MB

检查/var/lib/docker/aufs/

du -h /var/lib/docker/aufs/
4.0K    /var/lib/docker/aufs/diff
4.0K    /var/lib/docker/aufs/layers
4.0K    /var/lib/docker/aufs/mnt/b6ffb1d5ece015ed4d3cf847cdc50121c70dc1311e42a8f76ae8e35fa5250ad3-init
8.0K    /var/lib/docker/aufs/mnt
20K /var/lib/docker/aufs/

我确实看到-init挂载了，我会检查是否可以解决
那个（尽管它只是一个空目录）

我使用的dockerfile唯一的区别是（创建了不同的层）
从头开始
COPY [“ ./bigfile”，“ randomNoFile1”，/]
COPY [“ ./bigfile”，“ randomNoFile2”，/]
紧急行动

我不确定是否会有所作为。

不，问题不在于空的init文件夹。 就我而言，这是blob。 但是，我可以在星期一重新检查并更新。

另外，当时使用的是5GB文件，是通过从dev urandom中读取字节来创建的。
在您的情况下，同一文件被添加2次。 会创建一个单层并从其上安装第二层，还是将其分为2个单独的层？ 就我而言，它总是2个单独的层。

@thaJeztah
感谢您对问题的快速回复。 添加此功能将有很大帮助！

@ monikakatiyar16我尝试通过在ADD和RUN命令中多次取消构建来重现此错误，但是删除后无法泄漏到aufs/diff 。 我不太了解您要停止使用哪个容器，因为在ADD/COPY操作期间不应运行容器。 如果您可以将一个可以运行的复制器放在一起，将不胜感激。

我可能做错了什么。 由于我周末旅行，因此我将在星期一复制并更新所有必需的信息。

@tonistiigi @thaJeztah
我觉得你是对的。 实际上，没有任何列出为活动和正在运行的容器。 相反，有死容器。 在我的情况下，Docker系统修剪不起作用，可能是因为该过程没有被Ctrl + C杀死。 相反，它一直在后台运行。 就我而言，这就是原因，它无法删除这些斑点。

当我使用Ctrl + C中断进程时，构建进程被杀死，但是docker-untar进程仍在后台运行，从而继续构建映像。 （注意：/ var / lib / docker软链接到/ home / lib / docker以使用EBS卷在AWS上处理大数据）

root 12700 10781 7 11:43 ? 00:00:04 docker-untar /home/lib/docker/aufs/mnt/d446d4f8a7dbae162e7578af0d33ac38a63b4892905aa86a8d131c1e75e2828c

我已附加了用于创建大文件和构建图像的脚本（gc_maxpush_pull.sh）

还附带了构建过程的行为，该过程用于使用Ctrl + C（DockerBuild_WOProcessKill）构建图像中断并构建图像-使用Ctrl + C中断图像-终止进程（DockerBuild_WithProcessKill）

使用命令-

创建大文件： ./gc_maxpush_pull.sh 1 5gblayer 0 512 1

要生成图像： ./gc_maxpush_pull.sh 1 5gblayer 1 512 1

DockerBuild.zip

复制步骤：

1. 创建一个5GB的大文件
2. 开始构建过程并仅在发送构建上下文结束并且实际上正在复制Blob之后才中断构建过程。
3. 一段时间后，它完成了映像的构建并将其显示在docker映像中（如我附带的情况1-DockerBuild_WOProcessKill）
4. 如果该进程被终止，则将花费一会儿并将blob数据保留在/ diff中（在终止进程时，应将其突然终止，如文件中所附加的那样-DockerBuild_WithProcessKill）

如果我的假设是正确的，那么这可能不是docker prune的问题，而是因为杀死docker build而对我不起作用。

是否有一种优雅的方式来中断或停止构建映像过程，该方法还需要清理复制的数据（在docker pull中处理）？

以前，我并没有取消该过程。 我也很好奇docker-untar做了什么，为什么将它既挂载到/ mnt和/ diff文件夹，又又清理了/ mnt文件夹？

已在Docker 1.12.5版，AWS上构建7392c3b上对此进行了测试

码头工人信息
货柜：2
跑步：0
已暂停：0
已停止：2
图片：0
伺服器版本：1.12.5
存储驱动程序：aufs
根目录：/ home / lib / docker / aufs
支持文件系统：extfs
异常：4
Dirperm1支持：false
记录驱动程序：json-file
Cgroup驱动程序：cgroupfs
外挂程式：
数量：本地
网络：覆盖网桥空主机
群：不活动
运行时：runc
默认运行时：runc
安全选项：apparmor
内核版本：3.13.0-105-泛型
作业系统：Ubuntu 14.04.4 LTS
操作系统类型：linux
架构：x86_64
CPU：2
总内存：3.859 GiB
姓名：大师
ID：2 NQU：D2C5 ：5 WPL：IIDR ：P6FO：OAG7：GHW6： ZJMQ：VDHI ：B5CI： XFZJ：ZSZM
Docker根目录：/ home / lib / docker
调试模式（客户端）：false
调试模式（服务器）：false
注册表： https ：
警告：不支持交换限制
不安全的注册表：
127.0.0.0/8

@ monikakatiyar16当我在构建期间手动untar进程时，我在构建输出中得到Error processing tar file(signal: killed): 。 将正确的行为留在docker ps -a中，在任何构建错误中都会发生相同的事情，并且可以调试导致构建失败的问题。 我可以删除该容器，但是如果我这样做，也可以清除/var/lib/docker/aufs中的所有数据。

@tonistiigi是的，您是正确的。 在终止docker-untar进程后，我能够删除与容器关联的卷，并清理了所有内容。 在这种情况下，Docker系统修剪也可以使用。

剩下卷的实际问题是这种情况，当不终止docker-untar进程时，我尝试将docker容器与卷一起删除-这产生了以下错误：

docker rm -v -f $(docker ps -a -q)
Error response from daemon: Driver aufs failed to remove root filesystem 97931bf059a0ec219efd3f762dbb173cf9372761ff95746358c08e2b61f7ce79: rename /home/lib/docker/aufs/diff/359d27c5b608c9dda1170d1e34e5d6c5d90aa2e94826257f210b1442317fad70 /home/lib/docker/aufs/diff/359d27c5b608c9dda1170d1e34e5d6c5d90aa2e94826257f210b1442317fad70-removing: device or resource busy

守护程序日志：

Error removing mounted layer 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: rename /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec-removing: device or resource busy ERRO[0956] Handler for DELETE /v1.25/containers/78fb899aab98 returned error: Driver aufs failed to remove root filesystem 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: rename /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec-removing: device or resource busy ERRO[1028] Error unmounting container 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: no such file or directory

似乎现在要中断docker构建需要遵循的命令是：
Interrupt docker build > Kill docker untar process > remove container and volume : docker rm -v -f $(docker ps -a -q)

对于docker v1.13.0-rc4 ，可以是Interrupt docker build > Kill docker untar process > docker system prune -a

这似乎完美地工作。 没有清理问题，而是唯一的问题是docker-untar进程没有与docker-build进程一起被杀死。

我将搜索/更新/记录一个新问题，以对docker build进行正常中断，该中断也会同时停止docker-untar进程。

（已通过docker v1.12.5和v1.13.0-rc4进行了验证）

更新：在将构建上下文发送到docker守护进程时杀死docker-untar时，它在构建中给出了错误： Error response from daemon: Error processing tar file(signal: terminated) ，但是在层复制期间却没有

感谢您如此耐心并给予您宝贵的时间！

我看到/var/lib/docker/aufs在docker群模式工作器上的大小持续增加。 这件事大部分是由群集管理器自主管理的，除了这里和那里的一些维护命令外，很少手动创建容器。

我确实在服务容器上运行docker exec ； 不知道这是否可能是原因。

在我的情况下，要解决此问题，我的解决方法是启动另一个工作器，将完整节点设置为--availability=drain然后手动移动几个卷挂载。

ubuntu@ip-172-31-18-156:~$ docker --version
Docker version 1.12.3, build 6b644ec

这已经影响了我们的CI服务器很多年了。 这需要解决。

@orf谢谢

同样的问题在这里。 容器，卷和映像删除对Docker 1.13清理命令均无效。

我还确认我做了一些图像生成取消。 也许留下的文件夹也无法访问。
我现在将使用旧的rm方法，但这显然是一个错误。

/ var / lib / docker / aufs / diff中的文件为30G的/ dev / sda1文件系统填充了100％的空间

root @ Ubuntu ：/ var / lib / docker / aufs / diff＃df -h

已使用的文件系统大小可用百分比已安装在
udev 14G 0 14G 0％/ dev
tmpfs 2.8G 273M 2.5G 10％/运行
/ dev / sda1 29G 29G 0 100％/
tmpfs 14G 0 14G 0％/ dev / shm
tmpfs 5.0M 0 5.0M 0％/运行/锁定
tmpfs 14G 0 14G 0％/ sys / fs / cgroup
/ dev / sdb1 197G 60M 187G 1％/ mnt
tmpfs 2.8G 0 2.8G 0％/运行/用户/ 1000

du -h -d 1 / var / lib / docker / aufs / diff | grep'[0-9] G>'
表演

4.1G / var / lib / docker / aufs / diff / a0cde42cbea362bbb2a73ffbf30059bcce7ef0256d1d7e186264f915d15
14G / var / lib / docker / aufs / diff / 59aee33d8a607b5315ce103cd99f17b4dfdec73c9a2f3bb2afc7d02bfae
20G / var / lib / docker / aufs / diff

还尝试了docker system prune ，但没有帮助。

在代码中修复此错误之前，是否有人在diff中找到解决此超大文件问题的解决方案？

是的，已经给出了该方法，但这是一个启示性的摘要，它破坏了我在工作中放置的所有内容（卷的本地文件夹除外）。 放入bashrc或另一个bash配置文件。

```
别名docker-full-cleanup ='func_full-cleanup-docker'

func_full-cleanup-docker（）{

echo“警告：这将删除docker中的所有内容：卷，容器和图像。您敢吗？[y / N]”
阅读选择

如果[（“ $ choice” ==“ y”）-o（“ $ choice” ==“ Y”）]
然后
sudo echo“> sudo权限检查[确定]”
sizea = sudo du -sh /var/lib/docker/aufs

echo "Stopping all running containers"
containers=`docker ps -a -q`
if [ -n "$containers" ]
then
  docker stop $containers
fi

echo "Removing all docker images and containers"
docker system prune -f

echo "Stopping Docker daemon"
sudo service docker stop

echo "Removing all leftovers in /var/lib/docker (bug #22207)"
sudo rm -rf /var/lib/docker/aufs
sudo rm -rf /var/lib/docker/image/aufs
sudo rm -f /var/lib/docker/linkgraph.db

echo "Starting Docker daemon"
sudo service docker start

sizeb=`sudo du -sh /var/lib/docker/aufs`
echo "Size before full cleanup:"
echo "        $sizea"
echo "Size after full cleanup:"
echo "        $sizeb"

科幻
}`

我现在运行rm -rf命令以从diff文件夹中删除文件。 如果diff文件夹再次占据了整个Dis空间，则可能必须查看脚本。
希望看到此问题已在代码中解决，而不是变通解决。

嗨，我在docker 1.10.2中遇到了同样的问题，我正在运行kubernetes。 这是我的Docker版本：

Containers: 7
 Running: 0
 Paused: 0
 Stopped: 7
Images: 4
Server Version: 1.10.2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 50
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.4.0-31-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.954 GiB
Name: ubuntu-k8s-03
ID: NT23:5Y7J:N2UM:NA2W:2FHE:FNAS:56HF:WFFF:N2FR:O4T4:WAHC:I3PO
Debug mode (server): true
 File Descriptors: 10
 Goroutines: 23
 System Time: 2017-02-14T15:25:00.740998058+09:00
 EventsListeners: 0
 Init SHA1: 3e247d0d32543488f6e70fbb7c806203f3841d1b
 Init Path: /usr/lib/docker/dockerinit
 Docker Root Dir: /var/lib/docker
WARNING: No swap limit support

我试图通过分析/var/lib/docker/image/aufs/imagedb下的图层文件来跟踪/var/lib/docker/aufs/diff和/var/lib/docker/aufs/mnt/下所有未使用的diff目录，这是我使用的脚本：

https://gist.github.com/justlaputa/a50908d4c935f39c39811aa5fa9fba33

但是当我停止并重新启动docker守护程序时遇到了问题，似乎我使docker状态有些不一致：

/var/log/upstart/docker.log：

DEBU[0277] Cleaning up old shm/mqueue mounts: start.
DEBU[0277] Cleaning up old shm/mqueue mounts: done.
DEBU[0277] Clean shutdown succeeded
Waiting for /var/run/docker.sock
DEBU[0000] docker group found. gid: 999
DEBU[0000] Server created for HTTP on unix (/var/run/docker.sock)
DEBU[0000] Using default logging driver json-file
INFO[0000] [graphdriver] using prior storage driver "aufs"
DEBU[0000] Using graph driver aufs
INFO[0000] Graph migration to content-addressability took 0.00 seconds
DEBU[0000] Option DefaultDriver: bridge
DEBU[0000] Option DefaultNetwork: bridge
INFO[0000] Firewalld running: false
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT]
DEBU[0000] /sbin/iptables, [--wait -t nat -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -X DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -X DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -F DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t filter -X DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t nat -n -L DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -N DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -n -L DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -n -L DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t filter -C DOCKER-ISOLATION -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -I DOCKER-ISOLATION -j RETURN]
/var/run/docker.sock is up
DEBU[0000] Registering ipam driver: "default"
DEBU[0000] releasing IPv4 pools from network bridge (dcfcc71060f02440ae53da5ee0f083ca51c33a290565f1741f451754ae6b4257)
DEBU[0000] ReleaseAddress(LocalDefault/10.254.69.0/24, 10.254.69.1)
DEBU[0000] ReleasePool(LocalDefault/10.254.69.0/24)
DEBU[0000] Allocating IPv4 pools for network bridge (159d0a404ff6564b4fcfe633f0c8c123c0c0606d28ec3b110272650c5fc1bcb6)
DEBU[0000] RequestPool(LocalDefault, 10.254.69.1/24, , map[], false)
DEBU[0000] RequestAddress(LocalDefault/10.254.69.0/24, 10.254.69.1, map[RequestAddressType:com.docker.network.gateway])
DEBU[0000] /sbin/iptables, [--wait -t nat -C POSTROUTING -s 10.254.69.0/24 ! -o docker0 -j MASQUERADE]
DEBU[0000] /sbin/iptables, [--wait -t nat -C DOCKER -i docker0 -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -t nat -I DOCKER -i docker0 -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -D FORWARD -i docker0 -o docker0 -j DROP]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -i docker0 -o docker0 -j ACCEPT]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -i docker0 ! -o docker0 -j ACCEPT]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT]
DEBU[0001] /sbin/iptables, [--wait -t nat -C PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t nat -C OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]
DEBU[0001] /sbin/iptables, [--wait -t nat -A OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -j DOCKER-ISOLATION]
DEBU[0001] /sbin/iptables, [--wait -D FORWARD -j DOCKER-ISOLATION]
DEBU[0001] /sbin/iptables, [--wait -I FORWARD -j DOCKER-ISOLATION]
WARN[0001] Your kernel does not support swap memory limit.
DEBU[0001] Cleaning up old shm/mqueue mounts: start.
DEBU[0001] Cleaning up old shm/mqueue mounts: done.
DEBU[0001] Loaded container 0790b33ec8e5345ac944d560263b8e13cb75f80dd82cd25753c7320bbcb2747c
DEBU[0001] Loaded container 0e36a6c9319e6b7ca4e5b5408e99d77d51b1f4e825248c039ba0260e628c483d
DEBU[0001] Loaded container 135fb2e8cad26d531435dcd19d454e41cf7aece289ddc7374b4c2a984f8b094a
DEBU[0001] Loaded container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973
DEBU[0001] Loaded container 35eb075b5815e621378eb8a7ff5ad8652819ec851eaa4f7baedb1383dfa51a57
DEBU[0001] Loaded container 6be37a301a8f52040adf811041c140408224b12599aa55155f8243066d2b0b69
DEBU[0001] Loaded container d98ac7f052fef31761b82ab6c717760428ad5734df4de038d80124ad5b5e8614
DEBU[0001] Starting container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973
ERRO[0001] Couldn't run auplink before unmount: exit status 22
ERRO[0001] error locating sandbox id d4c538661db2edc23c79d7dddcf5c7a8886c9477737888a5fc2641bc5e66da8b: sandbox d4c538661db2edc23c79d7dddcf5c7a8886c9477737888a5fc2641bc5e66da8b not found
WARN[0001] failed to cleanup ipc mounts:
failed to umount /var/lib/docker/containers/2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973/shm: invalid argument
ERRO[0001] Failed to start container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973: error creating aufs mount to /var/lib/docker/aufs/mnt/187b8026621da2add42330c9393a474fcd9af2e4567596d61bcd7a40c85f71da: invalid argument
INFO[0001] Daemon has completed initialization
INFO[0001] Docker daemon                                 commit=c3959b1 execdriver=native-0.2 graphdriver=aufs version=1.10.2
DEBU[0001] Registering routers
DEBU[0001] Registering HEAD, /containers/{name:.*}/archive

当我尝试通过docker run创建新容器时，它失败并显示以下消息：

docker: Error response from daemon: error creating aufs mount to /var/lib/docker/aufs/mnt/f9609c0229baa2cdc6bc07c36970ef4f192431c1b1976766b3ea23d72c355df3-init: invalid argument.
See 'docker run --help'.

并且守护程序日志显示：

DEBU[0173] Calling POST /v1.22/containers/create
DEBU[0173] POST /v1.22/containers/create
DEBU[0173] form data: {"AttachStderr":false,"AttachStdin":false,"AttachStdout":false,"Cmd":["/hyperkube","kubelet","--api-servers=http://localhost:8080","--v=2","--address=0.0.0.0","--enable-server","--hostname-override=172.16.210.87","--config=/etc/kubernetes/manifests-multi","--cluster-dns=10.253.0.10","--cluster-domain=cluster.local","--allow_privileged=true"],"Domainname":"","Entrypoint":null,"Env":[],"HostConfig":{"Binds":["/sys:/sys:ro","/dev:/dev","/var/lib/docker/:/var/lib/docker:rw","/var/lib/kubelet/:/var/lib/kubelet:rw","/var/run:/var/run:rw","/etc/kubernetes/manifests-multi:/etc/kubernetes/manifests-multi:ro","/:/rootfs:ro"],"BlkioDeviceReadBps":null,"BlkioDeviceReadIOps":null,"BlkioDeviceWriteBps":null,"BlkioDeviceWriteIOps":null,"BlkioWeight":0,"BlkioWeightDevice":null,"CapAdd":null,"CapDrop":null,"CgroupParent":"","ConsoleSize":[0,0],"ContainerIDFile":"","CpuPeriod":0,"CpuQuota":0,"CpuShares":0,"CpusetCpus":"","CpusetMems":"","Devices":[],"Dns":[],"DnsOptions":[],"DnsSearch":[],"ExtraHosts":null,"GroupAdd":null,"IpcMode":"","Isolation":"","KernelMemory":0,"Links":null,"LogConfig":{"Config":{},"Type":""},"Memory":0,"MemoryReservation":0,"MemorySwap":0,"MemorySwappiness":-1,"NetworkMode":"host","OomKillDisable":false,"OomScoreAdj":0,"PidMode":"host","PidsLimit":0,"PortBindings":{},"Privileged":true,"PublishAllPorts":false,"ReadonlyRootfs":false,"RestartPolicy":{"MaximumRetryCount":0,"Name":"always"},"SecurityOpt":null,"ShmSize":0,"UTSMode":"","Ulimits":null,"VolumeDriver":"","VolumesFrom":null},"Hostname":"","Image":"gcr.io/google_containers/hyperkube:v1.1.8","Labels":{},"NetworkingConfig":{"EndpointsConfig":{}},"OnBuild":null,"OpenStdin":false,"StdinOnce":false,"StopSignal":"SIGTERM","Tty":false,"User":"","Volumes":{},"WorkingDir":""}
ERRO[0173] Couldn't run auplink before unmount: exit status 22
ERRO[0173] Clean up Error! Cannot destroy container 482957f3e4e92a0ba56d4787449daa5a8708f3b77efe0c603605f35d02057566: nosuchcontainer: No such container: 482957f3e4e92a0ba56d4787449daa5a8708f3b77efe0c603605f35d02057566
ERRO[0173] Handler for POST /v1.22/containers/create returned error: error creating aufs mount to /var/lib/docker/aufs/mnt/f9609c0229baa2cdc6bc07c36970ef4f192431c1b1976766b3ea23d72c355df3-init: invalid argument

有谁知道我的方法是否正确？ 为何删除这些文件夹后会发生问题？

我打开＃31012至少确保我们在任何情况下都不会泄漏这些污物。
我们当然还需要查看导致busy错误的各种原因

只要我记得，这一直在咬我。 几天前当我切换到overlay2驱动程序并完全覆盖aufs文件夹时，我得到了与上述几乎相同的结果（ docker system df说1.5Gigs， df说15Gigs） 。

我有大约1T的差异使用存储。 重新启动docker守护程序后-我恢复了约700GB。 所以我想停止守护进程会修剪这些吗？

不幸的是，重新启动对我没有任何帮助。

服务重新启动没有帮助。 这是一个严重的问题。 删除所有容器/图像不会删除那些差异。

停止守护程序不会修剪这些内容。

如果删除所有容器，但仍然有diff dirs，则可能是您泄漏了一些rw层。

我们刚刚遇到了这个问题。 /var/lib/docker/aufs/diff占用了28G的空间，并使我们的根文件系统达到100％，这导致我们的GitLab服务器停止响应。 我们将docker用于GitLab CI。 为了解决这个问题，我使用了上面建议的一些命令@sogetimaitral来删除临时文件，我们正在备份并运行。 我重新启动服务器，并发送了新的提交来触发CI，一切似乎都按预期运行。

我绝对担心这会再次发生。 这是怎么回事？ 这是需要修复的Docker错误吗？

1. 是的，有一个错误（都存在删除问题，并且--rm的--force忽略了这些问题）
2. 通常，不应将大量数据写入容器fs，而应使用一个卷（甚至是一次性卷）。 diff dir较大将表明有大量数据正在写入容器fs。

如果您不使用“ --force”进行删除，则不会遇到此问题（或者至少会看到您有一堆“死”容器，并且知道如何清理）。

我根本没有手动使用docker。 我们正在使用gitlab-ci-multi-runner 。 那可能是GitLab末期的错误吗？

看起来（默认情况下）它会强制删除容器； https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/dbdbce2848530df299836768c8ea01e209a2fe40/executors/docker/executor_docker.go#L878。 这样做可能导致无法删除被忽略的容器，并导致孤立的差异。

好的，那告诉我这是一个gitlab-ci-multi-runner错误。 这是正确的解释吗？ 我很乐意为他们解决这个问题。

我猜这是一个组合。 使用“ force”删除可以更轻松地进行清理（例如，容器尚未停止的情况等），同时（也就是提到的“ bug” @ cpuguy83 ），它也可以隐藏实际的问题，例如docker无法删除容器文件系统（可能有多种原因）。 在这种情况下，用“力”将容器取下。 如果没有，则将容器留在周围（但标记为“已死”）

如果gitlab运行程序可以在不移除力的情况下正常运行，那么更改（或使其可配置）可能会很好

我正在使用Drone并遇到相同的问题。 我没有检查代码如何删除容器，但是我猜想它也会强制删除。

可能是Docker问题中的Docker吗？ 我从docker-compose开始了Drone。

我决定继续提交gitlab-ci-multi-runner问题，以循环开发人员： https ://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

老实说，我们通过使用无人机CI运行Spotify的docker gc来解决此问题。

El El mar，3月。 2017年2月28日下午3:38，Geoffrey Fairchild <
[email protected]>escribió：

我决定继续提交gitlab-ci-multi-runner问题，目的只是为了
循环开发人员：
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/docker/docker/issues/22207#issuecomment-289926298 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AC6Wz197zkjWWOlq1-JOibiQP-xJym9Eks5rqYvegaJpZM4IMGt2
。

@sedouard感谢您的提示！ 从Spotify每小时运行docker-gc为我解决了这个问题。

我们正在使用命令构建映像/运行容器（不是Gitlab CI Docker集成）从Gitlab CI（不在docker中运行）运行此问题。 我们没有执行任何形式的强制撤除，只是docker run --rm ...和docker rmi image:tag

编辑：对不起，实际上原来的问题是相同的。 区别在于运行spotify/docker-gc不会_解决问题。

如下所示，我有0张图片，0个容器，一无所有！
docker system info同意我的观点，但提到Dirs: 38用于aufs存储。

那是可疑的！ 如果您查看/var/lib/docker/aufs/diff/ ，我们看到那里实际上有1.7 GB的数据，超过41个目录。 那是我的个人邮箱，在生产服务器上是19 GB。

我们该如何清洁呢？ 使用spotify/docker-gc不会删除这些。

philippe@pv-desktop:~$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

philippe@pv-desktop:~$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

philippe@pv-desktop:~$ docker system info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 38
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-72-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 31.34 GiB
Name: pv-desktop
ID: 2U5D:CRHS:RUQK:YSJX:ZTRS:HYMV:HO6Q:FDKE:R6PK:HMUN:2EOI:RUWO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: silex
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

philippe@pv-desktop:~$ ls -alh /var/lib/docker/aufs/diff/
total 276K
drwxr-xr-x 40 root root 116K Apr 13 15:32 .
drwxr-xr-x  5 root root 4.0K Sep 18  2015 ..
drwxr-xr-x  4 root root 4.0K Jun 17  2016 005d00efb0ba949d627ad439aec8c268b5d55759f6e92e51d7828c12e3817147
drwxr-xr-x  8 root root 4.0K May  2  2016 0968e52874bbfaa938ffc869cef1c5b78e2d4f7a670e19ef47f713868b9bfbdf
drwxr-xr-x  4 root root 4.0K Jun 20  2016 188233e6dcc37e2308e69807ffd19aca3e61be367daae921f2bcb15a1d6237d0
drwxr-xr-x  6 root root 4.0K Jun 20  2016 188233e6dcc37e2308e69807ffd19aca3e61be367daae921f2bcb15a1d6237d0-init
drwxr-xr-x 21 root root 4.0K Apr  8  2016 250ecb97108a6d8a8c41f9d2eb61389a228c95f980575e95ee61f9e8629d5180
drwxr-xr-x  2 root root 4.0K Dec 22  2015 291f16f99d9b0bc05100e463dbc007ef816e0cf17b85d20cf51da5eb2b866810
drwxr-xr-x  2 root root 4.0K May  2  2016 3054baaa0b4a7b52da2d25170e9ce4865967f899bdf6d444b571e57be141b712
drwxr-xr-x  2 root root 4.0K Feb  5  2016 369aca82a5c05d17006b9dca3bf92d1de7d39d7cd908ed665ef181649525464e
drwxr-xr-x  3 root root 4.0K Jun 17  2016 3835a1d1dfe755d9d1ada6933a0ea7a4943caf8f3d96eb3d79c8de7ce25954d2
(...strip)

philippe@pv-desktop:~$ du -hs /var/lib/docker/aufs/diff/
1.7G    /var/lib/docker/aufs/diff/

philippe@pv-desktop:~$ docker system prune -a
WARNING! This will remove:
    - all stopped containers
    - all volumes not used by at least one container
    - all networks not used by at least one container
    - all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0 B

我可以安全地rm -r /var/lib/docker/aufs并重新启动docker deamon吗？

运行spotify/docker-gc不会清除这些孤儿。

编辑：谢谢@CVTJNII！

停止Docker守护程序并删除所有/ var / lib / docker会更安全。 删除/ var / lib / docker / aufs仍然会导致丢失映像，所以我认为最好从干净的/ var / lib / docker开始。 这是我几个月来一直在解决此问题的“解决方案”。

从17.06开始，不再有任何新的孤立差异。
取而代之的是，您可能会开始看到状态Dead容器，如果在删除过程中出现无法恢复的错误，并且可能需要管理员处理，就会发生这种情况。

此外，删除操作更可靠，并且由于竞争状况或卸载失败而更容易出错。

@ cpuguy83 ：好消息，您能解释一下如果发生这种情况管理员需要做什么？

@Silex取决于原因。
通常发生的是由于某些装入泄漏到容器中而导致device or resource busy错误。 如果您运行的是cadvisor之类的东西，则这完全可以保证，如说明所示，将整个docker dir安装到cadvisor容器中。

这可能很棘手，您可能必须停止有问题的容器，然后删除dead容器。

如果您使用的是较新的内核（3.15及更高版本），尽管仍然可能存在某些情况，但您不太可能再看到此问题。

Docker版本17.06.0-ce，内部版本02c1d87

我尝试删除所有映像，卷，网络和容器，但没有帮助。
也尝试过的命令：

docker system prune -af
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc:ro spotify/docker-gc

仍保留文件：

root<strong i="11">@Dark</strong>:/var/lib/docker/aufs# ls -la *
diff:
total 92
drwx------ 12 root root 45056 Jul 28 17:28 .
drwx------  5 root root  4096 Jul  9 00:18 ..
drwxr-xr-x  4 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
drwxr-xr-x  6 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
drwxr-xr-x  5 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
drwxr-xr-x  6 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
drwxr-xr-x  4 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
drwxr-xr-x  6 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
drwxr-xr-x  4 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
drwxr-xr-x  6 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
drwxr-xr-x  6 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
drwxr-xr-x  6 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

layers:
total 52
drwx------ 2 root root 45056 Jul 28 17:28 .
drwx------ 5 root root  4096 Jul  9 00:18 ..
-rw-r--r-- 1 root root     0 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
-rw-r--r-- 1 root root     0 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
-rw-r--r-- 1 root root     0 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
-rw-r--r-- 1 root root     0 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
-rw-r--r-- 1 root root     0 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
-rw-r--r-- 1 root root     0 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
-rw-r--r-- 1 root root     0 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

mnt:
total 92
drwx------ 12 root root 45056 Jul 28 17:28 .
drwx------  5 root root  4096 Jul  9 00:18 ..
drwxr-xr-x  2 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
drwxr-xr-x  2 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
drwxr-xr-x  2 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
drwxr-xr-x  2 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
drwxr-xr-x  2 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
drwxr-xr-x  2 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
drwxr-xr-x  2 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              0                   0                   0B                  0B
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

如何删除？

@ haos616尝试先停止所有正在运行的容器，然后再运行docker system prune -af 。
这帮了我大忙。
我有一个容器在运行时没有工作。

如果是从先前版本的Docker升级而来，则这些差异可能是由该版本生成的/遗留下来的。 如果无法删除图层（使用--force时），则Docker 17.06不会删除容器； 较旧的版本确实存在，这可能会导致孤立的图层

@ julian-pani我一开始是这样做的，但没有帮助。

# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              0                   0                   0B                  0B
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

@thaJeztah不。我在一两个月前清理了Docker。 那时版本已经是17.06。 我使用命令docker system prune -af 。 它删除了所有内容。

将https://github.com/spotify/docker-gc作为容器运行对我来说很有效，但这又走了一步，并且删除了一些我需要的图像:(

因此，为了安全起见，我放置了一个小的包装脚本，如下所示

#!/bin/sh
docker images -q > /etc/docker-gc-exclude    # Save all genuine images as exclude
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc:ro spotify/docker-gc

再次感谢您发现

IIUC，spotify脚本仅调用docker rm和docker rmi -它实际上删除了孤立的差异吗？

我已经阅读了所有有关社区的反馈，而实际上没有一种解决方案似乎始终如一或可靠。 我的“解决方案”只是使我的AWS实例上的磁盘空间增加一倍。 而且我非常清楚这是一个糟糕的修补程序，但这是我发现的针对Docker膨胀的auf的最佳解决方法。 这确实非常需要修复。

@fuzzygroup 17.06应该不再创建孤立的差异，但仍不能清除旧的差异。

我可以使用此脚本进行清理。 我不知道为什么它不起作用，但是谁知道。
无论如何，这对我来说很好。 它将删除所有图像，容器和卷...因为它不应该经常运行，所以我发现它的副作用很小。 但是，是否使用它取决于您。

https://gist.github.com/Karreg/84206b9711cbc6d0fbbe77a57f705979

https://stackoverflow.com/q/45798076/562769似乎相关。 我已经发布了快速修复。

仅供参考，仍然可以看到17.06.1-ce

Containers: 20
 Running: 0
 Paused: 0
 Stopped: 20
Images: 124
Server Version: 17.06.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 185
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
 apparmor
Kernel Version: 4.4.0-83-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.796GiB
Name: gitlab-cirunner
ID: PWLR:R6HF:MK3Y:KN5A:AWRV:KHFY:F36D:WASF:7K7B:U7FY:2DJA:DBE2
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

/var/lib/docker/aufs/diff包含许多带有-init-removing和-removing前缀的目录：

ffd5477de24b0d9993724e40175185038a62250861516030a33280898243e742-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-init-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-removing

仅供参考，仍然会在17.06.1-ce中看到这一点

还在看什么，到底是什么？
diff目录不能有任何泄漏的可能，尽管diff dirs如果在升级时存在，则仍然存在，但它们仍将存在。

据我所知，仍然看到孤立的差异。 docker system prune并未删除它们，也没有删除docker-gc 。 手动运行rm -rf /var/lib/docker/aufs/diff/*-removing似乎有效。

是的，码头工人还不会清理旧的孤零零的东西。

旧时，您是指那些从早期版本的Docker创建的带有此问题的文件吗？

这是我们大约两周前完成的Docker的全新安装，那些孤儿一定是从那时起创建的，所以看来Docker仍必须在创建那些孤儿吗？

我的意思是，在过去的半小时内，我用-removing获得了112新差异，因为我手动对其进行了修改。

$ ls /var/lib/docker/aufs/diff/ | grep removing | wc -l
112

您说“ 17.06应该不再创建孤立的差异文件，但是它还不能清除旧的差异文件。”但是，这肯定是不正确的，还是我丢失了某些东西？ 那些标有-removing不是孤儿吗？

@orf在较新的内核上，在删除过程中根本没有任何问题是非常出乎意料的。 您要在容器中装入/var/lib/docker吗？

我将检查aufs驱动程序，查看是否存在特定问题，如果确实没有，则报告成功删除。

我们没有将/var/lib/docker装入容器。

$ uname -a
Linux gitlab-cirunner 4.4.0-83-generic #106~14.04.1-Ubuntu SMP Mon Jun 26 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

我们正在运行14.04 LTS

让我知道是否有什么可以帮助您调试的。

由于其他原因（群模式网络），我从Docker迁移到14.04
机器。
在2017年8月21日星期一上午8：23，orf [email protected]写道：

我们没有将/ var / lib / docker挂载到容器中。

$ uname -a
Linux gitlab-cirunner 4.4.0-83-generic＃106〜14.04.1-Ubuntu SMP Mon Jun 26 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU / Linux

我们正在运行14.04 LTS

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/moby/moby/issues/22207#issuecomment-323773033或静音
线程
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
。

对于17.06.01-ce，情况似乎更糟。 我将构建机器更新到此版本，并立即开始看到*-init-removing和*-removing目录留在构建过程中。 我停止了该服务，删除了/var/lib/docker目录，重新启动了该服务，并且在一些构建再次接近磁盘空间不足之后。 我再次停止了该服务，运行apt-get purge docker-ce ，再次删除了/var/lib/docker并安装了17.06.0-ce版本。 没有在/var/lib/docker/aufs/diff和磁盘空间中获得多余的目录代表了构建机器上的映像。 我也已经在开发机器上重现了这种行为-只是构建映像似乎为映像的每一层创建了这些额外的目录，所以我会很快用完磁盘空间。 同样，恢复到17.06.0-ce似乎没有问题，所以我现在待在那儿。

@mmanderson感谢您的举报。 看一下AUFS驱动程序中的更改。

@mmanderson您是否在docker ps -a中有处于Dead状态的容器？

我所有的Docker构建服务器的空间都已耗尽。

我在过去一周左右的时间内已升级到Docker版本17.06.1-ce，内部版本874a737。 我相信没有其他改变，并且这个问题在升级过程中已经出现或表现出来。 aufs diff目录很大，我已经修剪了所有映像并悬挂了卷。

issue-22207.txt
@ cpuguy83在任何状态下

1. 从在Ubuntu 16.04.03 LTS上全新安装docker 17.06.01-ce开始（即未安装docker且没有/ var / lib / docker目录）。 安装后，请验证一个空的/ var / lib / docker / aufs / diff目录。
2. 使用基于ubuntu：latest的相当简单的dockerfile运行一个docker构建-它所做的只是从github中提取statsd_exporter并将其解压缩到/ usr / bin中（请参见附件）。
3. 运行构建后，运行docker ps -a以显示任何状态的容器。 有几个*-remaining的文件夹/var/lib/docker/aufs/diff文件夹中。
4. 运行docker system df以验证图像，容器和卷。 结果是

TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              2                   0                   132.7MB             132.7MB (100%)
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

1. 运行du -sch /var/lib/docker/*/显示152M的价格为/var/lib/docker/aufs/
2. 运行docker rmi $(docker images -q)删除构建的图像层。 在此之后运行docker system df显示所有零。 运行du -sch /var/lib/docker/*/显示152M为/var/lib/docker/aufs/并有*-remaining的所有文件夹的文件夹，与现有的沿之前没有他们*-remaining文件夹是还在那里

@erikh这是您遇到的问题吗？

@ cpuguy83卸载17.06.01-ce后，删除/ var / lib / docker目录并安装17.06.0-ce，我尝试运行相同的构建。 由于ADD from remote URL's错误已在17.06.01中修复，因此构建失败。 但是我没有得到任何*-remaining目录来完成步骤，并且在用docker system prune和docker rmi $(docker image -q)清理所有内容之后， /var/lib/docker/aufs/diff目录再次为空。并释放了空间。

谢谢，这是17.06.1中的回归...
公关要修复在这里： https :

太棒了，感谢快速补丁@ cpuguy83！ / cc @erikh

@rogaha！ 是的，谢谢你和@ cpuguy83！

非常感谢@Karreg的出色脚本。 在摆脱了所有旧有的差异并释放了大量丢失的磁盘空间之后，我们现在定期使用它来清理虚拟机，然后再安装新的Docker映像。 对于此问题，现在提供了很大的帮助和几乎完美的解决方法。 @ TP75

看起来Docker，Inc.与计算机数据存储制造商签订了一些合同。

@Karreg的脚本对我来说很好用，我释放了diffs目录中的所有空间。

有同样的问题。
Docker主机详细信息

root @ UbuntuCont ：〜＃码头工人信息
货柜：3
跑步：0
已暂停：0
已停止：3
图片：4
服务器版本：17.06.1-ce
存储驱动程序：aufs
根目录：/ var / lib / docker / aufs
支持文件系统：extfs
异常：14
Dirperm1支持：true
记录驱动程序：json-file
Cgroup驱动程序：cgroupfs
外挂程式：
数量：本地
网络：网桥主机macvlan空覆盖
日志：awslogs流利的gcplogs gelf记录日志的json文件日志条目splunk syslog
群：不活动
运行时：runc
默认运行时：runc
初始化二进制文件：docker-init
容器版本：6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc版本：810190ceaa507aa2727d7ae6f4790c76ec150bd2
初始版本：949e6fa
安全选项：
装甲兵
seccomp
个人资料：默认
内核版本：4.4.0-93-通用
作业系统：Ubuntu 16.04.3 LTS
操作系统类型：linux
架构：x86_64
CPU：1
记忆体总容量：3.358GiB
名称：UbuntuCont
ID：QQA5：DC5S：C2FL：LCC6：XY6E：V3FR：TRW3： VMOQ：QQKD ：AP2M：H3JA：I6VX
Docker根目录：/ var / lib / docker
调试模式（客户端）：false
调试模式（服务器）：false
注册表： https ：
实验性：错误
不安全的注册表：
127.0.0.0/8
启用实时还原：false

root @ UbuntuCont ：/ var / lib /
031c85352fe85f07fede77dee0ac9dc2c7723177a819e72c534e1399208c95fa
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d-init
0fb1ffc90969e9706801e2a18870f3ecd857a58f1094fbb968b3fa873e4cf2e4
10549179bd21a9c7af018d4ef305bb9196413b9662fce333b607104c40f38781
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c-init-removing
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c移除
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606-init
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da-init-removing
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da-removing
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c-init-removing
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c-removing
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5-init-removing
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5-删除
59cbb25a4858e7d3eb9146d64ff7602c9abc68509b8f2ccfe3be76681481904f
5d1c661b452efce22fe4e109fad7a672e755c64f538375fda21c23d49e2590f6
605893aba54feee92830d56b6ef1105a4d2166e71bd3b73a584b2afc83319591
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281-init-removing
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281移除
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779-init-removing
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779-removing
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26-init-removing
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26-正在移除
a72735551217bb1ad01b77dbdbb9b8effa9f41315b0c481f8d74b5606c50deb4
aa58f2000b9f7d1ed2a6b476740c292c3c716e1d4dc04b7718580a490bba5ee8
b552cb853e33a8c758cb664aec70e2c4e85eacff180f56cbfab988a8e10c0174-正在移除
cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55-init-removing
删除cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2-init

@kasunsjc，请阅读您上方的帖子。

我确认升级到17.06.2-ce可以解决此问题。 升级后，我也不必手动（最后一次）目录。

17.06.2-ce _appears_也为我修复了此问题。 那里没有更多的-removing目录，回了相当大的空间。

我假设我在aufs/diff中拥有的-init目录是不相关的（其中一些已经很旧了）。 虽然它们都很小，所以没什么大不了的。

更新到17.07.0也可以解决此问题，即使docker system prune --all -f也不会在删除目录之前删除，但在升级后它们会在重新启动时自动删除。

确认此问题已在具有17.06.2-ce的Ubuntu 16.04上解决。 更新后，空间将立即清除。