[DOCS-13886] mongodump will not work according to docs Created: 21/Sep/20  Updated: 30/Oct/23  Due: 25/Sep/20  Resolved: 11/Nov/20

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: 4.4.0
Fix Version/s: Server_Docs_20231030

Type: Bug Priority: Major - P3
Reporter: Yurii Predborskyii Assignee: Andrew Feierabend (Inactive)
Resolution: Duplicate Votes: 0
Labels: bug
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

macos 10.15.6


Attachments: Text File log.txt     HTML File mongodump_auth_troubleshooting     File mongodump_auth_troubleshooting_4.4.1    
Issue Links:
Related
related to TOOLS-2752 TEST: "no users authenticated" on too... Closed
Participants:
Days since reply: 3 years, 13 weeks ago
Epic Link: DOCSP-11348
Story Points: 2

 Description   

Description

I tried to follow mongodb docs and tried to make a dump of the local mongodb database with no authentication enabled. Compass connects just fine with no parameters

But when I try running

mongodump

it results in the following error message:

Failed: error creating intents to dump: error getting database names: (Unauthorized) there are no users authenticated

The problem is: I don't have authentication mode enabled.

This is either an error on mongodump side (authentication is disabled, and mongodump checks against authenticated users anyways) or a documentation mistake (auth is required for mongodump, which means "mongodump" command example is invalid).

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Andrew Feierabend (Inactive) [ 11/Nov/20 ]

Closing this ticket. Work being tracked separately in TOOLS-2752.

Comment by Andrew Feierabend (Inactive) [ 19/Oct/20 ]

Thanks yurii.p@masterborn.com – I've passed this along as well.

Comment by Yurii Predborskyii [ 16/Oct/20 ]

For the sake of completeness:
I tested the mongodump command on a windows PC with freshly installed MongoDB and

mongodump

worked perfectly, did not require any local user accounts or anything, there was no error, the dump was created as expected.

Comment by Andrew Feierabend (Inactive) [ 12/Oct/20 ]

Thanks very much yurii.p@masterborn.com, I have passed this feedback up to engineering. Will report back!

Comment by Yurii Predborskyii [ 08/Oct/20 ]

Hi, I did as instructed. the log is below. Hope it helps!

yuriipredborskyi@Yuriis-MacBook-Pro ~ % mongo
MongoDB shell version v4.4.0
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("0c90cf09-9dbc-436f-837a-1f49f1155deb") }
MongoDB server version: 4.4.0
---
The server generated these startup warnings when booting: 
        2020-10-08T10:32:16.965+02:00: ***** SERVER RESTARTED *****
        2020-10-08T10:32:21.002+02:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
---
> db.getUsers();
[ ]
> db.runCommand({connectionStatus: 1})
{
	"authInfo" : {
		"authenticatedUsers" : [ ],
		"authenticatedUserRoles" : [ ]
	},
	"ok" : 1
}
> exit
bye

Please let me know if there is anything else I can do to help with this issue!

 

Comment by Andrew Feierabend (Inactive) [ 06/Oct/20 ]

yurii.p@masterborn.com Thank you!!

Can you run the following commands from the mongo shell once connected to the mongod on running at 127.0.0.1:27017 ?

db.getUsers();
db.runCommand({connectionStatus : 1})

Really appreciate your help!

Comment by Yurii Predborskyii [ 06/Oct/20 ]

PS: I just tried to use "localhost" instead of "127.0.0.1" and connection failed with the same error as no connection string. This could be the source of the issue, but I am not 100% sure. When I ran mongorestore with "127.0.0.1" instead of "localhost" it worked just fine.

Here's a short dump of the failed restore:

 

yuriipredborskyi@Yuriis-MacBook-Pro ~ % mongorestore mongodb://localhost:27017
2020-10-06T10:15:45.475+0200	using default 'dump' directory
2020-10-06T10:15:45.475+0200	preparing collections to restore from
2020-10-06T10:15:45.475+0200	don't know what to do with file "dump/.DS_Store", skipping...
2020-10-06T10:15:45.477+0200	finished restoring foo.bar (0 documents, 0 failures)
2020-10-06T10:15:45.477+0200	Failed: foo.bar: error reading database: (Unauthorized) there are no users authenticated
2020-10-06T10:15:45.477+0200	0 document(s) restored successfully. 0 document(s) failed to restore.

Please let me know if there's anything else I can do to help.

 

Comment by Yurii Predborskyii [ 06/Oct/20 ]

Here's my log:

I have created a new database in otherwise empty mongo. DB is called test, collection is called toast, it has a single document.

This is mongodump output

