Docker Compose挂载Buildroot输出目录为卷时构建失败

rename调用失败的本质是跨文件系统执行rename触发了POSIX系统调用限制，根源是两个版本Compose处理bind类型卷挂载的逻辑存在差异，直接决定了配置的output目录是否真正完成了宿主机路径挂载。

两个版本的核心行为差异 #

• 带连字符的旧版独立docker-compose（V1分支，Python实现，1.29.1属于该分支）
  该版本完全透传Docker引擎原生挂载逻辑，不会对配置的挂载路径做额外预处理。Docker引擎原生处理bind卷挂载时，仅会自动创建目标路径的最后一级目录，不会递归创建不存在的父目录；如果父目录缺失，挂载会直接静默失败，不会阻断容器启动流程。
  该场景中，容器启动执行挂载的阶段，/usr/local/share/broot/my-custom父目录还不存在——这个目录是容器启动后才通过clone-repo.sh脚本创建的，因此Docker引擎尝试创建output挂载点时会失败，bind挂载实际未生效。后续容器内的output目录是编译阶段在容器自身的overlay可写层生成的普通子目录，和临时文件所在的父目录属于同一个文件系统。
• 不带连字符的新版内置docker compose（V2分支，Go实现，Docker 20.10.5内置版本属于该分支）
  该版本遵循正式Compose规范，在调用Docker引擎挂载接口前会增加一层预处理：递归创建容器内所有挂载点路径下缺失的父目录，确保挂载一定执行成功。
  该场景中，V2会提前递归创建/usr/local/share/broot/my-custom/output全路径，Docker引擎顺利完成bind挂载，将宿主机的./output目录挂载到容器内对应路径。此时output是独立的宿主机文件系统挂载点，和父目录所在的容器overlay可写层不属于同一个文件系统。

rename调用失败的直接原因 #

POSIX标准定义的rename()系统调用不支持跨不同文件系统移动文件，跨文件系统调用时会返回EXDEV错误码。
Buildroot的kconfig逻辑会把临时文件生成在/usr/local/share/broot/my-custom/目录下（属于容器overlay层），再通过rename移动到output目录下的目标路径。V2场景下该操作属于跨文件系统操作，直接触发错误，最终返回编译失败。
V1场景下因为bind挂载未生效，临时文件和目标路径都在同一个overlay文件系统内，rename操作无系统调用限制，因此编译流程可正常执行。

验证方式 #

在V1启动的容器内执行mount | grep output，不会查询到任何挂载记录，可证明output目录实际位于容器可写层；在V2启动的容器内执行相同命令，可查询到宿主机路径到output目录的bind挂载记录。

修复方案 #

• 最优方案：调整卷挂载配置，不要仅挂载output子目录，直接挂载整个父目录，例如配置./my-custom:/usr/local/share/broot/my-custom，保证临时文件和目标路径在同一个挂载点、同一个文件系统内，rename可正常执行。
• 配置调整方案：修改Buildroot的kconfig配置，将临时文件生成路径改到output目录下，避免跨文件系统操作。

注意：不要尝试在Dockerfile构建阶段提前创建/usr/local/share/broot/my-custom父目录，该操作会让V1场景下也能成功挂载output卷，触发和V2完全一致的rename错误。

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