mkdir: cannot create directory ‘/bitnami/postgresql/data’: Permission denied #1210
Comments
|
Minikube version: |
|
Cleanup: |
|
I see that you manually created a PVC using hostpath. In that case, the permissions may be incorrect due to the non-root nature of the container. Could you try not creating the PVC instead? |
|
|
|
Well I thought configuring Variables Commands Results (after running commands in original issue description): |
|
@javsalgar, Unfortunately running without a PVC is a non-starter. The demonstration I'm creating needs to illustrate the use of PV and PVC. We anticipate customers wanting to try it out on We're delighted with Bitnami Docker images and Helm charts, we don't want to highlight any short-comings with them. So I'm looking for a straight-forward way of illustrating the use of Bitnami charts for PostgreSQL (and RabbitMQ) in a minikube environment. |
|
Although it doesn't help me get where I want to go, If I change the contents of That is |
|
...what gets me is that this chart and the RabbitMQ chart were working about a month ago in |
|
Hi, I saw that you opened an issue in helm/charts#14390. Let's continue the conversation there. |
|
Closed in favor of helm/charts#14390 |
|
@docktermj : incorrect ownership of '/bitnami/postgresql/data’ is a more generic problem, not specific to Helm charts, so I'd rather re-open the issue if you can, if only to correct the volumes documentation on Docker Hub overview page to incorporate my solution I found here. It has just resurfaced for If I set See error log details
However, if I move the See correct log details
|
|
Hi, We would need to check in more detail the cause of the issue. We test the chart in the major Kubernetes platforms and we don't see the issue. It would be great if you could share the permissions of the |
|
@javsalgar : Facing the same issue for one of my app. as well deployed via HELM. Following are its logs:
|
|
Hi, It seems that you were doing an upgrade. Could you tell us from which version of the container you were upgrading and which are the storage provider you have configured in the cluster? |
|
StorageProvider is "local-storage" or "manual" as its an On-Prem k8s-cluster. |
|
Hi, Could it be that this kind of storage provider does not work well with the |
|
Setting the fsGroup securityContext with latest bitnami image seems to work: securityContext: |
|
Same Problem here with docker-compose and bind mounts. Looks like if I change permissions on the folder beeing nmounted (which was automatically created by docker) to 777 the container is able to create its subfolder. Afterwards, changing the folders permission back works fine. |
|
Another and perhaps connected issue is hard-coded non-standard (not equal to 1000) user ID of 1001 used in |
|
Hi, Note that our containers are meant to work with any random user ID. We configure them so they work in Openshift, were there is no fixed user id for the container. The only requisite is that the random user ID must belong to the |
I have same issue on k8s, but im sure that the pod keycloak-postgres-pv is using the PVC, im actually running a multi-node cluster with kubeadm, i have 2 workers and 1 master node. I also have Docker as container runtime and calico as cni |
|
It seems that you are using a local storage provider. Is it compatible with fsGroups? |
|
Hi! I think that, for this case, the best option would be to use init containers in docker-compose, emulating the volumePermissions commands. Find an example here docker/docs#12633 (comment) |
I disagree :) |
|
Note that, in that case, the container would need to have root privileges in order for chown operations to work. The containers are non-root and that's the main reason we rely on the volumePermissions init containers in the chart. |
Can't you just switch temporarily to root? |
|
But that's at the docker build level, not at runtime. I believe we're talking about using the container at runtime. |
Yes. I didn't check the image definition honestly, so when do you the |
|
I think I'm not following in this case, what would we exactly want to achieve by doing a chown at the docker build level? Right now, it is configured so any random user that belongs to the root group works. If we perform a chown then it wouldn't work with random users. |
Ok, I was not aware of this. |
|
Are there ways to solve this problem? |
|
@batazor could you provide more details of your configuration and the issue you are facing? |
|
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. |
|
Hi, I am using a cluster-based environment and getting the below error while starting the Postgresql pod. Storage mode - nfs-storage-class $ kubectl logs -n gss-qa postgres-lb-deployment-7b45c5f6f5-zb5c9
postgresql 07:32:23.80
postgresql 07:32:23.81 Welcome to the Bitnami postgresql container
postgresql 07:32:23.81 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-postgresql
postgresql 07:32:23.81 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-postgresql/issues
postgresql 07:32:23.81
postgresql 07:32:23.83 INFO ==> ** Starting PostgreSQL setup **
postgresql 07:32:23.85 INFO ==> Validating settings in POSTGRESQL_* env vars..
postgresql 07:32:23.86 INFO ==> Loading custom pre-init scripts...
postgresql 07:32:23.87 INFO ==> Initializing PostgreSQL database...
mkdir: cannot create directory ‘/bitnami/postgresql/data’: Read-only file system |
|
The issue Read-only file system was resolved by properly setting up the NFS server and client configuration. |
|
Passing |
indeed. this worked for me using the following helm version: however, just for psa: using the following for |
bitnami postgresql subchart fails without userPermissions.enabled on some systems (eg. on minikube). See bitnami/charts#1210 for details.
|
i'm experiencing this issue where I have permission denied for:
It did not work with setting : |
|
Similar issue when installing latest keycloak NOTES: kubectl logs --all-containers=true -n identity keycloak-postgresql-0 --set volumePermissions.enabled=true <-- didn't help Any workaround for this? |
The postgresql helm chart requires the use of PersisentVolumes, and places PersisentVolumeClaim for this. Ensure that your cluster provies PersisentVolumes. Also set volumePermissions.enabled=true which helps to fix Permission denied when trying to create the data directory in the PV mount directory if the PV's permissions are not open enough: bitnami/charts#1210 (comment)
The postgresql helm chart requires the use of PersisentVolumes. It places a PersisentVolumeClaim for this. Ensure that the cluster provides PersistentVolumes. Also set volumePermissions.enabled=true which helps to fix Permission denied when trying to create the data directory in the PV mount directory if the PV's permissions are not open enough: bitnami/charts#1210 (comment)
The postgresql helm chart requires the cluster to provide a PersistentVolume and places a PersisentVolumeClaim for this. Ensure that the cluster provides PersistentVolumes. Also set volumePermissions.enabled=true which helps to fix Permission denied when trying to create the data directory in the PV mount directory if the PV's permissions are not open enough: bitnami/charts#1210 (comment)
Add it under This should also work |
Which chart:
bitnami/postgresql
Description
Although creating the bitnami/postgresql chart worked a few weeks ago in
minikube, recently it has begun failing with the following error:Steps to reproduce the issue:
namespace.yamlfile:persistent-volume-postgresql.yamlfile:persistent-volume-claim-postgresql.yamlfilepostgresql.yamlfile:bitnami/postgresqlhelm chart.Describe the results you received:
Describe the results you expected:
A chart that comes up. :-)
Additional information you deem important (e.g. issue happens only occasionally):
Version of Helm and Kubernetes:
helm version:kubectl version:The text was updated successfully, but these errors were encountered: