Closed leon0707 closed 2 years ago
Looks like a bug that was fixed in 3.5.10, and you're encountering it on 4.0.5 https://jira.mongodb.org/browse/SERVER-26871 https://jira.mongodb.org/browse/SERVER-32473
Starting a mongo:4.0.5 container doesn't show any errors for me
$ docker run -d --rm --name mongo mongo:4.0.5
d7b0f2308d4be6acdb874a0b11dd2abb96608857e296b3397209963bd70f7388
$ docker logs mongo
2019-01-16T17:53:09.971+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=d7b0f2308d4b
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] db version v4.0.5
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] git version: 3739429dd92b92d1b0ab120911a23d50bf03c412
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] allocator: tcmalloc
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] modules: none
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] build environment:
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] distmod: ubuntu1604
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] distarch: x86_64
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] target_arch: x86_64
2019-01-16T17:53:09.973+0000 I CONTROL [initandlisten] options: { net: { bindIpAll: true } }
2019-01-16T17:53:09.973+0000 I STORAGE [initandlisten]
2019-01-16T17:53:09.973+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-01-16T17:53:09.973+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-01-16T17:53:09.973+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=979M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2019-01-16T17:53:10.598+0000 I STORAGE [initandlisten] WiredTiger message [1547661190:598541][1:0x7f40fc54da40], txn-recover: Set global recovery timestamp: 0
2019-01-16T17:53:10.721+0000 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-01-16T17:53:10.799+0000 I CONTROL [initandlisten]
2019-01-16T17:53:10.799+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-01-16T17:53:10.799+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-01-16T17:53:10.799+0000 I CONTROL [initandlisten]
2019-01-16T17:53:10.800+0000 I STORAGE [initandlisten] createCollection: admin.system.version with provided UUID: 52806025-e5ad-4578-8216-1de9d92f2248
2019-01-16T17:53:10.904+0000 I COMMAND [initandlisten] setting featureCompatibilityVersion to 4.0
2019-01-16T17:53:10.914+0000 I STORAGE [initandlisten] createCollection: local.startup_log with generated UUID: beb27e97-eee9-44ac-86f0-379cce977e11
2019-01-16T17:53:10.955+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2019-01-16T17:53:10.958+0000 I NETWORK [initandlisten] waiting for connections on port 27017
2019-01-16T17:53:10.959+0000 I STORAGE [LogicalSessionCacheRefresh] createCollection: config.system.sessions with generated UUID: 34c27039-408e-4147-98b0-1cf7487db169
2019-01-16T17:53:11.030+0000 I INDEX [LogicalSessionCacheRefresh] build index on: config.system.sessions properties: { v: 2, key: { lastUse: 1 }, name: "lsidTTLIndex", ns: "config.system.sessions", expireAfterSeconds: 1800 }
2019-01-16T17:53:11.030+0000 I INDEX [LogicalSessionCacheRefresh] building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-01-16T17:53:11.034+0000 I INDEX [LogicalSessionCacheRefresh] build index done. scanned 0 total records. 0 secs
@wglambert I create two secrets for the mongo containerMONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD
. The container automatically creates the root user. The error message showed up between adding the root user and execution of the custom init script.
So the error is shown here when mongo does something like create a user and then wants to write its history to an invalid path.
Ouch, looks like https://jira.mongodb.org/browse/SERVER-29103 is related -- ideally we'd want to disable the "history file" for these commands, but there's not actually a way to do that without making the history file completely unusable by default. :disappointed:
Dealing with exactly the same error. Mongo image v 4.0.6. First "clean" initial run on container with variables MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_USERNAME
successfully creates admin user. But after stopping container and starting it again error comes up:
2019-03-19T08:21:18.911+0000 E QUERY [js] Error: couldn't add user: command createUser requires authentication :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DB.prototype.createUser@src/mongo/shell/db.js:1491:15
@(shell):1:1
2019-03-19T08:21:18.912+0000 E - [main] Error saving history file: FileOpenFailed: Unable to open() file /home/mongodb/.dbshell: Unknown error
Manually hacking the container and removing env. varibles MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_USERNAME
from it resolves the issue.
So, it seems, like mongo image tries to create user from MONGO_INITDB_ROOT_USERNAME
even if DB was already initialized. This is very confusing, especially considering the docs on dockerhub which say:
Do note that none of the variables below will have any effect if you start the container with a data directory that already contains a database: any pre-existing database will always be left untouched on container startup.
How to set up first super user in a proper way, so that not to break cluster after stop?
UPD: issue happens when running mongod as configsvr instance;
+1
Hi, all,
I have met this problem today. I used the docker image tag: 4.0.9
.
I used docker exec -it container-mongo /bin/bash
to go inside, and find:
There is no home folder for the user of mongodb
.
Yes, in the error message:
2019-03-19T08:21:18.912+0000 E - [main] Error saving history file: FileOpenFailed: Unable to open() file /home/mongodb/.dbshell: Unknown error
The folder /home/mongodb
does not exist.
Then my solution is:
\home\mongodb
Remind: don't use user and group name in your host for the owner assign - instead use the id of user and group.
You can get mongodb user and group id used in the docker image:
root@4778d894024d:/# id mongodb uid=999(mongodb) gid=999(mongodb) groups=999(mongodb)
After these steps, the error message is gone, and .dbshell shows up in the folder which owner is 999:999
.
One line command:
mkdir mongo-home && \
sudo chown `docker run --rm mongo:latest id -u mongodb`:`docker run --rm mongo:latest id -g mongodb` mongo-home
I check the dockerfile, and find the creation of the user mongodb
is missing -m
arugment:
root@4778d894024d:/# docker run --rm mongo useradd --help Usage: useradd [options] LOGIN useradd -D useradd -D [options]
Options: ... -m, --create-home create the user's home directory ...
+1
Is everybody using the manual folder workaround ? Should we proceed with a PR to add the -m option to the dockerfile ?
From what I've seen, the error doesn't prevent anything from working, so it's really more of a warning -- is someone else seeing behavior different from that?
As of today, I still have this issue with the latest image of mongo.
For people using Docker Compose, here is what I did.
1. Create the folder ./home/mongodb
on your local filesystem.
$ mkdir -p ./home/mongodb
2. Create the file ./home/mongodb/.dbshell
$ touch ./home/mongodb/.dbshell
3. Change the permission of the folder to match the one used in the Dockerfile.
As said above, the permissions are set to 999
$ chown -R 999:999 ./home/mongodb
4. Add a volume to your Docker Compose service (mine is called barret
for context).
version: "3"
services:
barret:
container_name: barret
image: mongo:latest
ports:
- $MONGO_PORT:27017
environment:
MONGO_DATABASE_USERNAME: $MONGO_DATABASE_USERNAME
MONGO_DATABASE_PASSWORD: $MONGO_DATABASE_PASSWORD
MONGO_DATABASE_NAME: $MONGO_DATABASE_NAME
MONGO_INITDB_ROOT_USERNAME: $MONGO_ROOT_USERNAME
MONGO_INITDB_ROOT_PASSWORD: $MONGO_ROOT_PASSWORD
volumes:
- ./home/mongodb:/home/mongodb
- ./database/migrations:/docker-entrypoint-initdb.d
- ./data/db:/data/db
I just updated Docker Desktop (Windows) from 2.2.0.4 to 2.2.0.5 and this problem went away 🤷♂️
Ha fair question. Comment updated! I updated Docker Desktop (Windows) from 2.2.0.4 to 2.2.0.5.
On Sun, May 3, 2020 at 1:33 AM Daniel Shmuglin notifications@github.com wrote:
@jhnieman https://github.com/jhnieman may I ask what did you update? what are these magic numbers?
10x
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/docker-library/mongo/issues/323#issuecomment-623074747, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSPWH7YS333B7LI6T6IXILRPUT5BANCNFSM4GQHRRQA .
As of today, I still have this issue with the latest image of mongo.
For people using Docker Compose, here is what I did.
1. Create the folder
./home/mongodb
on your local filesystem.$ mkdir -p ./home/mongodb
2. Create the file
./home/mongodb/.dbshell
$ touch ./home/mongodb/.dbshell
3. Change the permission of the folder to match the one used in the Dockerfile.
As said above, the permissions are set to 999
$ chown -R 999:999 ./home/mongodb
4. Add a volume to your Docker Compose service (mine is called
barret
for context).version: "3" services: barret: container_name: barret image: mongo:latest ports: - $MONGO_PORT:27017 environment: MONGO_DATABASE_USERNAME: $MONGO_DATABASE_USERNAME MONGO_DATABASE_PASSWORD: $MONGO_DATABASE_PASSWORD MONGO_DATABASE_NAME: $MONGO_DATABASE_NAME MONGO_INITDB_ROOT_USERNAME: $MONGO_ROOT_USERNAME MONGO_INITDB_ROOT_PASSWORD: $MONGO_ROOT_PASSWORD volumes: - ./home/mongodb:/home/mongodb - ./database/migrations:/docker-entrypoint-initdb.d - ./data/db:/data/db
thanks, works!
but don't need to create this path /home/mongodb
, can be other, likes ./data
.
and chown -R $USER ./data
Hi,
I found the same problem while passing the arguments for MONGO_INITDB_ROOT_USERNAME and MONGO_INITDB_ROOT_PASSWORD as environment variables in a kubernetes deployment.
Is there a reason why there is not a PR with the solution proposed here (https://github.com/docker-library/mongo/issues/323#issuecomment-494648458)? Should we create it?
From what I've seen, the error doesn't prevent anything from working, so it's really more of a warning -- is someone else seeing behavior different from that?
Correct... Sorry.
It seems I was having another problem related with the base64 of the secret inserting a \n at the end of the pasword (https://github.com/docker-library/mongo/issues/346).
I tried all the above and nothing worked for me. I switched my init file from sh to js and everything is fine now. The problem now is that I have to figure out how to use env variables in the js file.
I tried all the above and nothing worked for me. I switched my init file from sh to js and everything is fine now.
From what I've seen, the error doesn't prevent anything from working, so it's really more of a warning
It would be helpful to have a reproducer where the Error saving history file
is the cause of the container exiting early.
Any progress on this?
It works on the first initialization. But once mongo is restarted or killed or redeployed, it will try recreate the user which causes error and mongodb fails to start afterwards.
@StardustXiaoT I'm having a hard time seeing how what you describe is related to the error message/warning being discussed here, which is Error saving history file: FileOpenFailed: Unable to open() file /home/mongodb/.dbshell: Unknown error
?
It sounds like you're having some usage issues which would be better raised in the Docker Community Forums, the Docker Community Slack, or Stack Overflow.
From what I've seen, the error doesn't prevent anything from working, so it's really more of a warning -- is someone else seeing behavior different from that?
For me this error stopped mongo from creating the root user specified by the env variables. The mentioned workaround (mapping /home/mongodb) worked and after cleaning the whole mongo directory and doing a fresh initialize everything works as expected!
Given your experience, I was hoping that maybe having a read-only /home/mongodb
would do the trick and give us a reproducer, but no such luck:
(So in short, we're still looking for a reliable reproducer.)
Adding --mount type=volume,src=nonsense,dst=/home/mongodb,ro
makes the error message slightly different (Error saving history file: FileOpenFailed Unable to open() file /home/mongodb/.dbshell: Read-only file system
), but the whole run still succeeds and MongoDB starts correctly.
hi all: I get the same problem while using mongodb 3.6.15 for docker。 The container gets stuck after running to this step.
2021-05-18T03:35:10.439+0000 E - [main] Error saving history file: FileOpenFailed: Unable to open() file /home/mongodb/.dbshell: No such file or directory
2021-05-18T03:35:10.442+0000 I NETWORK [conn2] end connection 127.0.0.1:47240 (0 connections now open)
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
2021-05-18T03:35:10.456+0000 I CONTROL [main] ***** SERVER RESTARTED *****
killing process with pid: 458
2021-05-18T03:35:10.468+0000 I CONTROL [signalProcessingThread] got signal 15 (Terminated), will terminate after current cmd ends
2021-05-18T03:35:10.468+0000 I NETWORK [signalProcessingThread] shutdown: going to close listening sockets...
2021-05-18T03:35:10.468+0000 I NETWORK [signalProcessingThread] removing socket file: /tmp/mongodb-27017.sock
2021-05-18T03:35:10.469+0000 I FTDC [signalProcessingThread] Shutting down full-time diagnostic data capture
2021-05-18T03:35:10.469+0000 I STORAGE [signalProcessingThread] WiredTigerKVEngine shutting down
2021-05-18T03:35:10.569+0000 I STORAGE [signalProcessingThread] shutdown: removing fs lock...
2021-05-18T03:35:10.569+0000 I CONTROL [signalProcessingThread] now exiting
2021-05-18T03:35:10.569+0000 I CONTROL [signalProcessingThread] shutting down with code:0
I debuged docker-entrypoint.sh
found it was stuck in "${mongodHackedArgs[@]}" --shutdown
. The full command is mongod --config /tmp/docker-entrypoint-temp-config.json --bind_ip 127.0.0.1 --port 27017 --sslMode disabled --logpath /proc/6/fd/1 --logappend --pidfilepath /tmp/docker-entrypoint-temp-mongod.pid --shutdown
.
I hacking the container and run ps aux
find this stuck process and kill it, then the container run successfully!
I do not konw why it stuck in command ${mongodHackedArgs[@]}" --shutdown
Hi,
I found the same problem while passing the arguments for MONGO_INITDB_ROOT_USERNAME and MONGO_INITDB_ROOT_PASSWORD as environment variables in a kubernetes deployment.
Is there a reason why there is not a PR with the solution proposed here (#323 (comment))? Should we create it?
I also wonder why it is not implemented... I'm building my own docker image based on the same Dockerfile, just because I need to add the -m
...
From what I've seen, the error doesn't prevent anything from working, so it's really more of a warning -- is someone else seeing behavior different from that?
From what I've seen, the error doesn't prevent anything from working, so it's really more of a warning -- is someone else seeing behavior different from that?
For me this error stopped mongo from creating the root user specified by the env variables. The mentioned workaround (mapping /home/mongodb) worked and after cleaning the whole mongo directory and doing a fresh initialize everything works as expected!
Yeah, me too. I'm just trying to set up MERN stack in Docker compose.😟 But cannot make MONGO_INITDB_DATABASE work. Tried mounting Read-Only volume but still not working.
@quaos, The database will not be created unless you insert data via *.js
scripts in /docker-entrypoint-initdb.d/
. If nothing is inserted the database does not exist (or conversely every database exists, you just have to use it).
This variable allows you to specify the name of a database to be used for creation scripts in
/docker-entrypoint-initdb.d/*.js
(see Initializing a fresh instance below). MongoDB is fundamentally designed for "create on first use", so if you do not insert data with your JavaScript files, then no database is created.
Fixed via https://github.com/docker-library/mongo/pull/541 :+1:
Dockerfile