我的 Linux 机器上安装了一个使用 cifs 的 smb 共享，似乎可以正常工作。它能够拉取gcc:8docker 镜像并下载、验证和拉取镜像的所有层（我已将其验证为在本地驱动器上拉取镜像）。
我解决了创建符号链接的问题；cifs 挂载的共享正在使用文件和目录访问权限0777，并且我使用名为 mfsymlinks 的 cifs 参数 int /etc/fstab 来使软链接为 docker 工作。
docker 拉取之前曾失败过，因为在拉取其中一个层时无法创建符号链接，并且还因为无法“mkdir”而失败过一次，可能是因为访问权限不够。我还没有“清理”磁盘上的 docker 暂存区，所以也许这可能是那次失败的遗留问题？
以下是 docker pull 过程的最后几行：
...
16ea0e8c8879: Pull complete
50024b0106d5: Pull complete
ff95660c6937: Pull complete
9c7d0e5c0bc2: Pull complete
29c4fb388fdf: Pull complete
f87845d1b3b4: Pull complete
adc3e1e98dd6: Pull complete
4dc8223d50f0: Pull complete
failed to register layer: Error processing tar file(exit status 1): failed to mknod("/usr/bin/g++", S_IFCHR, 0): operation not permitted
鉴于只有 root 能够通过内核代码调用创建新节点（mknod）（在本例中，创建一个节点来将 g++ 编译器存储在 docker 层内），我开始认为这个问题与用户权限有关；无论是 gitlab-runner，cifs 挂载的用户凭据，还是 docker 服务，还是其他什么？
以下是 gitlab 作业的启动方式：
Running with gitlab-runner 12.5.0 (577f813d)
on XYZ-for-project abcdefgh
Using Shell executor...
Running on XYZ...
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in /mnt/share/NightlyBuild/abcdefgh/0/username/project/.git/
Checking out df111d72 as master...
Skipping Git submodules setup
$ docker login $IMAGE_PATH -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /home/gitlab-runner/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
$ docker info
Client:
Debug Mode: false
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 19.03.2
Storage Driver: overlay2
Backing Filesystem: <unknown>
Supports d_type: true
Native Overlay Diff: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 5.3.0-24-generic
Operating System: Ubuntu 19.10
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.775GiB
Name: XYZ
ID: 435N:UBGI:NS4Z:CX6F:GD2A:WMPT:4THN:FQQX:6NRU:VKJL:O7E2:V46F
Docker Root Dir: /mnt/share/NightlyBuild/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
$ docker build -f Lin64-Base/Dockerfile -t docker-build .
Sending build context to Docker daemon 949MB
Step 1/37 : FROM gcc:8
8: Pulling from library/gcc
16ea0e8c8879: Pulling fs layer
50024b0106d5: Pulling fs layer
ff95660c6937: Pulling fs layer
9c7d0e5c0bc2: Pulling fs layer
29c4fb388fdf: Pulling fs layer
f87845d1b3b4: Pulling fs layer
adc3e1e98dd6: Pulling fs layer
4dc8223d50f0: Pulling fs layer
b601d78e8f0b: Pulling fs layer
f87845d1b3b4: Waiting
adc3e1e98dd6: Waiting
4dc8223d50f0: Waiting
b601d78e8f0b: Waiting
9c7d0e5c0bc2: Waiting
29c4fb388fdf: Waiting
50024b0106d5: Verifying Checksum
50024b0106d5: Download complete
...
** 更新 **
我提到我没有“清理”docker 阶段区域，但是在新的 docker 主目录（替换 /var/lib/docker）上也出现了相同的行为，并报告了相同的错误。
这个问题导致我必须使用位于 Windows10 主机上的 VirtualBox 中的本地 ubuntu 磁盘。该分区有 150 GB 可用空间，足够大，而主机有超过 50 GB 的可用磁盘大小。所以这似乎是一个解决方案，直到我遇到了 另一个问题。在 docker 构建阶段，使用 (ninja) c++ 构建源代码时，磁盘空间会消失。论坛将该主题标记为“已解决”并提及chkdsk /f解决方案，但实际上是重新启动 Windows 修复了错误报告的主机可用磁盘大小。当磁盘大小似乎低于兆字节时，Windows 10 会冻结并显示蓝色消息屏幕，提示无法继续。当然，重新启动 Windows 会关闭 Virtual Box、Ubuntu、gitlabrunner 作业和 docker 构建，所以这显然不是一个好的解决方案。