MinIO server allows WORM for specific objects or by configuring a bucket with default object lock configuration that applies default retention mode and retention duration to all objects. This makes objects in the bucket immutable i.e. delete of the version are not allowed until an expiry specified in the bucket's object lock configuration or object retention.

export MINIO_ROOT_PASSWORD=minio123
minio server ~/export
```

> The KES instance at `https://play.min.io:7373` is meant to experiment and provides a way to get started quickly.
> Note that anyone can access or delete master keys at `https://play.min.io:7373`. You should run your own KES
> instance in production.

## Configuration Guides

A typical MinIO deployment that uses a KMS for SSE-S3 looks like this:

```

        }
    ]
}
```

### 3.3 Automatic removal of delete markers with no other versions

When an object has only one version as a delete marker, the latter can be automatically removed after a certain number of days using the following configuration:

```
{
    "Rules": [
        {
            "ID": "Removing all delete markers",
            "Expiration": {
                "DeleteMarker": true

### Expiry or removal events

An object that is in transition tier will be deleted once the object hits expiry date or if removed via `mc rm` (`mc rm --vid` in the case of delete of a specific object version). Other rules specific to legal hold and object locking precede any lifecycle rules.

### Additional notes

Tiering and lifecycle transition are applicable only to erasure/distributed MinIO.

- ObjectType (default)
- LegacyObjectType (preserves existing deployments and older xl.json format)
- DeleteMarker (a versionId to capture the DELETE sequences implemented primarily for AWS spec compatibility)

|:-------------------:|:----------|
| get                 | yes       |
| put                 | yes       |
| ls                  | yes       |
| mkdir               | yes       |
| rmdir               | yes       |
| delete              | yes       |
| append              | no        |
| rename              | no        |

MinIO supports following FTP/SFTP based protocols to access and manage data.

# PyInstaller
#  Usually these files are written by a python script from a template
#  before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec

# Installer logs
pip-log.txt
pip-delete-this-directory.txt

# Unit test / coverage reports
htmlcov/
.tox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
.hypothesis/
.pytest_cache/

# Translations
*.mo

> Without a 'Complete' status any 'Active' or 'Draining' pool(s) are not allowed to be removed once configured.

## NOTE

- Empty delete markers (such as for objects with no other successor versions) do not transition to the new pool to avoid creating empty metadata on the other pool(s). If you believe transitioning empty delete markers is required, open a GitHub issue.

## TODO

The main limitation is that to update or delete content of a file inside a ZIP file the entire ZIP file must be replaced.

## How to enable S3 ZIP behavior ?

Ensure to set the following header `x-minio-extract` to `true` in your S3 requests.

Once the user is successfully created you can now apply the `userManage` policy for this user.

```
mc admin policy attach myminio userManager --user=admin1
```

This admin user will then be allowed to perform create/delete user operations via `mc admin user`

### 3. Configure `mc` and create another user user1 with attached policy user1policy

```
mc alias set myminio-admin1 http://localhost:9000 admin1 admin123 --api s3v4