Debian Bullseye Docker中可执行文件报错如何排查缺失依赖

文件存在、权限正常但执行报bash: no such file or directory: ./[executable_name]，且ldd显示所有依赖已满足时，故障点是二进制硬编码的ELF动态链接器（解释器）路径在系统中不存在。
从你贴的ldd输出可以直接看到对应特征：可执行文件要求的链接器路径为/lib64/ld-lsb-x86-64.so.3，但Debian Bullseye默认仅提供/lib64/ld-linux-x86-64.so.2。ldd运行时会自动做路径兼容映射，所以会显示依赖满足，但内核加载二进制时不会执行这类替换，找不到对应路径的链接器就会抛出和文件不存在完全一致的报错，这也是WSL2 Ubuntu下安装lsb包能修复问题的核心原因——lsb相关包会自动创建这个缺失的软链接。

不需要逐个安装lsb依赖包试错，执行单条命令即可直接确认根因：

readelf -l ./[executable_name] | grep interpreter

命令输出会直接打印二进制硬编码要求的解释器绝对路径，你再执行ls [打印出的路径]验证，即可确认该路径确实不存在。

注：linux-vdso.so.1是内核暴露的虚拟动态库，不会导致该类报错，无需排查。

Debian Bullseye 主源已经移除了lsb、lsb-core安装包（LSB标准早已停止维护），不需要强行找包安装，直接手动创建对应软链接即可修复：

# 先确认系统自带的基础动态链接器存在（libc6包默认会预装该文件）
ln -s /lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3

软链接创建完成后即可正常执行目标二进制，不需要安装其他额外依赖。

很多人遇到这个报错会反复核对文件路径、执行权限，浪费大量时间：内核加载ELF二进制时，只要解释器路径不存在，无论二进制文件本身是否存在、权限是否正确，都会统一抛出"no such file or directory"报错，迷惑性极强。而ldd本身是个封装脚本，会预设加载规则做路径替换，因此无法检出这类解释器路径不匹配的问题。

内容的提问来源于stack exchange，提问作者Lucy The Brazen