仓库权限与快照失败

做的事：本机真实注册一个指向本地目录的仓库，目录一开始真实可写，确认注册和_verify都能顺利通过

代码PUT /_snapshot/perm_repo {"type":"fs","settings":{"location":".../snap-repo-readonly"}} POST /_snapshot/perm_repo/_verify

验证：目录可写时，注册和_verify真实都顺利通过

注册: {"acknowledged":true}
_verify: {"nodes":{"...":{"name":"node-1"}}}

真实把这个仓库目录chmod成只读(555)，再做一次_verify和一次真实的快照，看两者会怎么失败

代码真实执行: chmod 555 .../snap-repo-readonly POST /_snapshot/perm_repo/_verify PUT /_snapshot/perm_repo/perm_snap?wait_for_completion=true {"indices":"perm_test"}

验证：两次操作真实都失败了，报错原文精确指向access_denied_exception，甚至列出了具体写不进去的文件名

_verify真实失败:
→ repository_verification_exception: "path is not accessible on master node"
→ caused_by: access_denied_exception: ".../tests-SQufS58XROOReDvnIUcdsA"

快照真实也失败:
→ snapshot_exception: "failed to update snapshot in repository"
→ caused_by: access_denied_exception: ".../meta-BLYbJMTnTDCR85kXK2Hezg.dat"
→ suppressed还列出了snap-*.dat和indices目录等好几个真实写不进去的具体位置

这组真实报错说明Elasticsearch对仓库权限问题的处理真实是透明且具体的：它不会只给一个笼统的"失败了"，而是真实把操作系统层面拒绝写入的那个具体文件路径原样暴露出来，_verify这个接口的价值正在于能在真正执行快照之前，用一次轻量级的写测试文件操作提前真实发现这类权限问题，不需要等到真正做快照的时候才暴露。

真实查这次失败快照的状态，看它是不是会在仓库里留下一个卡住的半成品

代码GET /_snapshot/perm_repo/perm_snap

验证：真实什么都没留下——404 snapshot_missing_exception，失败得足够彻底的快照不会留下任何残留记录

→ 404 snapshot_missing_exception: "[perm_repo:perm_snap] is missing"

真实把目录权限改回可写(755)，重新发起一次快照，确认问题解除后立刻恢复正常

代码真实执行: chmod 755 .../snap-repo-readonly PUT /_snapshot/perm_repo/perm_snap2?wait_for_completion=true {"indices":"perm_test"}

验证：权限恢复之后，新发起的快照真实立刻就成功了，没有任何额外的清理步骤

state: "SUCCESS"

收尾：真实清理仓库和测试索引

代码DELETE /_snapshot/perm_repo/perm_snap2 DELETE /_snapshot/perm_repo DELETE /perm_test

分步演示：从可写时的正常基线，到只读后_verify与快照的真实失败，再到权限恢复后的立刻正常

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。