著者 MinIOをUbuntu 24.04のVPSで自前運用する方法
Ubuntu 24.04のVPS 1台でMinIOを構築します。検証済みバイナリ、systemd、mc、presigned URL、resticの設定と、2026年7月時点の更新停止リスクを解説します。
MinIOでセルフホスト型オブジェクトストレージを使う利点
MinIOは、Amazon S3 APIに対応したセルフホスト型オブジェクトストレージです。resticまたは任意のS3 SDKを自分のサーバーに接続し、エンドポイント設定を1か所変更するだけで、クライアントからは違いが分かりません。このガイドでは、Ubuntu 24.04上に単一ノードを構築します。検証済みバイナリ、専用system user、root認証情報をunit fileの外部で管理するsystemd unit、そしてresticがバックアップ先として使用するbucketを設定します。
S3（simple storage service）は、filesystemではなくHTTP APIです。bucket内のkeyに対してオブジェクトをPUTし、GETして取得します。部分的な書き込みやrenameはありません。バックアップツールにこのモデルが適しているのは、オブジェクトが完全な状態で到着するか、到着しないかのどちらかだからです。
1つのノードには、データのコピーが1つだけ保存されます。これが選択するトレードオフです。VPSの料金で、自分が管理するS3エンドポイントを利用できます。一方で、故障したディスクの交換やサーバーソフトウェアへのパッチ適用など、クラウドプロバイダーが担っていたすべての作業も自分で行う必要があります。終盤のセクションでは、このトレードオフが適している状況を明確に説明します。
2026年7月時点のMinIOコミュニティエディションの状況
この後の構築手順に進む前に、ここを確認してください。最近、状況が変わりました。2025年5月、MinIOはコミュニティエディションのWebコンソールから管理機能を削除しました。ブラウザーに残っているのはオブジェクトブラウザーです。そのため、バケットとアクセスキーは代わりにmcコマンドラインクライアントで管理します。
その後、2025年にMinIOはコンパイル済みのコミュニティバイナリの公開を停止しました。現在、プロジェクトのREADMEには、コミュニティエディションはソースコードのみで配布されると記載されています。以前のダウンロードURLは引き続き機能します。2026年7月時点では、サーバービルドRELEASE.2025-09-07T16-13-09ZとクライアントビルドRELEASE.2025-08-13T08-35-41Zが提供されており、それより新しいコミュニティビルドはありません。したがって、以下のバイナリは実在し、実行できますが、更新されていません。2025年9月以降に公開されたセキュリティ修正は含まれていません。
この事実が、このガイドの以降の構成を決めます。そのため、ここでのMinIOは127.0.0.1で待ち受け、管理するプロキシを介してのみインターネットに接続します。修正を追跡したい場合は、ソースコードからビルドしてください。ベンダーのREADMEにはgo install github.com/minio/minio@latestという単一のコマンドが記載されています。このコマンドにはGoツールチェーンが必要で、バイナリを~/go/bin/minioに書き込みます。そのバイナリを/usr/local/bin/minioにインストールすれば、ここでの他の手順はすべて変わりません。
MinIO binaryをインストールし、ダウンロードを検証する
固定したリリースと、公開されているチェックサムをダウンロードします。-f flagを指定すると、HTTPエラー時にcurlがエラーページを指定した名前で保存せず、失敗します。これにより、404ページをインストールして実行できない理由が分からなくなる事態を防げます。
cd /tmp
REL=RELEASE.2025-09-07T16-13-09Z
curl -fsSL "https://dl.min.io/server/minio/release/linux-amd64/archive/minio.$REL" -o minio
curl -fsSL "https://dl.min.io/server/minio/release/linux-amd64/archive/minio.$REL.sha256sum" -o minio.sha256sum2つのハッシュを比較します。比較するのはハッシュだけです。
published=$(awk '{print $1}' minio.sha256sum)
downloaded=$(sha256sum minio | awk '{print $1}')
[ "$published" = "$downloaded" ] && echo "checksum ok"ここでsha256sum -c minio.sha256sumを使用しないでください。そのファイルのハッシュの後に記載されたラベルはminio.RELEASE.2025-09-07T16-13-09Zです。ダウンロードしたファイル名はminioなので、-cは存在しないファイルを探します。No such file or directoryを報告した後、WARNING: 1 listed file could not be readを報告します。これはダウンロードが破損しているように見えますが、実際には破損していません。ラベルは名前にすぎません。保証を担うのはハッシュです。
この検証で何が証明されるかを明確にします。binaryとハッシュは、同じvendorから同じ接続経由で取得されています。そのため、一致すれば、ダウンロードが完全であり、転送中に破損または変更されていないことが証明されます。ただし、vendorが信頼できることは証明されません。これは別の問題であり、sha256sum commandで解決することはできません。
sudo install -o root -g root -m 755 minio /usr/local/bin/minio
minio --versionminio --versionはminio version RELEASE.2025-09-07T16-13-09Zに続けて、いくつかのbuild行を表示します。ここでPermission deniedが表示される場合はmodeが誤っています。command not foundが表示される場合は、/usr/local/binがPATHにありません。
システムユーザーとデータディレクトリを作成する
MinIOはネットワークからのアップロードを受け付けるため、rootとして実行しないでください。ホームディレクトリとログインシェルを持たないアカウントを割り当てます。
sudo groupadd -r minio-user
sudo useradd -M -r -g minio-user -s /usr/sbin/nologin minio-user
sudo mkdir -p /var/lib/minio/data
sudo chown -R minio-user:minio-user /var/lib/minio
sudo chmod 750 /var/lib/minio-rはUIDが1000未満のシステムアカウントを作成します。これにより、人が使用する範囲から分離できます。-Mはホームディレクトリの作成を省略します。ログインしないアカウントには、保持するホームディレクトリがないためです。id minio-userで結果を確認し、stat -c '%U %a' /var/lib/minioでも確認します。後者はminio-user 750を出力するはずです。
データディレクトリは、そのユーザーが読み取れるだけでなく、書き込める必要があります。初回起動時、MinIOはボリューム内に.minio.sysディレクトリを作成して独自の設定を保存します。そのため、ディレクトリの所有者がrootだと、MinIOは起動中に終了し、メッセージの末尾にpermission deniedと表示されます。この方法で実行するすべてのサービスに同じ規則が適用されます。VPSでの最小権限のサービスユーザーで詳しく説明しています。
root の認証情報を環境ファイルに格納する
root の認証情報ではすべてのバケットにアクセスできるため、全ユーザーから読み取り可能な unit file に記載してはいけません。まず適切なモードでファイルを作成し、その後で内容を書き込みます。これにより、パスワードが読み取り可能なファイルに一瞬でも存在することを防げます。
sudo install -o root -g root -m 600 /dev/null /etc/default/minio
printf 'MINIO_ROOT_USER=minio-root\nMINIO_ROOT_PASSWORD=%s\nMINIO_VOLUMES="/var/lib/minio/data"\nMINIO_OPTS="--address 127.0.0.1:9000 --console-address 127.0.0.1:9001"\n' "$(openssl rand -base64 24)" | sudo tee /etc/default/minio > /dev/null
sudo sed -n 's/^MINIO_ROOT_PASSWORD=//p' /etc/default/miniotee は既存のファイルを再作成せずに切り詰めるため、モードは 600 のままで、所有者も root のままです。これは意図した動作です。systemd は権限を User= に落とす前に、root として EnvironmentFile を読み取ります。そのため、サービスアカウントが自身の認証情報を読み取る必要はありません。サービスの起動後は、sudo -u minio-user cat /etc/default/minio で確認できます。このコマンドは Permission denied を出力する必要があります。
起動する前に、MinIO の 2 つの動作を把握しておいてください。環境に MINIO_ROOT_USER も MINIO_ROOT_PASSWORD もない場合、MinIO は起動を拒否しません。文書化されたデフォルト認証情報 minioadmin:minioadmin で起動します。これはスキャナーが最初に試す認証情報の組み合わせであり、その状態でも完全に正常に動作しているように見えます。8 文字未満のパスワードは別の扱いになります。MinIO は起動時に、認証情報が無効であることを示すエラーを出して終了します。access key には 3 文字以上、secret key には 8 文字以上が必要だからです。
MINIO_VOLUMES はデータパスで、MINIO_OPTS にはフラグを指定します。127.0.0.1 に bind すると、この VPS の外部から S3 API にアクセスできなくなります。これは適切なデフォルト設定です。後で、証明書を保持する proxy 経由で意図的に公開します。
systemd ユニットを作成する
/etc/systemd/system/minio.service を作成します。
[Unit]
Description=MinIO object storage
Documentation=https://github.com/minio/minio
Wants=network-online.target
After=network-online.target
[Service]
User=minio-user
Group=minio-user
EnvironmentFile=/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_VOLUMES $MINIO_OPTS
Restart=always
RestartSec=5
LimitNOFILE=65536
NoNewPrivileges=true
[Install]
WantedBy=multi-user.targetEnvironmentFile の先頭に - がないのは、タイプミスではなく意図的な設計です。ハイフンがあると、systemd はファイルが存在しなくても無視して MinIO を起動します。そのため、ファイルを削除した場合やパスを誤記した場合、minioadmin:minioadmin で実行されるサーバーが通知なしに起動します。ハイフンがない場合、ファイルが存在しないと MinIO が実行される前にユニットが失敗し、journalctl -u minio に Failed to load environment files: No such file or directory が表示されます。起動を拒否するユニットのほうが、デフォルトパスワードを使用してサーバーが気付かないまま接続を受け入れるより、容易に発見できます。
$MINIO_VOLUMES と $MINIO_OPTS を引用符で囲んでいないのは意図的です。systemd は、引用符で囲んでいない変数を空白で分割し、個別の引数にするためです。これにより、MINIO_OPTS の4つの単語が minio server への4つの引数になります。LimitNOFILE=65536 はファイルディスクリプターの上限を引き上げます。開いている接続とデータファイルはそれぞれ1つのディスクリプターを消費するため、デフォルト値の1024は負荷が高いと不足します。
sudo systemctl daemon-reload
sudo systemctl enable --now minio
systemctl is-active minio
curl -fsS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:9000/minio/health/liveis-active は active を出力し、ヘルスエンドポイントは 200 を返すはずです。journalctl -u minio -n 20 --no-pager には、サーバーがリッスンしているAPIアドレスが表示されます。ユニットが再起動を繰り返すと、systemd は再試行を停止し、Start request repeated too quickly をログに記録します。これは、MinIO が試行のたびに終了していることを意味します。原因はそのメッセージより上の行に出力されるため、上方向に読み進めてください。
分離を強化するには、[Service] セクションに ProtectSystem=full と ProtectHome=true を追加します。どちらもホストカーネルの mount namespace を必要とします。OpenVZ や LXC など、ホストカーネルを共有するコンテナ仮想化環境では失敗することがあり、その場合、ユニットは status=226/NAMESPACE を報告します。この2行を削除すると起動します。ユニット自体は通常のもので、残りのディレクティブについては VPS での systemd サービスとタイマーで説明しています。
mcをインストールしてラウンドトリップを確認する
MinIOクライアントはmcです。apt install mcでインストールしないでください。そのパッケージはMidnight Commanderという、MinIOとは無関係のファイルマネージャーです。
cd /tmp
curl -fsSL https://dl.min.io/client/mc/release/linux-amd64/mc -o mc
curl -fsSL https://dl.min.io/client/mc/release/linux-amd64/mc.sha256sum -o mc.sha256sum
[ "$(awk '{print $1}' mc.sha256sum)" = "$(sha256sum mc | awk '{print $1}')" ] && echo "checksum ok"
sudo install -o root -g root -m 755 mc /usr/local/bin/mcサーバーをエイリアスとして登録し、そのサーバー経由でオブジェクトを移動します。
MINIO_PASS=$(sudo sed -n 's/^MINIO_ROOT_PASSWORD=//p' /etc/default/minio)
mc alias set local http://127.0.0.1:9000 minio-root "$MINIO_PASS"
mc mb local/backups
echo "hello object storage" > /tmp/hello.txt
mc cp /tmp/hello.txt local/backups/hello.txt
mc ls local/backups
mc cat local/backups/hello.txtmc lsはhello.txtをサイズ付きで一覧表示し、mc catはhello object storageを出力します。このラウンドトリップがサーバーの動作を実際に証明します。他のすべてのクライアントと同じ署名付きS3リクエストを送信するためです。別の方法でも確認する場合は、mc admin info localでサーバーの状態を表示できます。
まだサーバーが空の状態で、ここでもう1つ確認します。
mc alias set defaultcheck http://127.0.0.1:9000 minioadmin minioadminこのコマンドは失敗する必要があります。成功する場合、環境ファイルがプロセスに渡っておらず、サーバーがデフォルトの認証情報で実行されています。ほかの処理がマシンにアクセスする前に修正してください。
mcはエイリアスを~/.mc/config.jsonにプレーンテキストで保存するため、認証情報はコマンドを実行したユーザーのホームディレクトリに置かれます。sudoでmcを実行すると、rootの認証情報が/root/.mc/config.jsonに保存されます。rootエイリアスは1つの管理者アカウントに限定し、各アプリケーションには専用のキーを割り当ててください。
presigned URLで1つのオブジェクトを渡す
presigned URLは、署名と有効期限が付いた通常のHTTPSリンクです。このリンクを持つ人は、アカウントやクライアントなしで、その1つのオブジェクトを取得できます。
mc share download --expire 12h local/backups/hello.txt出力には、クエリ文字列内にX-Amz-SignatureとX-Amz-Expiresが含まれます。この出力には、注意すべき点が2つあります。リンクは、使用したaliasのendpointから作成されます。そのため、127.0.0.1上のaliasで生成したリンクは、このマシンからしか開けません。送信するリンクには、公開ホスト名を指定した別のaliasを作成してください。もう1つは、revokeボタンがないことです。署名は有効期限まで有効なため、設定できる唯一の制御方法は短い有効期限です。S3の署名形式で指定できる最大期間は7日です。
restic専用のkeyとbucketを作成する
rootの認証情報ではすべてのbucketを読み取り、削除できます。そのため、バックアップジョブでrootの認証情報を使用してはいけません。bucket、対象のbucketだけに適用するpolicy、およびそれ以外の権限を持たないuserを作成します。
mc mb local/restic
cat > /tmp/restic-rw.json <<'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket", "s3:GetBucketLocation"],
"Resource": ["arn:aws:s3:::restic"]
},
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
"Resource": ["arn:aws:s3:::restic/*"]
}
]
}
EOF
RESTIC_KEY=$(openssl rand -base64 24)
mc admin policy create local restic-rw /tmp/restic-rw.json
mc admin user add local restic-backup "$RESTIC_KEY"
mc admin policy attach local restic-rw --user restic-backupMinIOには組み込みのreadwritepolicyがあります。これを使えばコマンドを1つ減らせますが、サーバー上のすべてのbucketへの完全なアクセス権が付与されます。上記のpolicyでは、意図的にbucket名を2回指定しています。1回目はbucketの一覧表示に必要なarn:aws:s3:::resticとして、2回目はbucket内のobjectに必要なarn:aws:s3:::restic/*として指定しています。S3ではbucketとそのobjectは別々のresourceです。そのため、どちらか一方だけを指定したpolicyは、clientの問題に見える形で失敗します。
信頼する前に、制限をテストします。
mc alias set resticuser http://127.0.0.1:9000 restic-backup "$RESTIC_KEY"
mc ls resticuser/restic
mc ls resticuser/backups最初のlsは成功し、2つ目はAccess Deniedで失敗します。テストしていないpolicyは推測にすぎません。
次に、resticからbucketを使用します。resticは標準のAWS環境変数からS3の認証情報を読み取るため、restic固有の認証情報ファイルは必要ありません。
sudo apt install -y restic
export AWS_ACCESS_KEY_ID=restic-backup
export AWS_SECRET_ACCESS_KEY="$RESTIC_KEY"
restic -r s3:http://127.0.0.1:9000/restic init
restic -r s3:http://127.0.0.1:9000/restic backup /etc
restic -r s3:http://127.0.0.1:9000/restic snapshotsrestic initではrepositoryのpasswordを要求されます。このpasswordによってrepositoryが暗号化されるため、MinIOに保存されるのは常にciphertextだけです。passwordを失うと、バックアップも失われます。systemd timerで起動する処理には入力用のterminalがありません。そのため、スケジュールされたバックアップではRESTIC_PASSWORD_FILEをmode 600のファイルに設定します。
上記のどのコマンドよりも重要な配置ルールがあります。保護対象のdataと同じVPS上にrestic repositoryを置いても、防げるのは不正なrmだけです。それ以外の障害からは保護できません。MinIO nodeは別のマシンに配置してください。できれば別のregionに配置します。VPS上のresticバックアップでは、この構成を前提にスケジュール設定と保持期間を説明しています。
nginxでTLSを終端する
MinIOはlocalhostで動作するため、公開側の窓口はnginxです。まず、certbotとnginxでLet's Encrypt証明書を取得するの説明に従って証明書を発行し、その後、次のserver blockを使用します。
server {
listen 443 ssl;
server_name s3.example.com;
ignore_invalid_headers off;
client_max_body_size 0;
proxy_buffering off;
proxy_request_buffering off;
location / {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 300;
proxy_http_version 1.1;
proxy_set_header Connection "";
chunked_transfer_encoding off;
proxy_pass http://127.0.0.1:9000;
}
}これらの行のいくつかは重要です。client_max_body_size 0はデフォルトの1 MBのbody制限を解除します。この制限があると、MinIOがリクエストを受け取る前に、1 MBを超えるアップロードが413 Request Entity Too Largeで拒否されます。proxy_request_buffering offはアップロードをそのまま転送します。デフォルト設定ではリクエスト全体を一時ファイルに保存するため、大きなオブジェクトではディスク容量が2倍必要になります。proxy_set_header Host $http_hostは見落としやすい設定です。S3の署名にはHostヘッダーが含まれるため、プロキシがこのヘッダーを書き換えると、アクセスログには通常どおりリクエストが到着しているように見えても、すべてのリクエストがSignatureDoesNotMatchで失敗します。
MinIOには公開名も設定してください。これにより、生成されるリンクがlocalhostではなくプロキシを指すようになります。
echo 'MINIO_SERVER_URL=https://s3.example.com' | sudo tee -a /etc/default/minio
sudo systemctl restart minioファイアウォール設定は最小限で構いません。SSHとHTTPSを許可し、ポート9000と9001にはルールを設定しないでください。127.0.0.1にバインドされたアドレスは、ファイアウォールの設定に関係なく別のマシンから到達できないためです。コマンドについては、VPSでのufwファイアウォールの基本を参照してください。
単一ノードの MinIO で十分な場合と、本格的な S3 が必要な場合
ここでいう単一ノードとは、パリティなしのドライブ1台構成です。MinIO の公式ドキュメントでは、この構成はテストや可用性要件のない小規模なワークロードに適していると説明されています。デプロイメント内に2つ目のコピーはないため、すべてのオブジェクトの耐久性は、1台の VPS ディスクの耐久性と同じです。バケットレプリケーションやオブジェクトロックなど、分散消失訂正コードバックエンドを前提とする機能は、複数ドライブのデプロイメント向けです。そのため、この構成で不変の保持ポリシーを提供できると約束してはいけません。
別のリージョンにある2台目の VPS 上の restic の保存先として適しています。また、開発作業や CI 成果物用の S3 エンドポイントにも適しています。バケットを失っても、再構築すれば済む場合に向いています。小規模アプリケーションのユーザーアップロードにも適しています。ただし、復旧計画を自分で管理し、実際にリストアをテストしていることが条件です。
契約や規制によってオブジェクトロックまたはマルチリージョンの耐久性が求められる場合は、マネージド S3 を選択してください。また、ディスクが満杯になったため03:00に対応担当者として呼び出される立場を避けたい場合も同様です。凍結されたビルドも、正直な理由の1つです。2026年7月時点で、事前コンパイル済みのコミュニティバイナリは2025年9月のもので、修正を受けていません。そのため、これを実行する場合はその状態を受け入れるか、ソースからビルドして自分でプロジェクトの更新に追従する必要があります。
よく問題になるため、1つ境界を明確にしておきます。オブジェクトストレージはデータベースではありません。書き込みのたびにオブジェクト全体が置き換えられるため、S3 バケット上の稼働中の SQL ファイルは低速で安全ではありません。データベースはローカルディスクに置き、代わりにバケットへバックアップしてください。VPS で SQLite を本番運用する方法では、この分離について説明しています。
失敗する状況と表示されるメッセージ
systemctl enable --now の直後にユニットが失敗します。 journalctl -u minio -n 30 --no-pager を確認してください。Failed to load environment files: No such file or directory は、ユニット内で /etc/default/minio が未設定であるか、そのパスのスペルが間違っていることを示します。permission denied で終わるメッセージは、サービスアカウントがデータディレクトリに書き込めないことを示します。そのため、stat -c '%U' /var/lib/minio/data の出力が minio-user になることを確認してください。
minioadmin:minioadmin がまだログインできます。 環境ファイルがプロセスに渡っていません。ユニットに EnvironmentFile=/etc/default/minio が含まれていることを確認し、sudo systemctl daemon-reload を実行してから、サービスを再起動してください。MinIO は起動時に root の認証情報を1回だけ読み取ります。そのため、再起動せずにこのファイルを編集しても反映されません。
起動時の Address already in use。 別のプロセスが port 9000 を使用しています。MinIO の port を変更する前に、sudo ss -ltnp | grep :9000 で使用中のプロセスを確認してください。
proxy 経由で 1 MB を超えるアップロードが失敗します。 nginx が 413 Request Entity Too Large を返し、MinIO はリクエストを受信していません。server block に client_max_body_size 0 を設定してください。
SignatureDoesNotMatch。 secret key が間違っているか、client と MinIO の間にある何らかの要素が、署名の対象となる Host header を書き換えています。
RequestTimeTooSkewed。 client または server の時刻が間違っています。すべての S3 リクエストには timestamp が含まれており、15 分の範囲外では拒否されます。timedatectl を確認し、時刻同期が有効であることを確認してください。
存在することが分かっている bucket で Access Denied が発生します。 key の対象が別の bucket になっています。mc admin policy info local restic-rw で policy が実際に許可している内容を表示し、resource 行の bucket 名と比較してください。
FAQ
単一ノードの MinIO で実際のバックアップに十分ですか？
データとは別のマシンで動作し、保護対象のデータを保存する restic の保存先としては十分です。ただし、唯一のコピーとしては不十分です。単一ドライブ構成にはパリティがないため、MinIO 内に2つ目のコピーは存在しません。その VPS のディスクでデータが失われると、オブジェクトも失われます。別の場所に2つ目の保存先を用意し、プロセスが機能することを確認するため、少なくとも1回は両方から復元してください。
MinIO のチェックサムファイルで sha256sum -c が失敗するのはなぜですか？
そのファイルのハッシュの後にあるラベルはリリース名の minio.RELEASE.2025-09-07T16-13-09Z ですが、通常、ダウンロードしたファイルの名前は minio だからです。sha256sum -c はチェックサムファイル内に記載された名前のファイルを探しますが、そのファイルが見つからないため、No such file or directory と WARNING: 1 listed file could not be read を報告します。ダウンロード自体は正常です。ハッシュ文字列を直接比較し、セキュリティ上の意味を持たないラベルは無視してください。
MinIO の管理用 Web コンソールはどうなりましたか？
MinIO は2025年5月に community edition のコンソールから管理機能を削除し、Web インターフェースにはオブジェクトブラウザーだけを残しました。現在、バケットとユーザーは mc クライアントで、mc admin user add や mc admin policy attach などのコマンドを使用して管理します。これは回避策ではなく、community edition でサポートされている方法です。そのため、このガイドではすべての操作をコマンドラインから行います。
restic から MinIO を S3 バックエンドとして使用するにはどう指定しますか？
AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY に MinIO のアクセスキーと対応するシークレットを設定し、s3:https://s3.example.com/restic 形式のリポジトリ文字列を使用します。最後のパス要素はバケット名です。バケットは先に mc mb で作成してください。1つのバケットに限定されたキーには、バケットを作成する権限がないためです。restic はアップロード前に独自のリポジトリパスワードで全データを暗号化するため、MinIO に保存されるのは暗号文であり、ファイルの内容が MinIO に知られることはありません。
MinIO を nginx の背後で実行する必要がありますか？
クライアントが同じマシン上にない場合は、TLS (transport layer security) が必要です。S3 の認証情報とオブジェクトデータは、どちらもリクエスト内を通過するためです。certbot の証明書を使用するポート443のプロキシが、これを実現する最も簡単な方法です。証明書の更新も MinIO から分離できます。--certs-dir を public.crt と private.key を保持するディレクトリに指定すれば、MinIO 自体で TLS を終端することもできます。ただし、その場合、サービスアカウントに更新後の秘密鍵への読み取りアクセス権が必要です。同じ結果を得るための追加作業になります。