MongoDB: dbclient_rs replSetGetStatus failed{ ok: 0.0, errmsg: "unauthorized" }

When I'm using mongodump or mongorestore on a replica set these messages appear in the verbose output:

dbclient_rs replSetGetStatus failed{ ok: 0.0, errmsg: "unauthorized" }

The replica set is configured for authentication and the user account I'm connecting with has the clusterAdmin role set, which makes me wonder why the clients (mongodump/restore) aren't authorized to execute replSetGetStatus.

The connecting user has the userAdminAnyDatabase, readWriteAnyDatabase, dbAdminAnyDatabase and clusterAdmin roles on the admin database.

Here is an exemplified mongodump command:

mongodump --host rs0/host0.example.org,host1.example.org,host2.example.org \
          --port 27017 \
          --ssl \
          --ipv6 \
          --verbose \
          --authenticationDatabase admin \
          --username *user* \
          --password *password* \
          --out bakdir \
          --db admin

mongod, mongodump and mongorestore are version 2.4.10, installed from the Debian Jessie (stable) repository.

I'd like to know why it fails, what the implications of these failings are and what I possibly can do about it (except switching off authentication ;-). Besides this quirk mongodump/restore seem to do their jobs just fine.

Here is the verbose log output from mongodump (timestamps truncated and hostnames replaced):

```
[Timestamp.381] starting new replica set monitor for replica set rs0 with seed of host0.example.org:27017,host1.example.org:27017,host2.example.org:27017
[Timestamp.381] creating new connection to:host0.example.org:27017
[Timestamp.383] BackgroundJob starting: ConnectBG
[Timestamp.412] connected connection!
[Timestamp.412] successfully connected to seed host0.example.org:27017 for replica set rs0
[Timestamp.413] ReplicaSetMonitor::_checkConnection: host0.example.org:27017 { setName: "rs0", ismaster: true, secondary: false, hosts: [ "host0.example.org:27017", "host2.example.org:27017", "host1.example.org:27017" ], primary: "host0.example.org:2701

Original Answer (leaving for people that might hit this because of the simple explanation):

The clusterAdmin role only applies when you authenticate against the admin database, so unless you specify the --authenticationDatabase option to be admin when you are running mongodump/mongorestore I suspect you are getting a lesser privilege when authing against the DB you are dumping/restoring and hence seeing the errors.

Follow up:

This issue looks like a bug, but besides some tangential issues, I can't find an issue that corresponds to a fix here. As of writing this, there have been 2 major releases since 2.4.10 (released April 2014), and even 2.4 has several subsequent updates (2.4.15 was release April 2015). Normally I would recommend filing a bug but 2.4 has reached EOL, so unless you can reproduce this with 2.6 or 3.0 then it won't be actioned.

Additionally, the tools (dump, restore etc.) have since been completely refactored (even have their own repo and project) and are even written in a different language now.

I don't believe the errors are impacting your data dump, so it's up to you in terms of how much effort you want to expend on this, but at a minimum I would recommend upgrading to a non-EOL version of MongoDB and retrying your process.

StackExchange Database Administrators Q#107193, answer score: 2