为什么docker-compose挂载MySQL初始化SQL文件时权限显示为?且Ubuntu下挂载为目录？

核心原理 #

• Docker 的 Bind Mount 存在一个非常容易踩坑的默认行为：当配置的本地源路径在宿主机上不存在时，Docker 引擎不会抛出任何错误，反而会自动在宿主机上创建一个与路径名完全一致的空目录，再将这个空目录挂载到容器内的目标路径下。这就是你在 Ubuntu 服务器上看到 SQL 文件被挂载成目录的根本原因。
• Mac 端显示全问号的异常是 Docker Desktop 自带虚拟文件系统的已知问题：旧版 osxfs 驱动在挂载单个小文件时，会偶发无法读取文件权限、大小等元数据的 I/O 错误，导致 ls 命令输出 -????????? 的异常结果，但文件内容的读取通道是正常的，所以 MySQL 的初始化脚本依然能正常读取 SQL 内容完成数据加载。
• 跨系统表现不一致的核心原因是两边的路径解析不匹配：Mac 上配置的相对路径能正确指向真实存在的 SQL 文件，而 Ubuntu 上相同的相对路径因为路径拼写、大小写差异，根本没有匹配到真实文件，触发了 Docker 自动创建空目录的逻辑。

排查与修复步骤 #

• 首先在 Ubuntu 服务器上，进入 docker-compose.yaml 所在的工作目录，执行 ls -l ./test/data/，核对本地真实的 SQL 文件名是否和 compose 配置里写的源路径完全匹配。重点核对下划线/横线差异、大小写拼写——你在容器内看到的目录名是 1-music-schema.sql（s 前是横线），但配置里写的源文件是 music_schema.sql（s 前是下划线），大概率就是路径拼写不匹配导致的文件找不到。
• 删掉宿主机上被 Docker 自动创建的空目录：一般在 ./test/data/ 路径下会生成和配置里写的文件名同名的空文件夹，手动删除这些空目录再重启容器，避免残留的空目录影响挂载。
• 规避相对路径的解析歧义：把 volumes 里的相对路径替换成基于 compose 文件目录的绝对路径，或者直接用内置变量拼接，比如：

  volumes:
    - ${PWD}/test/data/music_schema.sql:/docker-entrypoint-initdb.d/1-music_schema.sql
    - ${PWD}/test/data/beatles.sql:/docker-entrypoint-initdb.d/2-beatles.sql
  

  这种写法会强制使用启动 compose 时的工作目录作为路径基准，不会因为 Docker 版本、启动位置的差异出现路径解析错误。
• 关于 Mac 端的权限显示异常：可以在 Docker Desktop 设置里将文件共享驱动从旧版 osxfs 切换为 gRPC FUSE，就能解决单文件挂载的元数据读取异常，不影响实际运行效果。

补充提示：MySQL 官方镜像的初始化脚本只会识别 /docker-entrypoint-initdb.d/ 路径下的文件类型入口，如果挂载路径变成了目录，脚本会直接跳过该路径的内容，不会递归读取目录内的 SQL 文件，这也是你没有加载到数据、容器启动失败的直接原因。

内容的提问来源于stack exchange，提问作者Simon Ernesto Cardenas Zarate