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"

这是docker信息

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

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

以下是卡尔的建议:

当我摆脱了所有的图像和容器,它确实释放了一些空间和图像构建运行更长的时间之前失败与相同的错误。问题是,这指的是哪个空间我怎么配置它?

574068 次浏览

检查/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选项指定的目录中创建了一堆文件。

你的cgroups已经启用了cpuset控制器。这个控制器在NUMA环境中非常有用,它允许精细地指定允许运行哪个CPU/内存库的任务。

默认情况下,强制的cpuset.memscpuset.cpus没有设置,这意味着“没有空间留给”您的任务,因此出现错误。

解决这个问题最简单的方法是在根组中启用cgroup.clone_children到1。对你来说,应该是

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

它基本上会指示系统从容器的父cgroup中自动初始化容器的cpuset.memscpuset.cpus

如果它只是Docker的测试安装(即不是生产),并且你不关心做核清洁,你可以:

清洁所有容器 # EYZ0 < / p >

清除所有图像: # EYZ0 < / p >

同样,我在开发Docker的ec2实例中使用了这个方法,而不是在任何严肃的QA或生产路径中使用。最好的事情是,如果你有Dockerfile(s),它很容易重建或docker pull

目前的最佳实践是:

docker system prune

在接受结果之前,请注意该命令的输出:

WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache


Are you sure you want to continue? [y/N]

换句话说,继续执行这个命令是永久的。请记住,最佳实践是对待停止的容器是短暂的,即你应该用Docker设计你的工作,不要在周围保留这些停止的容器。如果不主动调试容器,可以考虑在运行时使用# EYZ0国旗

请务必阅读这个答案, re: Volumes

如果docker system prune不适合您,您可能还对这个答案感兴趣。

我也犯了同样的错误,用这种方法来解决:

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 | awk '/^<none>/ {print $3}')

然后,如果你使用Docker Compose为每个项目在本地构建图像。你最终会得到很多图片,通常和你的文件夹一样命名(例如,如果你的项目文件夹名为Hello,你会发现图片名称为Hello_blablabla)。所以也要考虑删除所有这些图片

您可以编辑上面的脚本以删除它们或手动使用

# EYZ0

使用以下命令清洁Docker:

docker images --no-trunc | awk '/<none>/ { print $3 }' \
| xargs docker rmi
  1. 清洁悬挂图像docker rmi $(docker images -f "dangling=true" -q)
  2. 删除不需要的卷
  3. 删除未使用的图像
  4. 移除未使用的容器

