I've installed a MongoDB on Google Cloud Compute Engine via a Bitnami script. I can see the vm instance in the Google Cloud dashboard. I can connect to the database using my deployed node.js app. My app works just fine.
What I can't figure out is how to independently verify the content in the Mongo database.
On the Compute Cloud dashboard for the Mongo DB VM, there is a SSH pulldown button at the top of the screen. Clicking this button opens up a browser frame. The frame connects to the VM instance via https, and confirms login info. I've seen this related stackoverflow posting, and I've met all of these suggestions. Settings confirmed at the Google Cloud VM instance interface. When I type mongo I can see the mongo shell. When I try show dbs I get back unexpected results:
show dbs
2017-02-19T05:51:45.161+0000 E QUERY [thread1] Error: listDatabases failed:{
"ok" : 0,
"errmsg" : "not authorized on admin to execute command { listDatabases: 1.0 }",
"code" : 13,
"codeName" : "Unauthorized"
} :
How can I do a simple show dbs and then show collections and finally db.foo.find() to confirm data content?
Ouch. So it turns out I missed something. When I created the instance the system sent me an confirmation email. In the email were a couple of key links.
There are two very different methods to "connect" to the database.
The first is to open the mongo shell interface via an admin / login.
$ mongo admin --username root -p
MongoDB shell version v3.4.2
Enter password: (password entered here)
connecting to: mongodb:///opt/bitnami/mongodb/tmp/mongodb-27017.sock/admin
MongoDB server version: 3.4.2
This worked quite well, without having to transfer SSH keys at all. Reference link here. At this point I could
> show dbs
admin 0.000GB
local 0.000GB
> use admin
switched to db admin
> show collections
books
system.users
system.version
> db.books.find()
{ "_id" : ObjectId("58a900452c972b0010def8a7"), "title" : "Mr. Tickle", "author" : "Roger Hargreaves", "publishedDate" : "1971", "description" : "" }
{ "_id" : ObjectId("58a900612c972b0010def8a8"), "title" : "Mr. Sneeze", "author" : "Roger Hargreaves", "publishedDate" : "1982", "description" : "" }
{ "_id" : ObjectId("58a93a192c972b0010def8a9"), "title" : "Mr. Happy", "author" : "Roger Hargreaves", "publishedDate" : "1971", "description" : "" }
>
The second method is to register SSH keys, via these instructions over at Bitnami.com
In this method, you have to first add your public SSH key via the Google Cloud interface to the instance.
Related
I'm learning MongoDB and trying to use Atlas. I created a remote cluster and tried to connect it using both MongoDB Compass and Studio 3T. However, I noticed that after connecting with Studio 3T, there was an empty database named "test" appearing in the left panel, below "admin" and "local" databases. Where did it come from? And how can I drop it? Because when I tried to drop this database, I got this error
Mongo Server error (MongoCommandException): Command failed with error 8000 (AtlasError): 'user is not allowed to do action [dropDatabase] on [test.]' on server ac-bkmhuxm-shard-00-02.w2nutv2.mongodb.net:27017.
The full response is:
{
"ok" : 0.0,
"errmsg" : "user is not allowed to do action [dropDatabase] on [test.]",
"code" : 8000.0,
"codeName" : "AtlasError"
}
After changing the roles in Atlas, I can now delete the database. However it keeps appearing when I make a new connection to MongoDB. Why is that?
Database test is the default database when you don't define anything.
Databases local, admin and config are MongoDB system internal databases, you should not touch them unless advised by MongoDB support or special admin tasks.
See also 3 default database in MongoDB
I'm moving a website and Mongo database to a new server.
Website can't see the data.
Mongo is installed and running on the same server.
Shell and server are both 3.6.3
Mongo shell sees the database.
From the shell,
dbs returns the database name.
use dbname appears to work.
db.getCollectionNames() returns a reasonable collection name. Say ["myCollection"]
.
db.getCollection("myColection").getIndexes() returns
[
{
"v" : 2,
"key" : {
"_id" : 1
},
"name" : "id",
"ns" : "myDB.myCollection"
}
]
But after that, I can't get any further.
db.myCollection.find() and
db.getCollection("myCollection").find() both return nothing.
Everything in the log looks correct, no errors.
Does that tell us anything?
Use below to backup
Mongodump --out <directory>
and below to restore
mongorestore <collectionName><path to the backup>
One of the features of Mongo is that you can create a database or collection just by mentioning it.
Turns out that someone had tried to import the data and failed. So when I looked at 'show dbs' and 'getCollectionNames', it looked like it was working.
The files I saw in the database directory were export files that hadn't actually been imported.
I recently opened up a free mLab account, and I'm trying to access the number of open connections in my database through the shell.
I never had problems with the command line when I was running mongodb locally, but now nothing works.
To connect I do this:
mongo ds127044.mlab.com:27044/db_name -u db_user -p db_password
And it show I'm successfully connected.
After that I run:
db.serverStatus()
And get:
{
"ok" : 0,
"errmsg" : "not authorized on admin to execute command { serverStatus: 1.0 }",
"code" : 13,
"codeName" : "Unauthorized"
}
But according to my console I'm listed as the owner of the db:
{
"_id": "db_name.db_user",
"user": "db_user",
"db": "db_name",
"roles": [
{
"role": "dbOwner",
"db": "db_name"
}
]
}
Is there something I'm doing wrong in the command line or is it something particular to my account with mLab?
Seems to be something related with your user's roles.
All documentation here: https://docs.mongodb.com/manual/reference/built-in-roles/#cluster-admin-roles/ (specifically cluesterMonitor information)
Say:
...The admin database includes the following roles for administering the
whole system rather than just a single database...
And in this Doc https://docs.mongodb.com/manual/core/security-built-in-roles/
Say:
Every database includes: Database Administration Roles... The
admin database includes the following roles for administering the
whole system: Cluster Administration Roles
'serverStatus' is realted to clusterMonitor role so..
Try to change it:
roles: [ { role: "clusterMonitor", db: "admin" },
{ role: "dbOwner", db: "db_name" }]
Good luck!
Not a mongodb expert, but here's what I found in the docs.
db.serverStatus() shares instance info in its output. For example:
host
The system’s hostname. In Unix/Linux systems, this should be the same as the output of the hostname command.
mLab wouldn't expose host info to end users, who should only have access to the dbs they're creating--specifically, the db you logged into.
Similarly, you'll run into issues with other calls like show dbs, since that would expose all the dbs (including dbs for other users!) existing alongside your own.
I imagine that the only commands that will work are ones that expose info completely related to only your db. I suggest hitting up a more export mongodb admin perhaps in a separate question for that definitive list, if necessary.
I fixed this exact issue by changing my mac settings to allow remote login.
System Preferences -> Sharing -> Remote Login: On
I would like to move the local implementations (mongoDB gridFS content repository) to cloud Heroku using mLAB. But I have a problem because some of the functionality of generating below error :
"errmsg" : "not authorized on admin to execute command {
listDatabases: 1.0 }", "code" : 13
Does anyone have an idea how to fix it?
Thanks for any help
I'm trying to clone a remotely hosted collection to my local Mongo database. I tried opening up the mongo console in the local environment and issued:
db.runCommand({cloneCollection: "<dbname.colname>", from: "<remotehost:port>"})
It fails with
"errmsg" : "exception: nextSafe(): { $err: \"not authorized for query on <dbname>.system.namespaces\", code: 16550 }",
"code" : 13106,
How do I properly authorize with the remote server to clone the collection?
Unfortunately that's currently not possible. There is a Jira ticket open for this feature. As a workaround you could consider using mongodump --collection and mongorestore.