Like they told you in the comments, you are using the wrong approach to the problem. Executing inside a container to make manual operations is (most of the times) useless, since Pods (and the containers which are part of such Pods) are ephimeral entities, which will be lost whenever the Pod restart.

Unless the path you are trying to interact with is supported by a persisted volume, as soon as the container will be restared, all your changes will be lost.

HELM Charts, like the bitnami-ha chart, exposes several way to refine / modify the default installation:

• You could build a custom docker image starting from the one used by default, adding there the libraries and whatever you need. This way the container will be already "ready" in the way you want, as soon as it starts

• You could add an additional Init Container to perfom operations such as preparing files for the main container on emptydir volumes, which can then be mounted at the expected path

• You could inject an entrypoint script which does what you want at start, before calling the main entrypoint

Check the Readme as it lists all the possibilities offered by the Chart (such as how to override the image with your custom one and more)

I need ... to place the .so libraries I need for postgresql in ... /opt/bitnami/postgresql/lib

I'd consider this "extending" rather than "configuring" PostgreSQL; it's not a task you can do with a Helm chart alone. On a standalone server it's not something you could configure with only a text editor, for example, and while the Bitnami PostgreSQL-HA chart has a pretty wide swath of configuration options, none of them allow providing extra binary libraries.

The first step to doing this is to create a custom Docker image that includes the shared library. That can start FROM the Bitnami PostgreSQL image this chart uses:

ARG postgresql_tag=11.12.0-debian-10-r44
FROM bitnami/postgresql:${postgresql_tag}
# assumes the shared library is in the same directory as
# the Dockerfile
COPY whatever.so /opt/bitnami/postgresql/lib
# or RUN curl ..., or RUN apt-get, or ...
#
# You do not need EXPOSE, ENTRYPOINT, CMD, etc.
# These come from the base image

Build this image and push it to a Docker registry, the same way you do for your application code. (In a purely local context you might be able to docker build the image in minikube's context.)

When you deploy the chart, it has options to override the image it runs, so you can point it at your own custom image. Your Helm values could look like:

postgresqlImage:
  registry: registry.example.com:5000
  repository: infra/postgresql
  tag: 11.12.0-debian-10-r44
  # `docker run registry.example.com:5000/infra/postgresql:11.12.0-debian-10-r44`

and then you can provide this file via the helm install -f option when you deploy the chart.

You should almost never try to manually configure a Kubernetes pod by logging into it with kubectl exec. It is extremely routine to delete pods, and in many cases Kubernetes does this automatically (if the image tag in a Deployment or StatefulSet changes; if a HorizontalPodAutoscaler scales down; if a Node is taken offline); in these cases your manual changes will be lost. If there are multiple replicas of a pod (with an HA database setup there almost certainly will be) you also need to make identical changes in every replica.