Welcome to the upcoming version of the MinIO Documentation! The content on this page is under active development and may change at any time. If you can't find what you're looking for, check our legacy documentation. Thank you for your patience.



A user is an identity with associated privileges on a MinIO deployment. Each user consists of a unique access key (username) and corresponding secret key (password). The access key and secret key support authentication on the MinIO deployment, similar to a username and password. Clients must specify both a valid access key (username) and the corresponding secret key (password) to access the MinIO deployment.

Each user can have one or more assigned policies that explicitly list the actions and resources to which the user is allowed or denied access. A user can also have membership in a group, where the user inherits any policies assigned to the group. Policies support authorization on the MinIO deployment, such that clients can only access a resource or operation if the user’s assigned and inherited policies explicitly grant. MinIO by default denies access to any resource or operation not explicitly allowed by a user’s assigned or inherited policies.

For example, consider the following table of users. Each user is assigned a built-in policy or a supported action. The table describes a subset of operations a client could perform if authenticated as that user:





readwrite on finance bucket
readonly on audit bucket
PUT and GET on finance bucket.
PUT on audit bucket


readonly on audit bucket

GET on audit bucket



All mc admin commands.

Each user can access only those resources and operations which are explicitly granted by the built-in role. MinIO denies access to any other resource or action by default.

Deny overrides Allow

MinIO follows the IAM policy evaluation rules where a Deny rule overrides Allow rule on the same action/resource. For example, if a user has an explicitly assigned policy with an Allow rule for an action/resource while one of its groups has an assigned policy with a Deny rule for that action/resource, MinIO would apply only the Deny rule.

For more information on IAM policy evaluation logic, see the IAM documentation on Determining Whether a Request is Allowed or Denied Within an Account.

root User

MinIO deployments have a root user with access to all actions and resources on the deployment. When a minio server first starts, it sets the root user credentials by checking the value of the following environment variables:

Rotating the root user credentials requires updating either or both variables for all MinIO servers in the deployment.

When specifying the root access key and secret key, consider using long, unique, and random strings. Exercise all possible precautions in storing the access key and secret key, such that only known and trusted individuals who require superuser access to the deployment can retrieve the root credentials.

  • MinIO strongly discourages using the root user for regular client access regardless of the environment (development, staging, or production).

  • MinIO strongly recommends creating users such that each client has access to the minimal set of actions and resources required to perform their assigned workloads.

If these variables are unset, minio defaults to minioadmin and minioadmin as the access key and secret key respectively. MinIO strongly discourages use of the default credentials regardless of deployment environment.

MinIO RELEASE.2021-04-22T15-44-28Z and later deprecates the following variables used for setting or updating root user credentials:

Create a User

Use the mc admin user add command to create a new user on the MinIO deployment:

   mc admin user add ALIAS ACCESSKEY SECRETKEY
  • Replace ALIAS with the alias of the MinIO deployment.

  • Replace ACCESSKEY with the access key for the user. MinIO allows retrieving the access key after user creation through the mc admin user info command.

  • Replace SECRETKEY with the secret key for the user. MinIO does not provide any method for retrieving the secret key once set.

Specify a unique, random, and long string for both the ACCESSKEY and SECRETKEY. Your organization may have specific internal or regulatory requirements around generating values for use with access or secret keys.

After creating the user, use mc admin policy set to associate a Policies to the new user. You can also use mc admin group add to add the user to a Groups.

Delete a User

Use the mc admin user remove command to remove a user on a MinIO deployment:

mc admin user remove ALIAS USERNAME
  • Replace ALIAS with the alias of the MinIO deployment.

  • Replace USERNAME with the name of the user to remove.