[bitnami/minio] service is not starting

[lomori]

Name and Version

bitnami/minio:2024.2.4

What architecture are you using?

amd64

What steps will reproduce the bug?

This is the same issue as 30684, which has been closed by recommending to use GUID 0. However in our environment GUID 0 (root) is blocked, along with User ID 0 (root), which kind of makes sense to me as that is the root group. Our expectation is to be able to run this container without using user root or group root. In fact, this problem has been observed with various container images from Bitnami.

What is the expected behavior?

MinIO starting without relying on setting used id or guid to 0 (root).

What do you see instead?

kubectl logs minio-allure-65ddbcdbcd-rtzwn

 19:48:56.42 INFO  ==> 
 19:48:56.42 INFO  ==> Welcome to the Bitnami minio container
 19:48:56.42 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
 19:48:56.42 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
 19:48:56.42 INFO  ==> 
 19:48:56.42 INFO  ==> ** Starting MinIO setup **
minio 19:48:56.62 DEBUG ==> Validating settings in MINIO_* env vars..
/opt/bitnami/scripts/libminio.sh: line 65: /opt/bitnami/minio/tmp/minio.pid: Permission denied
minio 19:48:56.72 INFO  ==> Starting MinIO in background...
/opt/bitnami/scripts/libminio.sh: line 95: /opt/bitnami/minio/tmp/minio.pid: Permission denied
Formatting 1st pool, 1 set(s), 1 drives per set.
WARNING: Host local has all drives of set. A host failure will result in data becoming unavailable.
MinIO Object Storage Server
Copyright: 2015-2024 MinIO, Inc.
License: GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html>
Version: DEVELOPMENT.2024-02-04T22-36-13Z (go1.21.7 linux/amd64)

Status:         1 Online, 0 Offline. 
S3-API: http://localhost:9000 
Console: http://172.20.38.18:9001 http://127.0.0.1:9001 

Documentation: https://min.io/docs/minio/linux/index.html
Warning: The standard parity is set to 0. This can lead to data loss.
/opt/bitnami/scripts/libminio.sh: line 95: /opt/bitnami/minio/tmp/minio.pid: Permission denied
/opt/bitnami/scripts/libminio.sh: line 95: /opt/bitnami/minio/tmp/minio.pid: Permission denied
minio 19:49:06.83 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:49:12.32 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:49:17.72 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:49:23.12 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:49:28.52 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:49:33.92 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:49:39.32 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:49:44.72 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:49:50.13 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:49:55.53 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:50:00.92 INFO  ==> Adding local Minio host to 'mc' configuration...
minio 19:50:06.32 INFO  ==> Adding local Minio host to 'mc' configuration...
Failed to add temporary MinIO server
/opt/bitnami/scripts/libminio.sh: line 65: /opt/bitnami/minio/tmp/minio.pid: Permission denied
minio 19:50:11.73 INFO  ==> MinIO is already stopped...

Additional information

#30684

[lomori]

A possible way to handle it is to make sure all directories and files that are expected to be updated to be changed to the Users (100) group, for example. I'm not sure about the security implications of that other than allowing non-root UID and GUID to update those directories and folders. To be more tight, perhaps do this only for files. Files that are being created now, could be created empty during the image build.

[javsalgar]

Hi,

We're working on adding readOnlyRootFilesystem support to our charts. Once this support is added, users will be able to use non-root groups in their deploymens. We cannot guarantee an ETA, but we will notify the community as soon as there are news.

[lomori]

OK, good to know, thanks!

[siddjellali]

We add this as workaround in the Dockerfile.

# HotFix for rootless container
USER 0
RUN chown -R 1001:1001 /opt/bitnami/ /.mc/
USER 1001