yuriipredborskyi@Yuriis-MacBook-Pro ~ % mongodump -vvvv
2020-10-06T10:02:27.675+0200	initializing mongodump object
2020-10-06T10:02:27.675+0200	will listen for SIGTERM, SIGINT, and SIGKILL
2020-10-06T10:02:27.685+0200	starting Dump()
2020-10-06T10:02:27.689+0200	Failed: error creating intents to dump: error getting database names: (Unauthorized) there are no users authenticated

This is mongorestore output

yuriipredborskyi@Yuriis-MacBook-Pro ~ % mongorestore -vvvv
2020-10-06T10:03:01.757+0200	using write concern: &{majority false 0}
2020-10-06T10:03:01.766+0200	checking options
2020-10-06T10:03:01.766+0200		dumping with object check disabled
2020-10-06T10:03:01.766+0200	will listen for SIGTERM, SIGINT, and SIGKILL
2020-10-06T10:03:01.769+0200	connected to node type: standalone
2020-10-06T10:03:01.769+0200	using default 'dump' directory
2020-10-06T10:03:01.769+0200	try 'mongorestore --help' for more information
2020-10-06T10:03:01.769+0200	Failed: mongorestore target 'dump' invalid: stat dump: no such file or directory
2020-10-06T10:03:01.769+0200	0 document(s) restored successfully. 0 document(s) failed to restore.

This is mongodump with connection string

yuriipredborskyi@Yuriis-MacBook-Pro ~ % mongodump -vvvv mongodb://127.0.0.1:27017
2020-10-06T10:03:41.700+0200	initializing mongodump object
2020-10-06T10:03:41.700+0200	will listen for SIGTERM, SIGINT, and SIGKILL
2020-10-06T10:03:41.702+0200	starting Dump()
2020-10-06T10:03:41.702+0200	found databases: admin, config, local, test
2020-10-06T10:03:41.703+0200	enqueued collection 'admin.system.version'
2020-10-06T10:03:41.703+0200	will not dump system collection 'config.system.sessions'
2020-10-06T10:03:41.703+0200	enqueued collection 'test.toast'
2020-10-06T10:03:41.703+0200	dump phase I: metadata, indexes, users, roles, version
2020-10-06T10:03:41.703+0200		reading indexes for `test.toast`
2020-10-06T10:03:41.704+0200		reading indexes for `admin.system.version`
2020-10-06T10:03:41.706+0200	writing admin.system.version to dump/admin/system.version.bson
2020-10-06T10:03:41.707+0200	counted 1 document in admin.system.version
2020-10-06T10:03:41.707+0200	done dumping admin.system.version (1 document)
2020-10-06T10:03:41.707+0200	dump phase II: regular collections
2020-10-06T10:03:41.707+0200	finalizing intent manager with longest task first prioritizer
2020-10-06T10:03:41.707+0200	dumping up to 2 collections in parallel
2020-10-06T10:03:41.707+0200	starting dump routine with id=1
2020-10-06T10:03:41.707+0200	starting dump routine with id=0
2020-10-06T10:03:41.707+0200	ending dump routine with id=0, no more work to do
2020-10-06T10:03:41.708+0200	writing test.toast to dump/test/toast.bson
2020-10-06T10:03:41.708+0200	counted 1 document in test.toast
2020-10-06T10:03:41.708+0200	done dumping test.toast (1 document)
2020-10-06T10:03:41.708+0200	ending dump routine with id=1, no more work to do
2020-10-06T10:03:41.708+0200	dump phase III: the oplog
2020-10-06T10:03:41.708+0200	finishing dump

I made this dump to

  • make sure mongodump works
  • see if there is any difference in creating a dump and restoring from a dump when not using a connection string depending on existence of the dump folder

 

This is mongorestore without connection string with existing dump folder and existing dump

