这个问题我之前帮不少用户排查过，核心原因是Windows Server的LCOW（Linux Containers on Windows）模式与Docker Desktop的权限映射机制差异——你设置了LCOW_SUPPORTED=1启用了Linux容器，但Windows文件系统的权限无法被Linux容器正确解析，导致RabbitMQ要求的.erlang.cookie文件权限（仅所有者可访问）无法满足，直接触发崩溃。而Docker Desktop用WSL2/Hyper-V后端时，会自动做权限转换，所以不会出现这个问题。

问题根源 #

当你用local卷挂载Windows目录到Linux容器的/var/lib/rabbitmq时，生成的.erlang.cookie文件继承了Windows的宽松权限，容器内的rabbitmq用户（UID 999）无法保证文件只有自己能访问，触发Erlang的安全校验，直接导致RabbitMQ崩溃。

解决步骤 #

1. 清理现有问题卷

首先要删掉已经被错误权限污染的卷，避免后续启动重复出现问题：

docker-compose down -v

2. 选择以下方案之一修改你的docker-compose.yml

方案一：启动时自动修复权限（快速生效）

修改rabbitmq服务的command，在启动RabbitMQ前先修正cookie文件权限：

version: "3.5"
services:
  rabbitmq:
    # restart: always
    image: rabbitmq:3-management
    container_name: rabbitmq
    ports:
      - 5672:5672
      - 15672:15672
    networks:
      - myname
    volumes:
      - rabbitmq:/var/lib/rabbitmq
    # 添加启动前的权限修复命令
    command: >
      bash -c "chmod 600 /var/lib/rabbitmq/.erlang.cookie && rabbitmq-server"
networks:
  myname:
    name: myname-network
volumes:
  rabbitmq:
    driver: local

方案二：临时用root用户启动（不推荐生产）

如果只是测试环境需要快速验证，可以让容器以root用户运行，绕过权限检查：

services:
  rabbitmq:
    # 其他配置不变
    user: "root"

⚠️ 注意：生产环境不建议这么做，会带来安全风险。

方案三：自定义镜像预配置权限（生产环境推荐）

创建一个自定义Dockerfile，提前确保/var/lib/rabbitmq目录和cookie文件的权限正确：

FROM rabbitmq:3-management
RUN chown -R rabbitmq:rabbitmq /var/lib/rabbitmq && \
    chmod 700 /var/lib/rabbitmq && \
    touch /var/lib/rabbitmq/.erlang.cookie && \
    chmod 600 /var/lib/rabbitmq/.erlang.cookie && \
    chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie

然后修改docker-compose.yml里的image为build：

services:
  rabbitmq:
    # 其他配置不变
    build: .

3. 重新启动服务

执行以下命令启动容器：

docker-compose up -d

等容器启动完成后，再访问http://localhost:15672/就能正常进入RabbitMQ管理界面了。

内容的提问来源于stack exchange，提问作者d.borzouei