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

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

/# 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的内部数据库将无法找到任何这些覆盖，这可能会导致意想不到的后果。

朋友们，为了保持一切清洁，你可以使用命令:

docker system prune -a && docker volume prune

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

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

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

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

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

Docker显然为运行的容器保留了映像的旧版本的映像层。如果你更新运行中的容器的镜像(相同的标签)而没有停止它，可能会发生这种情况，例如:

docker-compose pull
docker-compose up -d

在更新之前运行docker-compose down解决了它，停机时间在我的情况下不是一个问题。

我导航到包含overlay2的文件夹。使用du -shc overlay2/*，我发现overlay2中有25G的垃圾。运行docker系统prune -af显示总回收空间:1.687MB，所以我认为它未能清理它。然而，我然后再次运行du -shc overlay2/*，只看到overlay2只有80K，所以它确实工作。

小心，docker撒谎:)。