Since this update on the Helm chart, I am receiving the following errors in my minio pod:

API: SYSTEM()
Time: 09:18:35 UTC 05/24/2024
DeploymentID: 579eb3d5-4a7b-4c62-9319-8e888f257174
Error: Drive /storage, path (.minio.sys/buckets/state-storage/.metadata.bin) returned an error (file access denied) (*fmt.wrapError)
      18: internal/logger/logonce.go:118:logger.(*logOnceType).logOnceIf()
      17: internal/logger/logonce.go:149:logger.LogOnceIf()
      16: cmd/erasure-object.go:605:cmd.readAllXL()
      15: cmd/erasure-object.go:704:cmd.erasureObjects.getObjectFileInfo()
      14: cmd/erasure-object.go:225:cmd.erasureObjects.GetObjectNInfo()
      13: cmd/erasure-sets.go:752:cmd.(*erasureSets).GetObjectNInfo()
      12: cmd/erasure-server-pool.go:811:cmd.(*erasureServerPools).GetObjectNInfo()
      11: cmd/config-common.go:33:cmd.readConfigWithMetadata()
      10: cmd/config-common.go:54:cmd.readConfig()
       9: cmd/bucket-metadata.go:153:cmd.readBucketMetadata()
       8: cmd/bucket-metadata.go:176:cmd.loadBucketMetadataParse()
       7: cmd/bucket-metadata.go:213:cmd.loadBucketMetadata()
       6: cmd/bucket-metadata-sys.go:416:cmd.(*BucketMetadataSys).GetConfig()
       5: cmd/bucket-metadata-sys.go:304:cmd.(*BucketMetadataSys).CreatedAt()
       4: cmd/erasure-server-pool.go:1866:cmd.(*erasureServerPools).ListBuckets()
       3: cmd/erasure-server-pool.go:638:cmd.(*erasureServerPools).NSScanner()
       2: cmd/data-scanner.go:205:cmd.runDataScanner()
       1: cmd/data-scanner.go:78:cmd.initDataScanner.func1()

API: SYSTEM()
Time: 09:18:35 UTC 05/24/2024
DeploymentID: 579eb3d5-4a7b-4c62-9319-8e888f257174
Error: Drive /storage, path (.minio.sys/buckets/.usage-cache.bin) returned an error (file access denied) (*fmt.wrapError)
       9: internal/logger/logonce.go:118:logger.(*logOnceType).logOnceIf()
       8: internal/logger/logonce.go:149:logger.LogOnceIf()
       7: cmd/erasure-object.go:605:cmd.readAllXL()
       6: cmd/erasure-object.go:704:cmd.erasureObjects.getObjectFileInfo()
       5: cmd/erasure-object.go:225:cmd.erasureObjects.GetObjectNInfo()
       4: cmd/data-usage-cache.go:936:cmd.(*dataUsageCache).load.func1()
       3: cmd/data-usage-cache.go:954:cmd.(*dataUsageCache).load()
       2: cmd/erasure.go:375:cmd.erasureObjects.nsScanner()
       1: cmd/erasure-server-pool.go:666:cmd.(*erasureServerPools).NSScanner.func1()

API: SYSTEM()
Time: 09:18:35 UTC 05/24/2024
DeploymentID: 579eb3d5-4a7b-4c62-9319-8e888f257174

The security context, runAsUser and runAsGroup have changed and are hardcoded in the Helm chart. I can not unset them, but is there another way I can fix this error?

Based on the knowledge sources provided, it seems that the issue you're facing is related to the changes in the default User ID (UID) and Group ID (GID) of the running pod. This change is preventing the pod from accessing files it used to have access to, as mentioned in this [Github issue](https://github.com/airbytehq/airbyte/issues/36801). One user in the same issue thread suggested changing the

securityContext

in the templates of Airbyte's chart to the following:

yaml securityContext:   allowPrivilegeEscalation: true    runAsNonRoot: false   # uid=1000(airbyte)   runAsUser: 0   # gid=1000(airbyte)   runAsGroup: 0   readOnlyRootFilesystem: false   capabilities:     drop: ["ALL"]   seccompProfile:     type: RuntimeDefault

However, they also mentioned that they were unsure about the safety of this approach. It's important to note that changing security settings can have implications for the security of your system, so it's recommended to thoroughly understand the changes before implementing them. If the issue persists, it might be helpful to follow the progress of the issue on Github or reach out to the Airbyte community for further assistance.