Docker MinIO上传图片报错“Access Denied”权限不足

Question

在使用 Docker 部署 MinIO 并通过 SDK 或 Web 控制台上传图片时，常遇到 `Access Denied` 错误。该问题通常并非源于系统文件权限，而是 MinIO 的**访问控制策略配置不当**：默认启动的 MinIO（如 `minio/minio server /data`）启用严格 IAM 模式，要求显式创建用户、设置策略（Policy）并绑定到 Access Key；若直接使用 root 用户（`MINIO_ROOT_USER/ROOT_PASSWORD`）但未为其附加 `ConsoleAdmin` 或 `S3FullAccess` 策略，或 SDK 使用了错误的 endpoint/bucket region，亦或客户端请求携带了未授权的签名（如 v2 vs v4）、跨域（CORS）未配置导致预检失败，均会触发此错误。此外，Docker 容器内 `/data` 目录宿主机挂载权限异常（如 SELinux 限制或非 0700 权限）也可能间接导致服务降级为只读模式，引发拒绝访问。需结合日志（`--console-address :9001`）与 `mc admin info` 排查真实原因。

Answer 1

```html

一、现象层：识别 Access Denied 的典型触发场景

• Web 控制台登录成功，但上传图片时弹出 Access Denied (403)；
• SDK（如 AWS SDK for Go/Java/Python）调用 PutObject 报错：AuthorizationHeaderMalformed 或 AccessDenied；
• 使用 mc alias set 配置后执行 mc cp 失败，提示 error: Unable to stat `xxx`: Access Denied；
• 容器日志中高频出现 ERROR API error: access denied，但无明确策略上下文；
• MinIO Console 显示 “You do not have permission to perform this action” —— 即使使用 root 凭据登录。

二、配置层：IAM 模式下的权限链断裂分析

MinIO vRELEASE.2022-10-28T21-26-55Z 起默认启用 strict IAM mode，其权限模型为：

graph LR A[Root User] -->|必须显式绑定| B[Policy] C[Custom User] -->|必须分配| B B --> D[ConsoleAdmin] B --> E[S3FullAccess] B --> F[Custom Policy JSON] D --> G[Web Console 全功能] E --> H[S3 API 读写删]

三、协议层：签名版本与 endpoint 一致性校验

错误类型	根因	验证命令
SignatureDoesNotMatch	SDK 使用 signature_version=s3v2，而 MinIO 仅支持 s3v4（默认）	aws --endpoint-url http://localhost:9000 s3 ls --debug 2>&1 | grep Signature
InvalidRequest: The difference between the request time and the server's time is too large	客户端系统时间偏差 >15min，v4 签名失效	date -R; curl -s localhost:9000/minio/health/live | head -1

四、网络层：CORS 与预检请求（OPTIONS）拦截

前端 Web 应用直传 MinIO 时，浏览器会先发 OPTIONS 预检请求。若未配置 CORS，Nginx 反代或 MinIO 自身将拒绝后续 PUT 请求。

# 正确的 CORS 配置示例（通过 mc 设置）
mc admin config get myminio | jq '.cors'
# 应包含：
{
  "rules": [{
    "allowedOrigins": ["https://myapp.com"],
    "allowedMethods": ["GET", "PUT", "POST", "DELETE"],
    "allowedHeaders": ["*"],
    "exposeHeaders": ["ETag"],
    "maxAge": 86400
  }]
}

五、存储层：Docker 挂载权限导致的隐式只读降级

• 宿主机目录 /mnt/minio-data 权限非 0700 或属主非 1001:1001（MinIO 容器内默认 UID/GID）；
• SELinux 启用时，挂载选项缺失 :z 或 :Z（如 -v /mnt/data:/data:z）；
• MinIO 启动日志出现 WARNING: Detected non-0700 permissions on /data — switching to read-only mode；
• 此时即使策略正确，所有写操作均返回 AccessDenied（伪权限错误）。

六、诊断层：结构化排查路径（5步法）

1. 查服务状态：docker logs -f minio-container | grep -i "iam\|policy\|readonly"；
2. 查 root 权限：mc admin user info myminio $MINIO_ROOT_USER，确认是否绑定 ConsoleAdmin；
3. 查 bucket 策略：mc policy get myminio/mybucket，验证是否允许 s3:PutObject；
4. 查签名兼容性：SDK 初始化时强制指定 credentials.NewStaticV4(...) 和 use_path_style（若未启用 DNS 子域）；
5. 查挂载健康度：docker exec minio-container ls -ld /data && id，比对 UID/GID 与宿主机权限。

七、修复层：生产就绪配置模板

# docker-compose.yml 关键片段（含安全加固）
services:
  minio:
    image: quay.io/minio/minio:latest
    command: server /data --console-address :9001
    environment:
      MINIO_ROOT_USER: "admin"
      MINIO_ROOT_PASSWORD: "SecurePassw0rd!"
      MINIO_SERVER_URL: "http://localhost:9000"  # 影响签名生成
    volumes:
      - "/opt/minio/data:/data:z"     # SELinux 安全上下文
      - "/opt/minio/config:/root/.minio:z"
    ports:
      - "9000:9000"
      - "9001:9001"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]

八、验证层：端到端连通性测试脚本

以下 Bash 脚本可自动化验证全部关键链路：

#!/bin/bash
set -e
mc alias set local http://localhost:9000 admin SecurePassw0rd!
mc admin user add local appuser appsecret
mc admin policy attach local ConsoleAdmin --user=appuser
mc mb local/test-bucket
mc policy set public local/test-bucket
echo "test" | mc pipe local/test-bucket/test.txt
mc cat local/test-bucket/test.txt | grep "test" && echo "✅ All layers PASS"

```