Docker错误：设备上没有剩余空间

我以以下方式在Debian 7机器上安装了docker

$ echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list
$ sudo apt-get update
$ curl -sSL https://get.docker.com/ubuntu/ | sudo sh

之后，当我第一次尝试创建映像时，它失败并显示以下错误

 time="2015-06-02T14:26:37-04:00" level=info msg="[8] System error: write /sys/fs/cgroup/docker/01f5670fbee1f6687f58f3a943b1e1bdaec2630197fa4da1b19cc3db7e3d3883/cgroup.procs: no space left on device"

这是码头工人信息

Containers: 2
Images: 21
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 25
Dirperm1 Supported: true
Execution Driver: native-0.2
Kernel Version: 3.16.0-0.bpo.4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
CPUs: 2
 Total Memory: 15.7 GiB


WARNING: No memory limit support
 WARNING: No swap limit support

如何增加内存？系统配置存储在哪里？

根据Kal的建议：

当我删除所有图像和容器时，它确实释放了一些空间，并且在生成相同错误之前，图像构建运行了更长的时间。所以问题是，这是指哪个空间以及如何配置它？

我有同样的错误，并通过以下方式解决：

1。删除Docker中的孤立卷，可以使用内置的docker volume命令。内置命令还会删除/ var / lib / docker / volumes中不是卷的任何目录，因此请确保您未在​​其中保存任何要保存的目录。

如果您要保留一些数据，请谨慎使用此警告

清理：

$ docker volume rm $(docker volume ls -qf dangling=true)

附加命令：

列出悬空的体积：

$ docker volume ls -qf dangling=true

列出所有卷：

$ docker volume ls

2。还可以考虑删除所有未使用的图像。

首先删除<none>图像（有时会在构建图像时生成图像，并且由于某种原因，如果图像构建被中断，它们会停留在该位置）。

这是一个我用来删除它们的漂亮脚本

docker rmi $(docker images | grep '^<none>' | awk '{print $3}')

然后，如果您正在使用Docker Compose在本地为每个项目构建映像。您最终会得到很多通常以您的文件夹命名的图像（例如，如果您的项目文件夹名为Hello，您将找到图像名称Hello_blablabla）。所以也考虑删除所有这些图像

您可以编辑以上脚本以将其删除或使用以下命令手动将其删除

docker rmi {image-name}

更新
随着Docker的发展，以下命令已成为黑客。目前的最佳做法是

docker system prune

这将删除：

- all stopped containers
- all volumes not used by at least one container
- all networks not used by at least one container
- all dangling images

如下所示，这是核。

要清洁系统，请先卸下容器

$ docker rm $(docker ps -aq)

然后删除图像

$ docker rmi $(docker images -q)

这当然是核的，将删除所有容器和所有图像。您可以一次通过docker rm #CONTAINER_ID#和删除它们docker rmi #IMAGE_ID。

检查/ var上是否有可用空间，因为这是Docker默认存储映像文件的位置（在/ var / lib / docker中）。

首先使用docker ps -a列出所有容器（包括停止的容器）并docker rm删除它们来清理东西；然后使用docker images列出所有已存储的图像并将docker rmi其删除。

接下来，使用docker守护程序上的-g选项或通过编辑/etc/default/docker该-g选项并将其添加到来更改存储位置DOCKER_OPTS。-g指定“ Docker运行时”的位置，它基本上是Docker在构建映像和运行容器时创建的所有内容。选择一个有足够空间的位置，因为使用的磁盘空间会随着时间的流逝而增长。如果您进行编辑/etc/default/docker，则需要重新启动docker守护程序，以使更改生效。

现在，您应该能够创建一个新映像（或从Docker Hub中提取一个映像），并且应该看到在使用-g选项指定的目录中创建了一堆文件。

如前所述，

docker system prune

可以提供帮助，但是使用Docker 17.06.1及更高版本时不会修剪未使用的卷。从Docker 17.06.1开始，以下命令也修剪卷：

docker system prune --volumes

从Docker文档中：https : //docs.docker.com/config/pruning/

docker system prune命令是用于修剪映像，容器和网络的快捷方式。在Docker 17.06.0及更早版本中，还修剪了卷。在Docker 17.06.1及更高版本中，必须为docker system prune指定--volumes标志以修剪卷。

如果要修剪卷并保留图像和容器：

docker volume prune

如果这只是Docker的测试安装（即非生产），并且您不关心进行核清洁，则可以：