yuriipredborskyi@Yuriis-MacBook-Pro ~ % mongorestore -vvvv
2020-10-06T10:07:19.980+0200	using write concern: &{majority false 0}
2020-10-06T10:07:19.989+0200	checking options
2020-10-06T10:07:19.989+0200		dumping with object check disabled
2020-10-06T10:07:19.989+0200	will listen for SIGTERM, SIGINT, and SIGKILL
2020-10-06T10:07:19.993+0200	connected to node type: standalone
2020-10-06T10:07:19.993+0200	using default 'dump' directory
2020-10-06T10:07:19.993+0200	mongorestore target is a directory, not a file
2020-10-06T10:07:19.993+0200	preparing collections to restore from
2020-10-06T10:07:19.993+0200	using dump as dump root directory
2020-10-06T10:07:19.993+0200	reading collections for database admin in admin
2020-10-06T10:07:19.993+0200	found collection admin.system.version bson to restore to admin.system.version
2020-10-06T10:07:19.993+0200	found collection metadata from admin.system.version to restore to admin.system.version
2020-10-06T10:07:19.993+0200	reading collections for database test in test
2020-10-06T10:07:19.993+0200	found collection test.toast bson to restore to test.toast
2020-10-06T10:07:19.993+0200	found collection metadata from test.toast to restore to test.toast
2020-10-06T10:07:19.993+0200	finalizing intent manager with multi-database longest task first prioritizer
2020-10-06T10:07:19.993+0200	restoring up to 4 collections in parallel
2020-10-06T10:07:19.993+0200	starting restore routine with id=3
2020-10-06T10:07:19.993+0200	starting restore routine with id=0
2020-10-06T10:07:19.993+0200	ending restore routine with id=0, no more work to do
2020-10-06T10:07:19.993+0200	starting restore routine with id=1
2020-10-06T10:07:19.993+0200	ending restore routine with id=1, no more work to do
2020-10-06T10:07:19.993+0200	starting restore routine with id=2
2020-10-06T10:07:19.993+0200	ending restore routine with id=2, no more work to do
2020-10-06T10:07:19.995+0200	finished restoring test.toast (0 documents, 0 failures)
2020-10-06T10:07:19.995+0200	Failed: test.toast: error reading database: (Unauthorized) there are no users authenticated
2020-10-06T10:07:19.995+0200	0 document(s) restored successfully. 0 document(s) failed to restore.

As far as I can see, it reads the contents of the dump without an issue, the issue arises when it tries to connect to database when I'm not using a connection string

 

Here's mongorestore with connection string

yuriipredborskyi@Yuriis-MacBook-Pro ~ % mongorestore -vvvv mongodb://127.0.0.1:27017
2020-10-06T10:09:06.329+0200	using write concern: &{majority false 0}
2020-10-06T10:09:06.331+0200	checking options
2020-10-06T10:09:06.331+0200		dumping with object check disabled
2020-10-06T10:09:06.331+0200	will listen for SIGTERM, SIGINT, and SIGKILL
2020-10-06T10:09:06.331+0200	connected to node type: standalone
2020-10-06T10:09:06.332+0200	using default 'dump' directory
2020-10-06T10:09:06.332+0200	mongorestore target is a directory, not a file
2020-10-06T10:09:06.332+0200	preparing collections to restore from
2020-10-06T10:09:06.332+0200	using dump as dump root directory
2020-10-06T10:09:06.332+0200	reading collections for database admin in admin
2020-10-06T10:09:06.332+0200	found collection admin.system.version bson to restore to admin.system.version
2020-10-06T10:09:06.332+0200	found collection metadata from admin.system.version to restore to admin.system.version
2020-10-06T10:09:06.332+0200	reading collections for database test in test
2020-10-06T10:09:06.332+0200	found collection test.toast bson to restore to test.toast
2020-10-06T10:09:06.332+0200	found collection metadata from test.toast to restore to test.toast
2020-10-06T10:09:06.332+0200	finalizing intent manager with multi-database longest task first prioritizer
2020-10-06T10:09:06.332+0200	restoring up to 4 collections in parallel
2020-10-06T10:09:06.332+0200	starting restore routine with id=3
2020-10-06T10:09:06.332+0200	starting restore routine with id=1
2020-10-06T10:09:06.332+0200	ending restore routine with id=1, no more work to do
2020-10-06T10:09:06.332+0200	starting restore routine with id=0
2020-10-06T10:09:06.332+0200	ending restore routine with id=0, no more work to do
2020-10-06T10:09:06.332+0200	starting restore routine with id=2
2020-10-06T10:09:06.332+0200	ending restore routine with id=2, no more work to do
2020-10-06T10:09:06.332+0200	reading metadata for test.toast from dump/test/toast.metadata.json
2020-10-06T10:09:06.332+0200	creating collection test.toast using options from metadata
2020-10-06T10:09:06.332+0200	using collection options: primitive.D{primitive.E{Key:"idIndex", Value:mongorestore.IndexDocument{Options:primitive.M{"name":"_id_", "ns":"test.toast"}, Key:primitive.D{primitive.E{Key:"_id", Value:1}}, PartialFilterExpression:primitive.D(nil)}}}
2020-10-06T10:09:06.348+0200	restoring test.toast from dump/test/toast.bson
2020-10-06T10:09:06.349+0200	using 1 insertion workers
2020-10-06T10:09:06.350+0200	no indexes to restore
2020-10-06T10:09:06.350+0200	finished restoring test.toast (1 document, 0 failures)
2020-10-06T10:09:06.350+0200	ending restore routine with id=3, no more work to do
2020-10-06T10:09:06.350+0200	1 document(s) restored successfully. 0 document(s) failed to restore.

