我也有同样的问题，在我的实例中，这是因为' var/lib/docker '目录被挂载到一个运行的容器(在我的情况下谷歌/cadvisor)，因此它阻止了docker修剪清理文件夹。停止容器，运行docker prune -然后重新运行容器解决了问题。

也有快速增长的覆盖2的问题

/var/lib/docker/overlay2 -是docker存储容器可写层的文件夹。 只有当容器停止并删除时，Docker系统修剪-a才能工作。

在我的作品中，我能够通过研究overlay2来计算出什么占用了空间。

该文件夹包含其他命名为哈希的文件夹。每个都有几个文件夹，包括diff文件夹。

Diff文件夹——包含一个容器所写的实际差异，该容器具有与你的容器相同的文件夹结构(至少在我的情况下- ubuntu 18…)

所以我用du -hsc /var/lib/docker/overlay2/ longhashhhhhhh /diff/tmp来找出我的容器中的/tmp是被污染的文件夹。

因此，作为一个解决方案，我已经使用-v /tmp/container-data/tmp:/tmp参数为docker运行命令来映射内部/tmp文件夹到主机，并在主机上设置一个cron来清理该文件夹。

Cron任务很简单:

Sudo nano /etc/crontab */30 * * * * root rm -rf /tmp/container-data/tmp/* .使用实例 保存并退出

注意:overlay2是系统docker文件夹，他们可以随时改变它的结构。以上一切都是基于我在里面看到的。不得不进入docker文件夹结构，因为系统完全没有空间，甚至不允许我ssh进入docker容器。

docker system prune -af && docker image prune -af

我有这样的问题…那是一根巨大的木头。日志如下:

/var/lib/docker/containers/<container id>/<container id>-json.log

您可以在运行命令行或撰写文件中进行管理。参见:配置日志记录驱动程序

我个人将这3行添加到我的docker-compose中。Yml文件:

my_container:
  logging:
    options:
      max-size: 10m

也许这个文件夹不是你的问题，不要用docker的df -h的结果。 使用下面的命令查看每个文件夹的大小:

echo; pwd; echo; ls -AlhF; echo; du -h --max-depth=1; echo; du-sh

警告:不要在生产系统中使用

/# df
...
/dev/xvda1      51467016 39384516   9886300  80% /
...

好的，让我们先尝试系统修剪

#/ docker system prune --volumes
...
/# df
...
/dev/xvda1      51467016 38613596  10657220  79% /
...

不太好，好像清理了几兆。让我们疯狂起来吧:

/# sudo su
/# service docker stop
/# cd /var/lib/docker
/var/lib/docker# rm -rf *
/# service docker start
/var/lib/docker# df
...
/dev/xvda1      51467016 8086924  41183892  17% /
...

好了! 只需要记住，除了一次性服务器，不建议使用这种方法。此时，Docker的内部数据库将无法找到任何这些覆盖，这可能会导致意想不到的后果。