清洁所有容器： docker ps -a | sed '1 d' | awk '{print $1}' | xargs -L1 docker rm

清除所有图像： docker images -a | sed '1 d' | awk '{print $3}' | xargs -L1 docker rmi -f

同样，在开发Docker时，我在ec2实例中使用了它，而不是在任何认真的QA或生产路径中使用。很棒的事情是，如果您有自己的Dockerfile，则很容易重建和或docker pull。

一次删除所有未使用的容器，卷，网络和映像（https://docs.docker.com/engine/reference/commandline/system_prune/#related-commands）：

docker system prune -a -f --volumes

如果还不够，可以先删除正在运行的容器：

docker rm -f $(docker ps -a -q)
docker system prune -a -f --volumes

增加/ var / lib / docker或使用具有更多空间的其他位置也是摆脱此错误的不错选择（请参阅如何更改docker映像安装目录？）

Mac版Docker

因此，docker system prune并docker system prune --volumes在其他答案中建议每次都释放一些空间，但是最终每次我执行任何操作时，我都会得到错误。

真正解决了根本问题的是删除Docker.rawDocker for Mac用于存储的文件，然后重新启动它。

要找到该文件，请打开适用于Mac的Docker并转到*

Preferences > Resources > Advanced > Disk Image Location

*这是针对版本2.2.0.5的，但在较旧的版本上应该类似

在Mac **的较新版本的Docker上，它会在UI中显示磁盘上该文件的实际大小以及最大分配大小。您可能会看到它很大。例如，在我的机器上是41GB！

**在旧版本中，它不会在UI中显示您的实际磁盘使用情况，而MacOS Finder 始终将文件大小显示为最大分配大小。您可以通过在终端中打开目录并运行来检查磁盘上的实际大小du -h Docker.raw

我删除Docker.raw了Mac的Docker并重新启动，然后再次自动创建了该文件，并恢复为0GB。

尽管我当然失去了Docker缓存，但一切仍然照旧工作。不出所料，在运行了几个Docker命令之后，该文件开始再次充满了几GB的内容，但远不及 41GB。

更新资料

_{几个月后，我Docker.raw又重新填充到类似的大小。因此，此方法确实有效，但必须每隔几个月重复一次。对我来说很好。}

_{关于它为何有效的说明-我必须假定这是Docker for Mac中的错误。看起来docker system prune/ 确实docker system prune --volumes应该完全清除此文件的内容，但似乎该文件会累积其他不能由这些命令删除的内容。无论如何，手动删除它可以解决问题！}

Docker留下了晃来晃去的图像，这可能会占用您的空间。要在Docker之后进行清理，请运行以下命令：

docker image prune [-af if you want to force remove all images]

或旧版Docker：

docker rm $(docker ps -q -f 'status=exited')
docker rmi $(docker images -q -f "dangling=true")

这将删除现有的和悬空的图像，从而有望清除设备空间。

1. 清洁悬挂的图像 docker rmi $(docker images -f "dangling=true" -q)
2. 删除不需要的卷
3. 删除未使用的图像
4. 取出未使用的容器

您还可以使用：

docker system prune

或仅用于数量：

docker volume prune

就我而言，安装ubuntu-server 18.04.1（出于某些奇怪的原因）创建了一个LVM逻辑卷，其大小仅为4GB，而不是750GB。因此，当我拉图像时，我会得到这个“设备上没有剩余空间”的错误。解决方法很简单：

lvextend -l 100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

我还在RHEL机器上遇到此问题。我在堆栈溢出和docker-hub社区的任何地方都找不到合适的解决方案。如果即使在执行以下命令后仍遇到此问题：

docker系统修剪--all

最终起作用的解决方案：

1. 码头工人信息
   • 检查当前的Docker存储驱动程序
   • 我的是：存储驱动程序：devicemapper; 如果将存储驱动程序作为overlay2，则无需担心。解决方案仍然适用于您。
2. df -h
   • 这是为了检查计算机上可用的文件系统以及它们的安装路径。两条安装路径要注意：
   • / dev / mapper / rootvg-var 7.6G 1.2G 6.1G 16％/ var
   • / dev / mapper / rootvg-apps 60G 9.2G 48G 17％/ apps
   • 注 -默认情况下，docker存储路径为/ var / lib / docker。它具有约6 GB的可用空间，因此存在所有与空间有关的问题。因此，基本上，我必须将默认存储移动到可用空间更多的其他存储中。对我来说，它的文件系统路径'/ dev / mapper / rootvg-apps'安装在/ apps上。现在的任务是将/ var / lib / docker移至/ apps / newdocker / docker之类的位置。
