在尝试使用Docker和Docker Compose时，我突然遇到“设备上没有剩余空间”的错误。我试图使用类似问题中建议的方法删除所有内容，但无济于事。
我跑的事情：
$ docker-compose rm -v
$ docker volume rm $(docker volume ls -qf dangling=true)
$ docker rmi $(docker images | grep "^<none>" | awk "{print $3}")
$ docker system prune
$ docker container prune
$ docker rm $(docker stop -t=1 $(docker ps -q))
$ docker rmi -f $(docker images -q)
据我所知，现在真的不应该留下任何东西。看起来就是这样：
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
卷相同：
$ docker volume ls
DRIVER VOLUME NAME
对于容器：
$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
不幸的是，我仍然会遇到像这样的错误：
$ docker-compose up
Pulling adminer (adminer:latest)...
latest: Pulling from library/adminer
90f4dba627d6: Pulling fs layer
19ae35d04742: Pulling fs layer
6d34c9ec1436: Download complete
729ea35b870d: Waiting
bb4802913059: Waiting
51f40f34172f: Waiting
8c152ed10b66: Waiting
8578cddcaa07: Waiting
e68a921e4706: Waiting
c88c5cb37765: Waiting
7e3078f18512: Waiting
42c465c756f0: Waiting
0236c7f70fcb: Waiting
6c063322fbb8: Waiting
ERROR: open /var/lib/docker/tmp/GetImageBlob865563210: no space left on device
有关我的Docker安装的一些数据：
$ docker info
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 1
Server Version: 17.06.1-ce
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 15
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
seccomp
Profile: default
Kernel Version: 4.10.0-32-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.685GiB
Name: engelbert
ID: UO4E:FFNC:2V25:PNAA:S23T:7WBT:XLY7:O3KU:VBNV:WBSB:G4RS:SNBH
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
我的磁盘信息：
$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 3,9G 0 3,9G 0% /dev
tmpfs 787M 10M 778M 2% /run
/dev/nvme0n1p3 33G 25G 6,3G 80% /
tmpfs 3,9G 46M 3,8G 2% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/loop0 81M 81M 0 100% /snap/core/2462
/dev/loop1 80M 80M 0 100% /snap/core/2312
/dev/nvme0n1p1 596M 51M 546M 9% /boot/efi
/dev/nvme0n1p5 184G 52G 123G 30% /home
tmpfs 787M 12K 787M 1% /run/user/121
tmpfs 787M 24K 787M 1% /run/user/1000
和
$ df -hi /var/lib/docker
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/nvme0n1p3 2,1M 2,0M 68K 97% /
如上所述，我还在尝试，所以我不确定是否已发布所有相关信息 - 如果您需要更多信息，请告诉我。
任何人都知道还有什么问题可以解决？
答案 0 :(得分：8)
问题是/var/lib/docker位于/文件系统上，该文件系统用完了inode。您可以通过运行df -i /var/lib/docker
由于/home的文件系统有足够的inode和磁盘空间，所以在那里移动Docker的工作目录应该会再次进行。
（请注意，这假设当前的Docker安装没有任何价值。）
首先停止Docker守护程序。在Ubuntu上，运行
sudo service docker stop
然后将旧/var/lib/docker移开：
sudo mv /var/lib/docker /var/lib/docker~
现在在/home上创建一个目录：
sudo mkdir /home/docker
并设置所需的权限：
sudo chmod 0711 /home/docker
将/var/lib/docker目录链接到新的工作目录：
sudo ln -s /home/docker /var/lib/docker
然后重启Docker守护程序：
sudo service docker start
然后它应该再次起作用。
答案 1 :(得分：0)
供以后参考，如果您已删除所有容器，则也可以尝试docker system prune来删除悬空的图像，容器和其他任何东西。
答案 2 :(得分：0)
这可能无法直接回答问题，但是如果用于创建映像的Dockerfile可用，通常它会很有用。
尤其要确保限制将要生成的层数，因此，在编写Dockerfile时，请避免这样做：
RUN apt-get update && sudo apt-get install -y package1
RUN apt-get update && sudo apt-get install -y package2
RUN apt-get update && sudo apt-get install -y package3
然后执行以下操作：
RUN apt-get update && sudo apt-get install -y \
package1 \
package2 \
package3
这样做会大大减少图像的大小以及inode的使用量，因为生成的层数更少。在我的案例中，这有助于解决该问题（所有inode都将耗尽）。
请确保删除因构建失败而生成的潜在中间映像，以释放空间docker rmi <IMAGE_ID>。
有关更多提示，您可以访问有关Optimizing Docker images的站点。