Mac环境Docker Compose重建后旧环境变量残留问题

• Bitnami镜像的初始化逻辑不会重复执行：所有状态类配置（包括密码校验、空密码开关）仅在服务第一次启动、数据目录为空时生效，后续启动只要检测到数据目录内的初始化标记文件，会直接跳过配置校验环节。你之前把命名卷改为本地宿主路径映射后，这些本地目录的文件不会随容器、镜像删除被自动清理，哪怕反复重建容器，旧的初始化状态、校验逻辑还是会被触发，这也是你明明改了ALLOW_EMPTY_PASSWORD=yes却还是报密码未设置的核心原因。你提到手动运行原有镜像也出现同类报错，本质是运行命令时隐式关联了之前遗留的本地卷路径，没有使用全新的空目录触发初始化逻辑，所以即使启动参数正确，还是会沿用卷内存储的旧状态触发报错。
• Docker for Mac的虚拟机存储残留：Big Sur版本的Docker Desktop运行在独立的轻量虚拟机内，所有卷数据、容器缓存都存在虚拟机的虚拟磁盘里。如果你之前执行清理操作时漏加了清理卷的参数（比如只跑了docker system prune没带--volumes），旧的卷数据、网络配置、环境变量缓存会一直留在虚拟机存储里，不会被宿主机的操作清除。
• 权限配置的副作用：你给magento服务添加的user: root配置会改变卷内写入文件的属主为root，容器如果后续切回Bitnami默认的非root运行用户，会因为权限不足无法读取卷内的初始化状态文件，触发重复校验报错，哪怕配置本身是正确的。
• .env文件加载规则的坑：Docker Compose只会读取compose.yml文件同目录下的.env文件，如果你之前在其他目录执行过compose命令，或者手动指定了其他env文件，新配置的变量不会被正确加载。

• 先在compose项目目录下执行容器下线命令，清理关联网络：docker compose down --remove-orphans
• 手动删除你之前映射为本地路径的Magento、MariaDB数据目录内的所有文件（这些目录就是你替换原来命名卷的本地文件夹，Bitnami的初始化标记都存在这里，清掉才能触发重新初始化）
• 执行全量清理命令，务必带上卷清理参数，避免残留旧卷数据：docker system prune -a --volumes
• 针对Big Sur的额外虚拟机缓存清理：打开Docker Desktop设置面板，进入Resources->File Sharing配置页，确认你映射的本地路径在共享白名单内，重启Docker Desktop刷新虚拟机的挂载缓存。

完全支持使用自定义变量配置卷的宿主路径，这是Docker Compose的原生能力，具体操作：

• 在项目根目录的.env文件中定义你需要的本地路径变量，例如：

  MAGENTO_HOST_PATH=./dev-data/magento
  MARIADB_HOST_PATH=./dev-data/mariadb
  

• 在docker-compose.yml的卷映射配置中直接引用变量即可：

  volumes:
    - ${MAGENTO_HOST_PATH}:/bitnami/magento
    - ${MARIADB_HOST_PATH}:/bitnami/mariadb
  

• 注意事项：
  • 避免将映射路径设置在MacOS的系统受保护目录下（如系统级Library目录、受限的共享文件夹），否则Docker的文件共享机制会无法正常读写
  • 如果之前使用user: root启动过容器，记得给本地映射目录开放所有用户的读写权限，避免后续非root用户启动时出现权限错误

• 调整和Bitnami服务初始化相关的配置（如密码、空密码开关、安装参数）时，必须先清空对应服务挂载的数据目录，不要只靠删除容器、镜像重建，因为卷内的状态不会被自动重置
• 调整完compose配置后，先执行docker compose config查看解析后的最终生效配置，确认环境变量、卷路径、用户配置是否和你预期一致，避免因为变量名拼写错误、.env文件路径错误导致配置未加载
• 测试新配置时不需要反复删除Docker镜像，只要清空对应数据目录、执行docker compose down后再重新up即可，Bitnami镜像的初始化逻辑是幂等的。

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