# Elasticsearch S3 Snapshot Repository - Is s3:DeleteObject Mandatory for S3 Repository and SLM?

**URL:** <https://discuss.elastic.co/t/elasticsearch-s3-snapshot-repository-is-s3-deleteobject-mandatory-for-s3-repository-and-slm/388588>\
**Category:** Elasticsearch\
**Created:** [July 22, 2026, 6:01am UTC](https://discuss.elastic.co/t/elasticsearch-s3-snapshot-repository-is-s3-deleteobject-mandatory-for-s3-repository-and-slm/388588 "2026-07-22T06:01:51Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Shubham\_Khodpe](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/shubham_khodpe/32/147372_2.png) [@Shubham\_Khodpe](https://discuss.elastic.co/u/Shubham_Khodpe)\
**Post date:** [July 22, 2026, 6:01am UTC](https://discuss.elastic.co/t/elasticsearch-s3-snapshot-repository-is-s3-deleteobject-mandatory-for-s3-repository-and-slm/388588/1 "2026-07-22T06:01:51Z")

</div>

Hi Team,

We are configuring Elasticsearch 9.1.3 snapshots to an AWS S3 bucket using the repository-s3 plugin and would like to clarify whether `s3:DeleteObject` permission is mandatory.

## Environment

- Elasticsearch Version: 9.1.3
- Deployment: AWS EC2
- Authentication: IAM Role (Instance Profile)
- Snapshot Repository: S3
- Snapshot Lifecycle Management (SLM): Planned for daily automated backups

## IAM Permissions

The IAM Role currently has the following permissions:

- `s3:ListBucket`
- `s3:GetBucketLocation`
- `s3:GetObject`
- `s3:PutObject`

The client is **not willing to provide** :

- `s3:DeleteObject`  
due to their organization's security policy.

## Current Behaviour

Elasticsearch is able to:

- Authenticate successfully using the IAM Role.
- Connect to the S3 bucket.
- Upload temporary verification files (`master.dat`, `data-*.dat`) into the configured `base_path`.

However, repository verification fails with:  
repository\_verification\_exception  
[s3\_repository] cannot delete test data at [ELK\_BACKUP]

The detailed error indicates:  
AccessDenied  
is not authorized to perform:  
s3:DeleteObject

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/6/1/61d477c6b1fdf192b95c0f2ce56a9c8a818b8381.png)

The temporary verification files remain in the S3 bucket because Elasticsearch cannot delete them.

## Questions

1. Is `s3:DeleteObject` **mandatory** for configuring an S3 snapshot repository?

2. Is there any supported way to configure the repository **without** granting `s3:DeleteObject` permission?

3. Can snapshots be created successfully if repository verification cannot delete temporary verification files?

4. Is there any Elasticsearch setting to skip repository cleanup or disable deletion of temporary verification files?

5. If `s3:DeleteObject` is not granted, what functionality will be affected?  
Repository verification  
Snapshot creation  
Snapshot restore  
Snapshot Lifecycle Management (SLM) retention  
Repository cleanup

Our objective is to enable daily automated S3 backups while complying with the client's security policy, which currently allows only:

- `s3:ListBucket`
- `s3:GetBucketLocation`
- `s3:GetObject`
- `s3:PutObject`

Any guidance or best practices for this scenario would be greatly appreciated.

---

<div class="post-metadata">

**Author:** ![davidwarner44](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidwarner44/32/147872_2.png) [@davidwarner44](https://discuss.elastic.co/u/davidwarner44)\
**Post date:** [July 22, 2026, 7:53am UTC](https://discuss.elastic.co/t/elasticsearch-s3-snapshot-repository-is-s3-deleteobject-mandatory-for-s3-repository-and-slm/388588/2 "2026-07-22T07:53:49Z")

</div>

`s3:DeleteObject` is required for normal Elasticsearch S3 snapshot repository operation. Repository verification needs to create and delete test files, and SLM also needs delete access to remove expired snapshots. There’s no supported option to disable this cleanup, so the best approach is to allow `s3:DeleteObject` only on the specific backup bucket/prefix.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [July 22, 2026, 2:00pm UTC](https://discuss.elastic.co/t/elasticsearch-s3-snapshot-repository-is-s3-deleteobject-mandatory-for-s3-repository-and-slm/388588/3 "2026-07-22T14:00:26Z")

</div>

See also [Support immutable repository when using snapshot and restore along with point in time recovery · Issue #118187 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/issues/118187).

If you forbid `DeleteObject` then some things might actually even appear to work today. Definitely not supported tho, and it is not advisable to trust your snapshots to an unsupported configuration. So yes, in that sense, this permission is mandatory.

> The client is **not willing to provide** :
> 
> - `s3:DeleteObject`  
> due to their organization's security policy.

This sounds like [security theater](https://en.wikipedia.org/wiki/Security_theater) to me. If an attacker can `PutObject` then they can modify the contents of objects, rendering snapshots inaccessible (or even just subtly altering the data they contain) even if they cannot `DeleteObject`. The proper approach is to enable versioning, which avoids all these problems and eliminates any security concerns around `DeleteObject` calls too.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [July 22, 2026, 2:51pm UTC](https://discuss.elastic.co/t/elasticsearch-s3-snapshot-repository-is-s3-deleteobject-mandatory-for-s3-repository-and-slm/388588/4 "2026-07-22T14:51:27Z")

</div>

> [@DavidTurner](#):
>
> This sounds like [security theater](https://en.wikipedia.org/wiki/Security_theater) to me.

What a cool expression, which is new to me, tho the concept is very far from new.

Every day's a school day!

---

<div class="post-metadata">

**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\
**Post date:** [July 22, 2026, 2:55pm UTC](https://discuss.elastic.co/t/elasticsearch-s3-snapshot-repository-is-s3-deleteobject-mandatory-for-s3-repository-and-slm/388588/5 "2026-07-22T14:55:19Z")

</div>

> [@Shubham\_Khodpe](#):
>
> - Authentication: IAM Role (Instance Profile)
> - Snapshot Repository: S3

Does this IAM role has permissions to other buckets as well?

Not willing to provide the `s3:DeleteObject` permission would make sense if this role has access to multiple buckets, like buckets used to store data that are being ingested in the cluster.

In this case I think you could use an access\_key/access\_secret with the required permissions for only the snapshot bucket.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [July 22, 2026, 3:18pm UTC](https://discuss.elastic.co/t/elasticsearch-s3-snapshot-repository-is-s3-deleteobject-mandatory-for-s3-repository-and-slm/388588/6 "2026-07-22T15:18:44Z")

</div>

> [@leandrojmp](#):
>
> In this case I think you could use an access\_key/access\_secret with the required permissions for only the snapshot bucket.

I think it'd be preferable to set up the IAM role with finer-grained permissions, forbidding all write access to the ingested data source bucket/path while allowing all the required permissions on the snapshot bucket/path. Managing fixed keys is kinda painful, you have to arrange to rotate them, and they're much easier to leak than the credentials used for an IAM role.
