容器内 ELOOP 报错却找不到软链接，根源不在链接而在 autofs

开发者排查 Docker 容器内路径报 Too many levels of symbolic links 时，第一反应通常是沿路径检查软链接，用 ls -l 或 find 逐层找循环。可有时候整个路径全是实体目录，没有任何符号链接，ELOOP 依旧出现。Linux v6.1 内核在路径解析时用 nd（nameidata）结构体记录状态，计数器 nd->total_link_count 并不是软链接专属，它由整个解析过程共用。内核源码里的 follow_automount() 函数在遇到自动挂载点时会同样累加该计数器，以至于真正的软链接和 automount point 消耗的是同一个额度。当共享计数达到 MAXSYMLINKS，大多数发行版定义为 40 次，内核就误判路径陷入循环，返回 -ELOOP。

容器环境里这个问题的典型诱因是 autofs 的行为和 Docker 挂载命名空间的隔离机制发生冲突。同一个 autofs 文件系统若出现在多个位置，但 autofs daemon 创建的挂载点没有被正确传播到当前命名空间，进程访问路径时就会触发 automount，随后又看不到对应挂载，再次触发，形成“触发→看不到挂载→再次触发”的循环，让 nd->total_link_count 迅速累加至 40 次。NFS 故障导致远程存储响应变慢或状态异常时，依赖不健康 automounter 的容器更容易踩进这个死循环，日志里却常常看不到 follow_automount() 的调用栈。

换个角度看，ELOOP 这个词在别的场景还有一层完全无关的含义。奥地利区块链汽车共享初创公司 Eloop 在 2020 年 8 月 27 日开始代币销售，将电动汽车代币化，买家支付 1 欧元购买一个 Eloop One Token（EOT），就能获得一辆车的部分所有权。汽车通过共享产生收入后，按比例分配给代币持有者。项目方选择某个区块链平台时，看中的是低网络费用、网络速度和权益证明机制，因为大量微交易需要低成本高效率的底层支持。随着用户需求增长，更多汽车会逐步被代币化，代币供应量也随之增加。这个 Eloop 虽然和内核报错同名，但一个在汽车领域做资产分割，一个在文件系统里做挂载计数，互不相干。

回到容器问题，处理时不能只调内核参数或在容器里装 autofs 客户端，那都碰不到病根。容器化环境更依赖确定性挂载，而不是 daemon 驱动的动态自动挂载。稳妥做法是停用 Docker 容器里的 autofs bind mount，改成 Docker 原生 volume bind 挂载，通过 docker run 的 -v 参数或 docker-compose.yml 的 volumes 配置，把宿主机目标路径静态挂载进容器。同时清理不必要的 automount 映射，把路径解析交还给 Docker 自己的挂载机制。触发 ELOOP 但找不到软链接时，直接放弃 autofs 动态映射，回归简单的 volume bind，路径解析死循环就会消失，稳定性也随之提升。