立即删除所有未使用的容器、卷、网络和映像(https://docs.docker.com/engine/reference/commandline/system_prune/):

docker system prune -a -f --volumes

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

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

增加/var/lib/docker或使用其他有更大空间的位置也是消除此错误的好选择(参见如何更改docker镜像安装目录?)

你还可以使用:

docker system prune

或者仅为卷:

docker volume prune

如果您通过Docker Toolkit使用boot2docker映像,那么问题源于boot2docker虚拟机已耗尽空间。

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

检查映像中可用空间的一种方法是ssh进入虚拟机并运行df -h并检查/mnt/sda1中的剩余空间

ssh命令为 # EYZ0 < / p >

一旦您确定这确实是一个空间问题,您可以根据这个问题的一些答案中的说明进行清理,或者您可以选择通过增加/mnt/sda1上的空间来调整boot2docker映像本身的大小

你可以按照这里的说明来调整图像的大小 # EYZ0 < / p >

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")

这将删除退出和悬空的图像,这有望清除设备空间。

似乎有几种方式可以发生这种情况。我遇到的问题是,docker磁盘映像已经达到其最大大小(docker Whale -> Preferences -> disk,如果你想查看它在OSX中的大小)。

我提高了极限,然后就可以出发了。我相信清理未使用的图像也会起作用。

在我的案例中,安装ubuntu服务器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社区中,我没有找到任何合适的解决方案。 如果您在执行以下命令后仍面临此问题:

. 0

Docker系统全部修剪

最终奏效的解决方案:

    <李>码头工人信息
    • 查看当前的docker存储驱动程序
    • 我的是:存储驱动程序:设备映射器;如果你有存储驱动作为overlay2没有什么可担心的。解决方案仍然对你有效。
    • 李< / ul > < / > <李> df - h
      • 这是检查机器上可用的文件系统和它们被挂载的路径。 两个挂载路径要注意:
      • /dev/mapper/rootvg-var 7.6G 1.2G 6.1G 16% / var
      • /dev/mapper/rootvg-apps 60G 9.2G 48G 17% /应用程序
      • 请注意- docker默认存储路径为/var/lib/docker。它有可用空间~6 GB,因此所有空间相关的问题。所以基本上,我必须将默认存储转移到其他可用空间更大的存储。对我来说,它的文件系统路径是“/dev/mapper/rootvg-apps”,挂载在/apps上。现在的任务是将/var/lib/docker移动到/apps/newdocker/docker。
      • 李< / ul > < / >
      • mkdir /应用程序/ newdocker /码头工人
      • chmod -R 777 /apps/newdocker/docker
      • <李>更新码头工人。Linux上的Serive文件,位于/usr/lib/systemd/system目录下
        • vi /usr/lib/systemd/system/docker.service
        • 李< / ul > < / >
        • 如果存储设备是devicemapper,注释现有的ExecStart行并在[Service]下添加以下内容:
          • ExecStart =
          • ExecStart=/usr/bin/dockerd -s devicemapper——storage-opt dm.fs=xfs——storage-opt dm.basesize=40GB -g /apps/newdocker/docker——execute -opt native.cgroupdriver=cgroupfs . txt
          • 李< / ul > < / >
          • 或者存储设备覆盖2:
            • 只需在现有的ExexStart语句中添加-g /apps/newdocker/docker即可。
            • 比如ExecStart=/usr/bin/dockerd -g /apps/newdocker/docker -H fd://——containerd=/run/containerd/containerd.sock
            • 李< / ul > < / >
            • 删除docker的所有数据
            • Systemctl stop docker
            • ps aux | grep -i docker | grep -v grep
              • 如果上面的命令没有输出,那么使用下面的命令重新加载systemd daemon。
              • 李< / ul > < / >
              • systemctl daemon-reload
              • Systemctl start docker
              • <李>码头工人信息
                • 检查可用的数据空间:挂载到docker到新文件系统后的62.15GB。
                • 李< / ul > < / >
                • 完成

如前所述,

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系统剪枝指定——volumes标志来剪枝卷。

如果你想修剪卷并保留图像和容器:

docker volume prune

我运行以下命令。

之后不需要重新构建图像。

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操作系统。

Docker for Mac

因此,在其他答案中建议的docker system prunedocker system prune --volumes每次都释放了一些空间,但最终每次我运行任何东西都得到错误。

到底是什么解决了根本问题正在删除Docker for Mac用于存储的Docker.raw文件,并重新启动它。

要找到这个文件,打开Docker for Mac,然后转到*

Preferences > Resources > Advanced > Disk Image Location

*这是2.2.0.5版本,但在旧版本上应该是类似的

在新版本的Docker for Mac**上,它会在UI中显示该文件在磁盘上的实际大小,以及它的最大分配大小。你可能会看到它是巨大的。例如,在我的机器上它是41 gb!

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

我删除了Docker.raw,重新启动Mac的Docker,文件被自动重新创建,并回到了0 gb

一切照常运转,当然我已经丢失了Docker缓存。正如预期的那样,在运行了一些Docker命令后,文件又开始被一些GB的东西填满,但是附近的地方 41GB。


更新

< p > <子> 几个月后,我的Docker.raw再次填充到类似的大小。所以这个方法确实有效,但必须每隔几个月重复一次。对我来说这很好。 < / sub > < / p > < p > <子> 关于为什么这样工作的说明-我不得不假设这是Mac Docker中的一个bug。看起来docker system prune / docker system prune --volumes应该完全清除这个文件的内容,但它似乎积聚了其他不能被这些命令删除的东西。不管怎样,手动删除它可以解决问题! < / sub > < / p >
$ docker rm $(docker ps -aq)

这对我很有效

docker system prune

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

这可能是因为默认存储空间设置为40GB(默认路径,/var/lib/docker)

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

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

DOCKER_STORAGE_OPTIONS = '——存储驱动=叠加图= CUSTOM_PATH '

    <李>重启码头工人 Systemctl stop docker systemctl daemon-reload Systemctl start docker . txt

如果你运行命令docker info(它应该显示存储驱动为overlay)

如果你使用Docker桌面,你可以通过Docker的首选项来增加磁盘映像大小高级设置中。

以下是macOS的截图:

Docker Desktop on macOS, Resources, Advanced, Disk image size

不要只运行docker prune命令。它将删除所有的docker网络、容器和映像。所以你可能最终也会丢失重要的数据。

错误显示“设备上没有剩余空间”;所以我们只需要腾出一些空间。

腾出空间最简单的方法就是删除悬空的图像。

当旧创建的图像不被使用时,这些图像被称为悬空图像或有一些缓存图像,以及你可以删除。

使用以下命令。 列出所有悬空图像

docker images -f "dangling=true" -q

按映像id删除映像。

docker rmi IMAGE_ID

这样你就可以腾出一些空间,重新开始使用docker了:)