Please let me know if there is a way to check what connection string (or connection parameters) is used by default when I run mongodump / mongorestore on my machine. I don't think I changed it as mongo connects without an issue, compass connects without an issue (but it connects to localhost:27017 by default, so maybe it works around the default config somehow). It is possible mongodump / mongorestore uses a different default connection string from a config I am not aware of, although I do believe this is unlikely.

Comment by Andrew Feierabend (Inactive) [ 05/Oct/20 ]

Hi yurii.p@masterborn.com. Great, thanks for letting us know!

Could you try running mongodump and mongorestore on your machine with the following verbose parameters (omitting the explicit localhost IP)?

mongodump -vvvv
 
mongorestore -vvvv

We'd like to try to reproduce the issue if possible, and this output would help us do so. Thanks!

Comment by Yurii Predborskyii [ 05/Oct/20 ]

Hi, sorry for the late response.

The command

mongodump mongodb://127.0.0.1:27017

worked great as soon as I added connection string.

I tried with mongorestore and had the same issue - when trying to execute restore "as is" (without connection string) I got an error, using connection string worked great.

mongorestore mongodb://127.0.0.1:27017

Thanks for help!

Maybe my Mac tries to execute some other connection by default, but I have no spare macs in "clean" state to test this hypothesis, sadly. When trying to execute mongodump without connection string, it fails right after "starting Dump()", without mentioning connection parameters.

Comment by Andrew Feierabend (Inactive) [ 29/Sep/20 ]

EDIT: I adjusted the above command to include verbose output, for troubleshooting.

Comment by Andrew Feierabend (Inactive) [ 29/Sep/20 ]

Hello yurii.p@masterborn.com, thanks for your patience. Can you try with the following slight adjustment to your invocation of mongodump:

mongodump -vvvv mongodb://127.0.0.1:27017

This is assuming that you use the default port of 27017. Thank you!

Comment by Yurii Predborskyii [ 24/Sep/20 ]

Thanks! It would be great to have this resolved, please let me know if there's anything I can do to help.

Comment by Andrew Feierabend (Inactive) [ 23/Sep/20 ]

yurii.p@masterborn.com Thank you very much for your detailed troubleshooting steps, and for repeating my steps and attaching your log. We're looking into this now.

Comment by Yurii Predborskyii [ 23/Sep/20 ]

@Andrew

I've attached a log trying to repeat the same actions as you did. My result was different in the last step - I get an error instead of an export.

log.txt

Comment by Yurii Predborskyii [ 23/Sep/20 ]

I'm not sure this will work "from scratch" as I don't have spare fresh-new macs lying around waiting to have mongodb installed on them for the first time ever so I tried to create a similar condition:

I uninstalled mongodb from my system and cleaned up all the remaining files. I then reinstalled mongodb, added it as a service and installed standalone tools using homebrew by following official docs:
https://docs.mongodb.com/manual/tutorial/install-mongodb-on-os-x/#install

The following steps should take you to a similar result (as close as possible, probably, since these are the steps I've taken initially)

  1. Install x-code tools on mac (I'm on mac and this seems to be the best way to make it)
  2. Install homebrew on mac.
  3. Install mongodb using homebrew package manager (mongodb-community@4.4)
  4. Run mongodb as a service using homebrew, according to manual.
  5. Restart mac (not sure this is necessary)
  6. Create a new db "toast" with collection "test" using mongo compass. Add a document or two.
  7. Install mongodb database tools using homebrew 

    brew install mongodb-database-tools

    (official docs offer a standalone zip which doesn't make them available via CLI)

  8. Run the following command:

    mongodump -d toast 

 

Expected result:

a dump is created that contains all collections of db "toast" and can be imported

Actual result:

Failed: error creating intents to dump: error getting collections for database `toast`: (Unauthorized) there are no users authenticated

I don't have any users in my database, the database is empty, I can log in using compass without any user or password, I can connect to it just fine using CLI. I can also connect from my node.js application without any user or password.

I'd rather export via Compass but that is not an option - Compass can only export one collection at a time, as far as I'm aware.

Comment by Andrew Feierabend (Inactive) [ 22/Sep/20 ]

Hi yurii.p@masterborn.com, I am unable to replicate this error in either 4.4.0 or 4.4.1.
I have attached my troubleshooting efforts for both versions to this ticket.

Can you provide the steps required to reproduce this error, starting with a fresh download of the MongoDB Server and the Database Tools, so that I can further troubleshoot?

Thanks very much.

Generated at Thu Feb 08 08:08:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.