-
Notifications
You must be signed in to change notification settings - Fork 9.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mkdir: cannot create directory '/bitnami/mariadb': Permission denied #8565
Comments
Note the MariaDB container is a non-root container , because of that the directory (or volume) where the container needs to write data or create dirs should have the proper permissions. In this case, it seems the directory is trying to mount doesn't have the proper permission to work with non-root containers. You can modify the permission of the volume or change the security context for the container/pod to run the container as a privileged user, it will depend on the policy you can/would like to apply. |
Hi, I included the setting
And when I look at the permissions they are correct
But still is receive permission denied |
It's really weird, I'm not able to reproduce the issue on my side but maybe I'm creating the PVC in a different way. Can you please provide us with the steps/manifests you're using to create the PVC that is being used as an existing claim? |
I ran into this issue just deploying the default chart, no prior steps. The only values I deployed with are below:
|
@SQLJames please, can you open a new issue? It seems you're using bitnami/wordpress while this issue is about bitnami/mariadb |
+1 hitting this issue with the mariadb chart also. :/ |
@carrodher in my case, the PVC is being created with the https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner, by setting |
Same for me. I using also nfs-subdir-external-provisioner.
…On Sun, Jan 23, 2022, 07:12 Yorgos Saslis ***@***.***> wrote:
@carrodher <https://github.com/carrodher> in my case, the PVC is being
created with the
https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner, by
setting primary.persistence.storageClass=managed-nfs-storage when
installing the chart.
—
Reply to this email directly, view it on GitHub
<#8565 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACAZ4EEJILIQZ33QFVPMWW3UXOL2LANCNFSM5LHL6IBA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Can you check with |
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. |
this can be resolved with the mariadb chart by using the following initContainer: primary:
initContainers:
- name: mariadb-create-directory-structure
image: busybox
command:
[
"sh",
"-c",
"/bin/mkdir -p /bitnami/mariadb/data && /bin/chmod -R 777 /bitnami/mariadb",
]
volumeMounts:
- name: data
mountPath: /bitnami/mariadb/data not the most secure way of doing things obviously, but it's working for me for local development at least. probably a better idea is to try to change the user rather than just opening the whole directory up to everyone. also, unfortunately that doesn't help with the wordpress chart, as there's no way to fix it that i've seen there. if anyone has any ideas, i'm all ears. |
I faced this issue in Kubernetes v1.26.x and figured out it happened because the volume ownership modification (fsGroup: 1001) didn't work. Based on this docs, I changed that value of |
I'll add two cents: For me, starting up a recipe referencing mariadb begets this error on an existing lando-run project after upgrading to latest lando 3.21 beta. Using the same sort of recipe, I can start a new project (and db comes up, and healthcheck passes), but I can't seem to latch onto existing ones. Lando Log
Two more cents:
|
Which chart:
bitnami/mariab
Describe the bug
To Reproduce
Expected behavior
The datastore of the database is correctly created
Version of Helm and Kubernetes:
helm version
:kubectl version
:Additional context
The text was updated successfully, but these errors were encountered: