Docker容器挂载docker二进制文件存在但执行提示not found

这个报错不是指/usr/bin/docker文件本身不存在，是动态链接依赖缺失导致的二进制加载失败。
你挂载到容器内的docker二进制是宿主机上的动态编译版本，运行时需要匹配的ELF动态链接器、以及glibc等依赖动态库才能被内核正常加载：

• 如果容器用的是Alpine这类默认使用musl libc的精简基础镜像，本身没有提供glibc兼容的链接器和依赖库
• 就算容器用的是Debian/Ubuntu这类glibc系镜像，也可能因为和宿主机的glibc版本、链接器路径不匹配，导致加载时找不到对应依赖

Shell返回的not found是二进制加载失败的通用提示，不会区分是目标文件本身不存在，还是目标文件依赖的运行时组件不存在，很容易误导排查方向。你可以在容器内执行ldd /usr/bin/docker验证，会直接输出大量依赖库找不到的结果；也可以执行readelf -l /usr/bin/docker | grep interpreter查看二进制要求的动态链接器路径，这个路径在容器内大概率是不存在的。

• 补全依赖挂载：在宿主机执行ldd /usr/bin/docker，将输出中列出的所有动态依赖库、以及对应的动态链接器（x86_64架构通常路径为/lib64/ld-linux-x86-64.so.2），按照宿主机的原路径全部挂载到容器内，保证二进制运行时能找到所有依赖
• 替换为静态编译的docker客户端：下载官方静态编译版本的docker二进制放入容器，静态编译版本不依赖系统动态库，不存在依赖匹配问题，可直接运行
• 标准Docker out of Docker方案：这是容器内操作宿主机Docker的最稳妥实践，仅将宿主机的/var/run/docker.sock挂载到容器，在容器构建阶段通过自身系统的包管理器安装和宿主机版本匹配的docker客户端，不需要跨环境挂载二进制，完全适配容器自身的系统库环境
• 临时调试场景可以直接使用docker:dind这类自带完整Docker运行环境、或者带完整glibc依赖的基础镜像，从基础上避免依赖不匹配问题

内容的提问来源于stack exchange，提问作者Pueblo2708