3. mkdir / apps / newdocker / docker
4. chmod -R 777 / apps / newdocker / docker
5. 在Linux上更新docker.serive文件，该文件位于/ usr / lib / systemd / system下
   • vi /usr/lib/systemd/system/docker.service
6. 如果存储设备是devicemapper，请注释现有的ExecStart行，并在[Service]下添加以下内容：
   • ExecStart =
   • ExecStart = / usr / bin / dockerd -s devicemapper-存储选择dm.fs = xfs-存储选择dm.basesize = 40GB -g / apps / newdocker / docker --exec-opt native.cgroupdriver = cgroupfs
7. 或者，如果存储设备为overlay2：
   • 只需在现有ExexStart语句中添加-g / apps / newdocker / docker。
   • 像ExecStart = / usr / bin / dockerd -g / apps / newdocker / docker -H fd：// --containerd = / run / containerd / containerd.sock之类的东西
8. rm -rf / var / lib / docker（它将删除所有现有的docker数据）
9. systemctl停止docker
10. ps aux | grep -i泊坞窗| grep -v grep
    • 如果以上命令未产生任何输出，请通过以下命令重新加载systemd守护程序。
11. systemctl守护程序重新加载
12. systemctl启动docker
13. 码头工人信息
    • 在将docker迁移到新文件系统后，签出可用数据空间：62.15GB。
14. 完成

使用以下命令清理Docker：

docker images --no-trunc | grep '<none>' | awk '{ print $3 }' \
| xargs docker rmi

您的cgroup cpuset启用了控制器。该控制器在NUMA环境中最有用，它可以精确地指定允许您的任务运行的CPU /内存库。

默认情况下，没有设置必填项cpuset.mems和cpuset.cpus，这意味着您的任务没有“剩余空间”，因此会出现错误。

解决此问题的最简单方法是cgroup.clone_children在根cgroup中将其启用为1。就您而言，应该是

echo 1 > /sys/fs/cgroup/docker/cgroup.clone_children

它会在系统基本上指示自动初始化容器的cpuset.mems，并cpuset.cpus从其父cgroup中。

如果您通过Docker Toolkit使用boot2docker映像，则问题源于boot2docker虚拟机空间不足的事实。

当您执行docker import或添加新图像时，该图像将被复制到/mnt/sda1其中可能已满的图像中。

检查映像中有哪些可用空间的一种方法是，将ssh放入vm并运行df -h并检查/ mnt / sda1中的剩余空间。

ssh命令是 docker-machine ssh default

一旦确定确实存在空间问题，就可以根据此问题的一些答案中的说明进行清理，或者可以选择通过增加boot2docker映像本身的大小来调整其大小。 /mnt/sda1

您可以按照此处的说明调整图像的大小 https://gist.github.com/joost/a7cfa7b741d9d39c1307

如果您使用的是Docker Desktop，则可以转到Docker的Preferences，在Advanced Settings中增加Disk image大小。

这是macOS的屏幕截图：

可能是由于默认存储空间设置为40GB（默认路径为/ var / lib / docker）

您可以更改存储量以指向不同的路径

• 编辑文件-> / etc / sysconfig / docker-storage
• 更新以下行（如果不存在则添加）

DOCKER_STORAGE_OPTIONS ='-存储驱动程序=覆盖--graph = CUSTOM_PATH'

• 重新启动docker systemctl停止docker systemctl守护进程重新加载systemctl启动docker

如果您运行命令docker info（它应该将存储驱动程序显示为覆盖）

似乎有几种方法可以发生这种情况。我遇到的问题是docker磁盘映像已达到其最大大小（如果要查看OSX中的大小，则为Docker Whale-> Preferences-> Disk）。

我提高了限制，很高兴去。我敢肯定，清理未使用的图像也可以。

我运行以下命令。

之后无需重建图像。

docker rm $(docker ps -qf 'status=exited')
docker rmi $(docker images -qf "dangling=true")
docker volume rm $(docker volume ls -qf dangling=true)

这些将删除退出的/悬挂的容器和悬挂的体积。

对我来说docker system prune，绝招。我正在运行Mac OS。

$ docker rm $(docker ps -aq)

这对我有用

docker system prune 

最新版本似乎是更好的选择