search

bitnami / charts

Bitnami Helm Charts
https://bitnami.com
Other
8.98k stars 9.21k forks source link

[bitnami/minio] Minio Helm chart persistence not working on Windows 11 Docker Desktop w/ HyperV and Kubernetes #28784

Closed SledgeHammer01 closed 1 month ago

SledgeHammer01 commented 2 months ago

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:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: minio
  namespace: minio
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: minio
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 8Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /host_mnt/c/users/xxx/.minio

values:

        auth:
          rootPassword: xxx
        ingress:
          enabled: true
          hostname: minio.xxx.com
          ingressClassName: nginx
        tls:
          existingSecret: minio-tls
        persistence:
          existingClaim: minio
        volumePermissions:
          enabled: true
        apiIngress:
          enabled: true
          hostname: minio-api.xxx.com
          ingressClassName: nginx
          tls: true
          extraTls:
            - hosts:
                - minio-api.xxx.com
              secretName: minio-api-tls

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

Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  74s                default-scheduler  Successfully assigned minio/minio-5c746994b6-t9rfd to docker-desktop
  Normal   Pulled     75s                kubelet            Container image "docker.io/bitnami/os-shell:12-debian-12-r27" already present on machine
  Normal   Created    75s                kubelet            Created container volume-permissions
  Normal   Started    75s                kubelet            Started container volume-permissions
  Normal   Pulled     25s (x4 over 74s)  kubelet            Container image "docker.io/bitnami/minio:2024.8.3-debian-12-r0" already present on machine
  Normal   Created    25s (x4 over 74s)  kubelet            Created container minio
  Normal   Started    25s (x4 over 74s)  kubelet            Started container minio
  Warning  BackOff    5s (x10 over 72s)  kubelet            Back-off restarting failed container minio in pod minio-5c746994b6-t9rfd_minio(2a191ca1-2fa7-43df-929a-7c0c13996156)

 16:21:16.56 INFO  ==>
 16:21:16.56 INFO  ==> Welcome to the Bitnami minio container
 16:21:16.56 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
 16:21:16.57 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
 16:21:16.57 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
 16:21:16.57 INFO  ==>
 16:21:16.57 INFO  ==> ** Starting MinIO setup **
/opt/bitnami/scripts/libminio.sh: line 364: /bitnami/minio/data/.root_user: Operation not permitted
SledgeHammer01 commented 2 months 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
carrodher commented 2 months ago

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.

SledgeHammer01 commented 2 months ago

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.

@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
SledgeHammer01 commented 2 months ago

@carrodher Also, when I try to runAs 0:0, I still get a crash backoff, but no error message in the logs.

javsalgar commented 2 months ago

Hi! It seems to me that the PVC system for does specific cluster is not compatible. I use minikube in wsl without issues

SledgeHammer01 commented 2 months ago

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).

github-actions[bot] commented 2 months ago

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.

github-actions[bot] commented 1 month ago

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.