Closed SledgeHammer01 closed 1 month ago
If I use this config, then I don't get the "Operation not permitted" error, but I still get a crash backoff and nothing is written to the share. No indication of what the error is.
apiIngress:
enabled: true
extraTls:
- hosts:
- minio-api.xxx.com
secretName: minio-api-tls
hostname: minio-api.xxx.com
ingressClassName: nginx
tls: true
auth:
rootPassword: xxx
containerSecurityContext:
runAsNonRoot: false
runAsUser: 0
ingress:
enabled: true
hostname: minio.xxx.com
ingressClassName: nginx
persistence:
existingClaim: minio
tls:
existingSecret: minio-tls
Bitnami containers are designed to operate as non-root by default. Consequently, any files or directories used by the application should be owned by the root group, as the random user (1001 by default) is a member of this root group. To ensure proper permissions, you'll need to adjust the ownership of your local directory accordingly.
For more comprehensive information about non-root containers and their significance for security, you can explore the following resources:
These references provide valuable insights into the best practices and considerations when working with non-root containers in Bitnami applications.
Bitnami containers are designed to operate as non-root by default. Consequently, any files or directories used by the application should be owned by the root group, as the random user (1001 by default) is a member of this root group. To ensure proper permissions, you'll need to adjust the ownership of your local directory accordingly.
For more comprehensive information about non-root containers and their significance for security, you can explore the following resources:
- Why non-root containers are important for security
- Use Non-Root Containers
- Work With Non-Root Containers for Bitnami Applications
- Running non-root containers on Openshift
These references provide valuable insights into the best practices and considerations when working with non-root containers in Bitnami applications.
@carrodher Thanks for the reply.
Are you referring to the folder on the host machine c/users/xxx/.minio
(in this case Windows)? or the mounted volume /bitnami/minio/data
inside of the pod?
In the case of the folder on the Windows box, I set that to Everyone has full R/W access.
In the case of the mount inside the pod, isn't that what volumePermissions.enabled: true
is supposed to do?
apiIngress:
enabled: true
extraTls:
- hosts:
- minio-api.xxx.com
secretName: minio-api-tls
hostname: minio-api.xxx.com
ingressClassName: nginx
tls: true
auth:
rootPassword: xxx
ingress:
enabled: true
hostname: minio.xxx.com
ingressClassName: nginx
persistence:
existingClaim: minio
tls:
existingSecret: minio-tls
volumePermissions:
enabled: true
I get:
volume-permissions
Container is terminated because of Completed. It exited with exit code 0. It is not started.
18:36:29.01 INFO ==>
18:36:29.01 INFO ==> Welcome to the Bitnami minio container
18:36:29.01 INFO ==> Subscribe to project updates by watching https://github.com/bitnami/containers
18:36:29.01 INFO ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
18:36:29.01 INFO ==> Upgrade to Tanzu Application Catalog for production environments to access custom-configured and pre-packaged software components. Gain enhanced features, including Software Bill of Materials (SBOM), CVE scan result reports, and VEX documents. To learn more, visit https://bitnami.com/enterprise
18:36:29.01 INFO ==>
18:36:29.01 INFO ==> ** Starting MinIO setup **
/opt/bitnami/scripts/libminio.sh: line 364: /bitnami/minio/data/.root_user: Operation not permitted
@carrodher Also, when I try to runAs 0:0, I still get a crash backoff, but no error message in the logs.
Hi! It seems to me that the PVC system for does specific cluster is not compatible. I use minikube in wsl without issues
Hi! It seems to me that the PVC system for does specific cluster is not compatible. I use minikube in wsl without issues
Weird. I have other applications running in the cluster that write to HostPath just fine (i.e. LocalStack).
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.
Name and Version
bitnami/minio:latest
What architecture are you using?
amd64
What steps will reproduce the bug?
When I deploy the Helm chart as below, the pod fails to start up with "Operation not permitted" when it tries to initialize the database. I also tried
volumePermissions.enabled
to true. Also tried changing all the security contexts to run as user/group 0, non-root to false, elevated permission = true, etc. Still no write access :(.PVC:
PV:
values:
What do you see instead?
When I deploy the Helm chart as below, the pod fails to start up with "Operation not permitted" when it tries to initialize the database.
Additional information