- Error code
- 13
- Code name
Unauthorized- Product
- MongoDB
- Versions
- MongoDB 7.0 and 8.0 (wording checked against the 8.0 source)
- Category
- Authentication & Authorisation
- Last reviewed
- 24 October 2026
On this page
What it means
Error 13 (Unauthorized) means access control is on and the connection is either not logged in or its user lacks a role that grants the action the command needs, so MongoDB refused the command.
With access control enabled, every command needs a privilege: an action (find, insert, update, createIndex and so on) on a resource (a database, a collection or the cluster). Users get privileges from roles. When the connection's users hold no role that grants the required action on the target resource, MongoDB 8.0 raises code 13 with not authorized on <database> to execute command <command>, followed by the command document (with sensitive parts removed). The database named is the one the command ran against, which is the first thing to check.
The same code covers two other cases with different wording. Command <name> requires authentication means the connection never authenticated (no credentials in the connection string, or the login silently was not used). <command> may only be run against the admin database. means an administrative command was sent to an application database. A failed login itself is a different error, 18 AuthenticationFailed.
Common causes
- The user has a role on a different database: for example readWrite on
testwhile the application writes toshop. - The user has
readbut the command writes (insert, update, delete) or creates an index; both need at least readWrite on that database. - The connection is not authenticated: the connection string has no credentials, so every command that requires authentication fails.
- The command needs a cluster-level or admin privilege (listDatabases across all databases, serverStatus, replSetGetStatus, currentOp for other users) that application roles do not include.
- The user exists in one authentication database but the role grants were made to a same-named user in another database.
- A custom role was changed or a role was revoked, and the application lost an action it used to have.
Diagnose it
Read-only These mongosh commands only read data, indexes, statistics and server state (find, aggregate without $out or $merge, getIndexes, stats, currentOp, rs.status). They do not change data, users or settings, so they are safe to run first.
Who is this connection, and what can it do?
db.runCommand({ connectionStatus: 1, showPrivileges: true })authInfo.authenticatedUsers (empty means not logged in), authenticatedUserRoles with the database each role applies to, and authenticatedUserPrivileges: the actions per resource. Look for the action the failing command needs on the database named in the message.
Show the user's roles (run in the user's authentication database)
db.getSiblingDB("admin").getUser("appUser", { showPrivileges: true })The user's roles and inherited privileges. Reading another user needs the viewUser action; a user can always read its own entry. If the roles are on a different database from the one in the error, that is the cause.
Check which database the command really runs against
db.getName()The current database in mongosh. In applications, the database comes from the client code or the path in the connection string. The $db field in the logged command shows it too.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Grant the narrowest built-in role on the right database
Changes permissionsAn administrator (a user with userAdmin or userAdminAnyDatabase) grants the role the application needs, on the database it actually uses. For a normal application, readWrite on its own database is usually enough; reporting users need only read.
Caution: Grant on the specific database, not with AnyDatabase roles, root or dbOwner. Broad roles hide the real requirement and give the application far more access than it needs.
db.getSiblingDB("admin").grantRolesToUser("appUser", [
{ role: "readWrite", db: "shop" }
])Create a custom role for one extra action
Changes permissionsWhen the application needs a single action that no small built-in role grants (for example only find and insert on one collection), create a role with exactly those privileges and grant it.
db.getSiblingDB("admin").createRole({
role: "ordersWriter",
privileges: [
{ resource: { db: "shop", collection: "orders" }, actions: [ "find", "insert" ] }
],
roles: []
})
db.getSiblingDB("admin").grantRolesToUser("appUser", [ { role: "ordersWriter", db: "admin" } ])Authenticate the connection
Client or network sideFor requires authentication, add credentials to the connection and set authSource to the database where the user was created (admin by default when the URI names no database). Percent-encode special characters in the password.
// mongosh
mongosh "mongodb://appUser@db1.example.net:27017/shop?authSource=admin"
// or inside an open shell
db.getSiblingDB("admin").auth("appUser", passwordPrompt())Run admin-only commands against admin
Client or network sideFor may only be run against the admin database, send the command with db.adminCommand() or db.getSiblingDB("admin"); the user still needs the matching cluster privilege, for example from clusterMonitor for status commands.
db.adminCommand({ replSetGetStatus: 1 })Examples
A read-only user tries to insert
Not reproduced here: no MongoDB server is installed for this site. The wording is built in MongoDB 8.0's command code (commands.cpp: "not authorized on " + database + " to execute command " + the redacted command). The fields in the command document depend on the client and are illustrative.
// connected as reportUser, which has { role: "read", db: "shop" }
use shop
db.orders.insertOne({ item: "pen", qty: 2 })MongoServerError: not authorized on shop to execute command { insert: "orders", ordered: true, lsid: { id: UUID("...") }, $db: "shop" }
A connection without credentials
Not reproduced here: no MongoDB server is installed for this site. The wording comes from MongoDB 8.0's command code (commands.cpp, checkAuthorizationImplPreParse) with this example's command name filled in.
// mongosh "mongodb://db1.example.net:27017/shop" (no user in the URI)
db.orders.find()MongoServerError: Command find requires authentication
How to prevent it
Give each application its own user with roles only on the databases it uses, and record the required roles next to the deployment configuration. Test with that user, not an admin account, so missing privileges appear before release.
Run connectionStatus with showPrivileges at application start-up in non-production environments, and alert on code 13 in logs: it usually means a role or database name drifted.
Common questions
How do I fix "not authorized on admin to execute command" in MongoDB?
Check which command it is. Commands such as listDatabases, serverStatus or replSetGetStatus need cluster privileges; grant a narrow role such as clusterMonitor if the user really needs them. Often the application ran a command on admin by mistake and should target its own database instead.
My user has readWrite, so why do I still get error 13?
The role is tied to one database. readWrite on test does not cover shop. Compare authenticatedUserRoles from connectionStatus with the database named in the error, and grant the role on the right database.
Is error 13 the same as a wrong password?
No. A wrong user name or password fails the login with error 18 AuthenticationFailed. Error 13 comes after login (or with no login at all) when a command is not allowed.
Official documentation
Last technically reviewed 24 October 2026; examples and diagnostics run on MongoDB 8.0 documentation and source (error_codes.yml r8.0.0); not run locally. Codes and code names are checked against MongoDB's error_codes.yml (8.0); no MongoDB server was available, so the examples were not run locally.