适用版本： 6.8-8.9
1. 错误异常的基本描述 #
cannedACL is not valid: [cannedACL] 表示 Elasticsearch 在解析 S3 仓库配置中的 canned_acl 时，没有在支持的 ACL 枚举中找到对应值，因此直接拒绝该配置。
从源码片段可以看出，这一步是把字符串与内置枚举逐个比对；只要没有匹配项，就会抛出 BlobStoreException。
常见现象 #
- 创建或更新 S3 仓库时立即返回配置错误。
- 仓库验证在真正访问 S3 之前就失败。
- 常见于手工填写 ACL 字符串、从 AWS SDK 样例直接复制参数或大小写写错。
2. 为什么会发生这个错误 #
Elasticsearch 只接受它内部支持的 canned ACL 值。如果配置中填入了未知字符串，或者填的是 AWS 其他接口支持但仓库插件不接受的值，就会触发该异常。
常见原因包括：
canned_acl拼写错误。- 使用了 Elasticsearch 当前版本未支持的 ACL 名称。
- 从外部系统复制了带有不同命名风格的 ACL 值。
- 在自动化模板中把 ACL 变量渲染成了空值或错误值。
3. 如何排查和解决这个异常和解决这个异常 #
- 检查仓库配置里的
canned_acl实际值。 - 对照当前 Elasticsearch 版本文档，确认该值是否是受支持的预定义 ACL。
- 如果配置来自自动化系统，检查模板变量是否被错误渲染。
- 去掉
canned_acl重新验证仓库，确认问题确实由 ACL 参数引起。
排查时要注意 #
- 这不是 IAM 权限不足，而是参数值在本地校验阶段就已经不合法。
- 大小写、短横线和下划线差异都可能导致不匹配。
- 如果你的桶策略已经满足需求，通常可以不显式设置
canned_acl。
4. 如何解决这个错误 #
常用修复思路 #
- 将
canned_acl改成 Elasticsearch 文档中明确支持的值。 - 如果并不需要对象级 ACL，删除该配置，改用桶策略和 IAM 权限控制。
- 更新自动化模板，避免把无效枚举写入仓库配置。
预防建议 #
- 对仓库配置做参数枚举校验，而不是直接透传字符串。
- 统一使用版本对应的官方文档作为配置来源。
- 把 S3 仓库创建和验证放进部署流水线，尽早暴露参数错误。
5. 小结 #
cannedACL is not valid: [cannedACL] 本质上是 S3 仓库参数校验失败。修复重点是改正 canned_acl 配置值，或直接去掉这项配置并回到更稳定的 IAM/桶策略控制方式。
相关错误 #
附：日志上下文 #
if (cur.toString().equalsIgnoreCase(cannedACL)) {
return cur;
}
} throw new BlobStoreException("cannedACL is not valid: [" + cannedACL + "]");
} ThreadPool getThreadPool() {
return threadPool;
}
