Table of Contents
The procedures on this page cover deploying MinIO in a Single-Node Single-Drive (SNSD) configuration for early development and evaluation. This mode was previously called Standalone Mode or ‘filesystem’ mode.
Starting with RELEASE.2022-06-02T02-11-04Z, MinIO implements a zero-parity erasure coded backend for single-node single-drive deployments. This feature allows access to erasure coding dependent features without the requirement of multiple drives.
MinIO only starts in SNSD mode if the storage volume or path is empty or only contain files generated by a previous SNSD deployment. See minio-snsd-pre-existing-data for more complete documentation on MinIO startup behavior in SNSD mode.
For extended development or production environments, deploy MinIO in Distributed Mode. See Deploy MinIO in Distributed Mode for more information.
MinIO startup behavior depends on the the contents of the specified storage volume or path. The server checks for both MinIO-internal backend data and the structure of existing folders and files. The following table lists the possible storage volume states and MinIO behavior:
Storage Volume State |
Behavior |
|---|---|
Empty with no files, folders, or MinIO backend data |
MinIO starts in SNSD mode and creates the zero-parity backend |
Existing SNSD zero-parity objects and MinIO backend data |
MinIO resumes in SNSD mode |
Existing filesystem folders, files, and MinIO backend data |
MinIO resumes in the legacy filesystem (“Standalone”) mode with no erasure-coding features |
Existing filesystem folders, files, but no MinIO backend data |
MinIO returns an error and does not start |
The following procedure deploys MinIO consisting of a single MinIO server and a single drive or storage volume.
Network File System Volumes Break Consistency Guarantees
MinIO’s strict read-after-write and list-after-write consistency
model requires local disk filesystems (xfs, ext4, etc.).
MinIO cannot provide consistency guarantees if the underlying storage volumes are NFS or a similar network-attached storage volume.
For deployments that require using network-attached storage, use NFSv4 for best results.
Visit https://min.io/download and select
the tab most relevant to your use case. Follow the displayed instructions to
download the minio binary to your local machine. The example instructions
use the /data folder by default. You can create or change this folder
as necessary for your deployment. The minio process must have
full access to the specified folder and all of its subfolders.
The minio server process prints its output to the system console, similar
to the following:
Hybrid Cloud Object Storage
Baremetal
Erasure Code Calculator
Reference Hardware
API: http://192.0.2.10:9000 http://127.0.0.1:9000
RootUser: minioadmin
RootPass: minioadmin
Console: http://192.0.2.10:9001 http://127.0.0.1:9001
RootUser: minioadmin
RootPass: minioadmin
Command-line: https://docs.min.io/docs/minio-client-quickstart-guide
$ mc alias set myminio http://192.0.2.10:9000 minioadmin minioadmin
Documentation: https://docs.min.io
WARNING: Detected default credentials 'minioadmin:minioadmin', we recommend that you change these values with 'MINIO_ROOT_USER' and 'MINIO_ROOT_PASSWORD' environment variables
Open your browser to any of the listed Console addresses to open the MinIO Console and log in with the RootUser and RootPass. You can use the MinIO Console for performing administration on the MinIO server.
For applications, use the API addresses to access the MinIO server and perform S3 operations.
The following steps are optional but recommended for further securing the MinIO deployment.
MinIO supports enabling Transport Layer Security (TLS) 1.2+
automatically upon detecting a x.509 private key (private.key) and public
certificate (public.crt) in the MinIO certs directory:
For Linux/MacOS: ${HOME}/.minio/certs
For Windows: %%USERPROFILE%%\.minio\certs
You can override the certificate directory using the
minio server --certs-dir commandline argument.
Issue the following command to start the minio server with non-default
credentials. The table following this command breaks down each portion of the
command:
export MINIO_ROOT_USER=minio-admin
export MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME
#export MINIO_SERVER_URL=https://minio.example.net
minio server /data --console-address ":9001"
The example command breaks down as follows:
The access key for the root user. Replace this value with a unique, random, and long string. |
|
The corresponding secret key to use for the root user. Replace this value with a unique, random, and long string. |
|
The URL hostname the MinIO Console uses for connecting to the MinIO server. This variable is required if specifying TLS certificates which do not contain the IP address of the MinIO Server host as a Subject Alternative Name. Specify a hostname covered by one of the TLS certificate SAN entries. |
|
|
The path to each disk on the host machine. See MinIO writes objects to the specified directory as is and without Erasure Coding. Any other application accessing that directory can read and modify stored objects. |
|
The static port on which the embedded MinIO Console listens for incoming connections. Omit to allow MinIO to select a dynamic port for the MinIO Console.
With dynamic port selection, browsers opening the root node hostname
|
You may specify other environment variables as required by your deployment.
Open your browser to the DNS name or IP address corresponding to the
container and the MinIO Console port. For example,
https://127.0.0.1:9001.
Log in with the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD from the previous step.
You can use the MinIO Console for general administration tasks like Identity and Access Management, Metrics and Log Monitoring, or Server Configuration. Each MinIO server includes its own embedded MinIO Console.
Applications should use the https://HOST-ADDRESS:9000 to perform S3
operations against the MinIO server.
The following procedure deploys a single MinIO container with a single drive.
The procedure uses Podman for running the MinIO container in rootfull mode. Configuring for rootless mode is out of scope for this procedure.
Network File System Volumes Break Consistency Guarantees
MinIO’s strict read-after-write and list-after-write consistency
model requires local disk filesystems (xfs, ext4, etc.).
MinIO cannot provide consistency guarantees if the underlying storage volumes are NFS or a similar network-attached storage volume.
For deployments that require using network-attached storage, use NFSv4 for best results.
MinIO reads configuration values from environment variables. MinIO supports
reading these environment variables from /run/secrets/config.env. Save
the config.env file as a Podman secret and
specify it as part of running the container.
Create a file config.env using your preferred text editor and enter the
following environment variables:
export MINIO_ROOT_USER=minio-admin
export MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME
#export MINIO_SERVER_URL=https://minio.example.net
Create the Podman secret using the config.env file:
sudo podman secret create config.env config.env
The following table details each environment variable set in config.env:
The access key for the root user. Replace this value with a unique, random, and long string. |
|
The corresponding secret key to use for the root user. Replace this value with a unique, random, and long string. |
|
The URL hostname the MinIO Console uses for connecting to the MinIO server. This variable is required if specifying TLS certificates which do not contain the IP address of the MinIO Server host as a Subject Alternative Name. Specify a hostname covered by one of the TLS certificate SAN entries. |
You may specify other environment variables as required by your deployment.
MinIO supports enabling Transport Layer Security (TLS) 1.2+
automatically upon detecting a x.509 private key (private.key) and public
certificate (public.crt) in the MinIO certs directory:
Create a Podman secret pointing to the x.509
private.key and public.crt to use for the container.
sudo podman secret create private.key /path/to/private.key
sudo podman secret create public.crt /path/to/public.crt
You can optionally skip this step to deploy without TLS enabled. MinIO strongly recommends against non-TLS deployments outside of early development.
Issue the following command to start the MinIO server in a container:
sudo podman run -p 9000:9000 -p 9001:9001 \
-v /data:/data \
--secret private.key \
--secret public.crt \
--secret config.env \
minio/minio server /data \
--console-address ":9001" \
--certs-dir "/run/secrets/"
The example command breaks down as follows:
|
Exposes the container internal port Port Port |
|
Mounts a local volume to the container at the specified path. |
|
Mounts a secret to the container. The specified secrets correspond to the following:
|
|
The path to the container volume in which the See |
|
The static port on which the embedded MinIO Console listens for incoming connections. Omit to allow MinIO to select a dynamic port for the MinIO Console.
With dynamic port selection, browsers opening the root node hostname
|
|
Directs the MinIO server to use the |
Open your browser to the DNS name or IP address corresponding to the
container and the MinIO Console port. For example,
https://127.0.0.1:9001.
Log in with the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD from the previous step.
You can use the MinIO Console for general administration tasks like Identity and Access Management, Metrics and Log Monitoring, or Server Configuration. Each MinIO server includes its own embedded MinIO Console.
Applications should use the https://HOST-ADDRESS:9000 to perform S3
operations against the MinIO server.
This work is licensed under a Creative Commons Attribution 4.0 International License.
©2020-Present, MinIO, Inc.
