Docker挂载本地build目录到容器后本地无对应生成文件如何解决

1. 挂载路径配置错误 #

• 先确认docker-compose.yml中volumes配置的本地路径是否符合预期：
  • 若使用相对路径（例：./build:/app/build），相对路径是基于执行docker-compose up命令的工作目录，而非docker-compose.yml文件所在目录（通过-f参数指定非当前目录的compose文件时极易踩坑）
  • 可以执行docker inspect <实际容器名/容器ID>，查看Mounts字段的Source值，确认实际绑定的本地路径就是你预期的build目录

2. 容器内/app/build路径被二次挂载覆盖 #

这是该场景下最常见的诱因：

• 验证方法：容器启动后执行docker exec <容器名/ID> mount | grep /app/build，如果返回结果中存在除type bind之外的挂载类型（比如tmpfs、overlay等），说明你配置的bind mount被后续的其他挂载操作覆盖了，容器内写入的文件都落在新挂载的文件系统中，自然不会同步到本地。
• 常见触发场景：
  • Dockerfile中显式声明了VOLUME /app/build
  • 容器的entrypoint启动脚本、command命令中存在挂载到/app/build的操作
  • docker-compose.yml中额外配置了tmpfs、匿名卷到/app/build路径
• 解决方法：删除对应的VOLUME声明、启动脚本中的挂载逻辑，或调整compose配置避免路径重复挂载。

3. 宿主权限不匹配（Linux/Mac 宿主） #

• 容器内生成文件的用户UID/GID如果和本地build目录的所有者UID/GID不一致，可能出现文件已写入但本地当前用户无权限查看的情况
• 验证方法：Linux下执行sudo ls -la <本地build目录绝对路径>，如果能看到文件则确认是权限问题，可修改本地目录权限，或在compose中配置user参数，让容器以和本地目录所有者一致的UID启动即可。

4. Docker Desktop 文件共享权限问题（Windows/Mac 宿主） #

• 如果你使用Docker Desktop，需要先在设置的「文件共享」列表中开启本地build目录所在盘符/路径的共享权限，未授权的路径挂载会直接失效。

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