# EYZ0:

# EYZ0

# EYZ0:

# EYZ0

你可以这样做,而不是执行步骤1和2:

# EYZ0

该命令将删除:

  • 所有停止的集装箱
  • 未被至少一个容器使用的所有卷
  • 所有网络不被至少一个容器使用
  • 所有悬挂的图像

在我的情况下,我没有那么多的镜像/容器,但构建缓存正在填满我的Docker磁盘。

你可以通过跑步看到这就是问题所在

docker system df

输出:

TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              22                  13                  7.581GB             3.899GB (51%)
Containers          15                  0                   2.166GB             2.166GB (100%)
Local Volumes       4                   4                   550.2MB             0B (0%)
Build Cache         611                 0                   43.83GB             43.83GB!!!!!!!!!

下面的命令解决了这个问题

docker builder prune

我刚碰到这个。我用的是Ubuntu 20.04。工作什么?重新安装码头工人:

sudo apt-get purge docker-ce docker-ce-cli containerd.io
sudo apt-get install docker-ce docker-ce-cli containerd.io

有点粗鲁,我知道。我试着修剪Docker,但还是不管用。

我进入docker设置并更改了可用的图像空间。在使用docker build创建新映像时达到了极限。所以我增加了可用的数量。

Image from MacOS docker dashboard

如果你已经清理了未使用的容器,图片用

docker system prune -a

一定要检查你是否有不健康的容器。他们的行为非常奇怪,难以预测。在我的例子中,因为这些,我得到了这个错误,即使有大量的磁盘空间。

docker ps -a 将列出所有的容器。如果他们中的任何一个是这样的:

CONTAINER ID   IMAGE          COMMAND   CREATED          STATUS                     PORTS           NAMES
4c01db0b339c   ubuntu:12.04   bash      17 seconds ago   Up 16 seconds (unhealthy)  3300-3310/tcp   webapp

您需要重新启动docker守护进程。

那么多关于修剪声明的帖子。因为这个命令确实会清理docker文件,如果实际存储空间被占用,它不会修复您的系统。对我来说,问题是服务器的存储空间太满了。因此,我有两个选择。

选项1:清理现有空间

  1. 运行别人说过的所有系统修剪命令。
  2. df -H,还有多少空间?
  3. 使用du --block-size=M -a / | sort -n -r | head -n 20检查是什么占用了系统上这么多的空间,它将显示20个最大的文件。
  4. 删除文件或将其移出系统。

选择2:获得更多空间

  1. 为硬盘驱动器增加更多空间,然后扩展。如果你像我一样只有一个HD,我必须挂载一个名为“gparted”的操作系统。并扩大驱动器。

在我的例子中,我运行了docker system df来找出哪个组件占用了更多的空间,然后我执行了docker system prune -a来清理所有悬挂的容器、图像等。最后,我运行docker volume rm $(docker volume ls -qf dangling=true)来清理悬挂的卷。

下面是按顺序执行的命令。

docker system df
docker system prune -a
docker volume rm $(docker volume ls -qf dangling=true)

在我的例子中,发生这种情况是因为我超过了Docker映像大小的10Gb限制。这似乎已经有所缓解,有一种方法可以将限制增加到100Gb (https://github.com/moby/moby/issues/5151),但我不确定如何—对于我的用例,切换到映射卷是可以的,无论如何都有更好的性能。

我在GCP mashine上遇到了这个问题。没有一种修剪方法对我有效。/var/lib/docker仍然重约160gb。然后我停了下来 service docker stop删除docker缓存文件夹

# EYZ0。重新启动docker服务后,这个删除的文件夹被重新创建为明确的docker系统文件夹。当然,我丢失了所有的docker数据,但释放了磁盘空间。