使用mc将公共S3存储桶文件复制到本地S3时出现Access Denied错误

常见报错根因 #

• 权限校验优先级错位
  你观察到浏览器能正常打开目标文件，本质是浏览器发起的是不带任何身份凭证的匿名请求，命中了源桶配置的公共读规则。但mc客户端在访问s3-ghaf别名时，默认会携带你之前配置好的AccessKey/SecretKey凭证，对象存储的权限校验逻辑是已认证身份的权限优先级远高于公共匿名权限——哪怕匿名用户能访问的文件，只要你带的认证身份没有对应的s3:GetObject权限，系统会直接返回Access Denied，不会自动降级走匿名公共访问的规则。
• K8s前置网关的细粒度拦截
  源MinIO部署在K8s集群中，外部访问流量一般会经过Ingress、WAF、对象存储专用网关等组件。这类组件常见的拦截规则是：只放行带浏览器标准User-Agent的GET请求，对mc客户端（默认UA为mc/[版本号]）发起的请求直接做权限拦截，返回Access Denied。这种场景下的报错根本没有走到MinIO本身的权限校验环节，和桶的公共策略没有关系。
• 桶公共策略的粒度配置错误
  配置公共访问策略时容易出现权限错位：只给指定路径的匿名用户配了s3:GetObject权限（也就是浏览器能打开文件），但没有给对应路径配置s3:ListBucket权限时，mc虽然能通过其他渠道遍历到部分文件路径，但实际发起对象读取请求时，匿名身份不满足最小权限要求，就会触发拒绝；反过来如果配置的访问凭证只有列表权限没有对象读取权限，也会出现“能扫到文件路径、拉取时报错”的现象。

快速定位方法 #

• 给mc命令增加--anonymous参数，强制mc不携带任何配置的凭证，完全模拟浏览器的匿名访问逻辑执行递归复制，如果命令执行成功，即可直接定位为之前配置的s3-ghaf别名对应的认证凭证权限不足。
• 给mc命令增加--debug参数，查看实际返回的403响应头信息：如果响应头里没有MinIO自带的x-amz-request-id字段，说明Access Denied是K8s前置网关层返回的，需要去检查Ingress、WAF的UA过滤、路径拦截规则。
• 直接核对源MinIO控制台的公共访问策略JSON配置，确认对应路径下的策略同时包含路径列表权限、对象读取权限，没有因为通配符配置错误导致权限范围偏移。

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