-
Notifications
You must be signed in to change notification settings - Fork 8.9k
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
MongoDB Chart fails on windows host #827
Comments
Hi @dwitzig, MongoDB is a non-root container that runs as user 1001 by default. The volumes used by MongoDB should be owned by this user. Can you try installing the chart with the following options to launch it as root user?
|
Hi @tompizmor, thanks for your reply. I also confirmed my windows user ID is 1001
|
I used helm install stable/mongodb --set securityContext.fsGroup=0,securityContext.runAsUser=0 |
I found a similar issue using other mongodb image and it looks a MongoDB limitation:
Check this issue for more info: mvertes/docker-alpine-mongo#1 |
Same issue here. I run mongo in a docker in windows without issue, so there is definitely an issue here. |
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. |
@lagorsse and did you try disabling the persistence completely?
|
@tompizmor have same issue with rook/ceph. No problem with disabled persistence or run mongodb 3.4 as root. |
Hi @Bessonov, It seems rook mount the volumes owned by |
I'm also getting: |
@TheHalcyonSavant I am not sure if it has been already mentioned in this issue, but the problem happens because Docker for Windows doesn't support mounting volumes with specific ownerships or permissions. Hence, as the mongodb image is non-root, it cannot write to the mouted volume. Another user had a similar issue with the Postgres chart and wrote this comment that may help understand the issue. |
This same issue and fix applies to https://github.com/bitnami/charts/tree/master/bitnami/etcd as well. |
Correct! This issue affects all helm chart whose main image run as non-root user and writes data into a volume. |
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. |
I suspect this particular problem was solved by docker/for-win#5665 in Docker Desktop for Windows 2.2.0.4, which keeps the hostmounts on the Linux VM instead of passing through to Windows. |
Thanks for letting us know! |
I have a similar issue on Azure. I checked that mongo runs with user id 1238, but neither
nor
helped. The mount is still not writable. Any other suggestion? |
Hi @eevleevs Are you able to reproduce the issue when disabling persistence? It's very likely that the issue is related with the type of PersitentVolume(s) you are mounting on MongoDB. Are you using any special StorageClass? |
Disabling persistence it works. The issue is with the mount not being writable. I tried using default and cet-store classes, no difference. Also, if I run a bitnami/mongodb container directly (not with the chart) and change the user to 1238, I can write to persistent storage. |
Hi @eevleevs Please take a look to the Troubleshooting guide below we recently created: And give a try to the solution suggested on the guide. |
If I use only
If I use
then volume-permissions works, but mongodb container fails with:
|
Hi @eevleevs You obtained the error below:
It looks like you are installing the chart but you didn't remove exiting PVCs from previous deployments (see https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues/#persistence-volumes-pvs-retained-from-previous-releases). Could you please uninstall your release, remove the associated PVCs, and install it again setting |
This is not the case, I am always using a different release name. And anyway the PVC are actually removed automatically here. |
Hi @eevleevs But your logs say:
So.. It's possible that you're not sharing the logs from the 1st container boot. I mean, the 1st time the MongoDB is created before it's restarted and enters in the CrashLoopBackOff state. Could you please share these logs instead? Please also set |
Sorry, cannot see any difference. |
@eevleevs what do you mean? You should obtain in the logs: mongodb 08:37:53.60 INFO ==> ** Starting MongoDB setup **
mongodb 08:37:53.61 INFO ==> Validating settings in MONGODB_* env vars...
mongodb 08:37:53.64 INFO ==> Initializing MongoDB...
mongodb 08:37:53.65 INFO ==> Enabling authentication...
mongodb 08:37:53.66 INFO ==> Deploying MongoDB from scratch...
... Instead of: mongodb 10:08:58.24 INFO ==> ** Starting MongoDB setup **
mongodb 10:08:58.25 INFO ==> Validating settings in MONGODB_* env vars...
mongodb 10:08:58.45 INFO ==> Initializing MongoDB...
mongodb 10:08:58.62 INFO ==> Enabling authentication...
mongodb 10:08:58.63 INFO ==> Deploying MongoDB with persisted data...
... |
I am always seeing |
Hi @eevleevs, AFAIK, logs cannot retrieved past the previous to the running one. Could you try I can't seem to reproduce the issue, have you changed any other parameter besides |
Does not like it with
Did not change anything but
|
Hi @eevleevs, Could you paste the |
In my case the replica set key was not long enough. |
Thanks for sharing your insights @HassanHashemi |
mongoDB chart will continue to crash and restart on a windows 10 host with
mongodb.persistence.enabled=true
(persistence disabled works without issue)running on docker-for-windows Version 18.06.1-ce-win73 (19507)
with kubernetes enabled
kubectl describe
mongodb logs
The text was updated successfully, but these errors were encountered: