1Panel-dev/1Panel · error · Error
failed to drop users from ${dbName}
Error message
failed to drop users from ${dbName} What it means
Thrown by a generated mongosh script (buildMongodbDeleteScript) executed via `docker exec <container> mongosh <admin-uri> --eval <script>` when `targetDb.runCommand({ dropAllUsersFromDatabase: 1 })` returns a result whose `ok` field is not 1. It is not a Go error: the agent builds the JS with the JSON-marshaled dbName and surfaces whatever the script throws. `ok !== 1` almost always means the connected user lacks the `dropUser`/`userAdmin` privilege on that database or the authenticationDatabase does not match where the users live.
Source
Thrown at agent/app/service/database_mongodb.go:439
targetDb.createUser({
user: userName,
pwd: password,
roles: [{ role: permission, db: dbName }]
});
`, dbNameJSON, usernameJSON, passwordJSON, permissionJSON)), nil
}
func buildMongodbDeleteScript(dbName string) (string, error) {
dbNameJSON, err := json.Marshal(dbName)
if err != nil {
return "", err
}
return strings.TrimSpace(fmt.Sprintf(`
const dbName = %s;
const targetDb = db.getSiblingDB(dbName);
const dropUsersResult = targetDb.runCommand({ dropAllUsersFromDatabase: 1 });
if (!dropUsersResult || dropUsersResult.ok !== 1) {
throw new Error("failed to drop users from " + dbName);
}
const dropDatabaseResult = targetDb.runCommand({ dropDatabase: 1 });
if (!dropDatabaseResult || dropDatabaseResult.ok !== 1) {
throw new Error("failed to drop database " + dbName);
}
`, dbNameJSON)), nil
}
func buildMongodbBindUserScript(dbName, username, password string) (string, error) {
dbNameJSON, err := json.Marshal(dbName)
if err != nil {
return "", err
}
usernameJSON, err := json.Marshal(username)
if err != nil {
return "", err
}
passwordJSON, err := json.Marshal(password)View on GitHub (pinned to 5ac7c80881)
Solutions
- Verify the stored credential is privileged: `docker exec <container> mongosh -u <user> -p <pass> --authenticationDatabase admin --eval 'db.runCommand({connectionStatus:1}).authInfo.authenticatedUserRoles'` and confirm a root/userAdminAnyDatabase role
- If the credential is stale, update the app install's username/password in 1Panel to the real root account and retry the delete
- Run the drop manually to see the raw server error: `db.getSiblingDB("<dbName>").runCommand({dropAllUsersFromDatabase:1})` inside the container and read `codeName`/`errmsg`
- If users live on `admin`, drop them with an explicit user deletion on admin before re-running the delete
Example fix
// before: rely on stored (possibly non-root) credential
runMongodbAdminScript(database, script)
// after (operational fix): confirm privilege before delete flow
// docker exec <c> mongosh -u root -p <pass> --authenticationDatabase admin --eval \
// 'db.getSiblingDB("mydb").runCommand({dropAllUsersFromDatabase:1})' Defensive patterns
Strategy: try-catch
Validate before calling
// before invoking the delete flow, verify privilege on the db
// docker-side: db.getSiblingDB(dbName).runCommand({dropAllUsersFromDatabase:1})
// code-side: check roles first
roles, _ := runMongodbAdminScriptWithStdout(database, "printjson(db.runCommand({connectionStatus:1}).authInfo.authenticatedUserRoles)") Try / catch
// wrap the service call; on failure surface container logs for the raw codeName
if err := service.DeleteMongodbDatabase(...); err != nil {
if strings.Contains(err.Error(), "failed to drop users") {
// pull `docker logs <container>` tail and show codeName/errmsg to the user
}
return err
} Prevention
- Keep the 1Panel app-install credential as the MongoDB root user
- Rotate credentials through 1Panel, never directly in mongosh
- Test delete on a scratch database right after install to validate the privilege path early
When it happens
Trigger: Calling the 1Panel database-delete flow for a MongoDB install where: (a) the app install's stored username/password is not root/admin (e.g. a limited user was set after install), (b) users were created on the `admin` db while the script runs against the target db (or vice versa), or (c) the mongosh URI built by buildMongodbRestoreURI authenticates against a db where dropAllUsersFromDatabase is forbidden.
Common situations: MongoDB container whose root password was rotated outside 1Panel so the stored credential authenticates as a non-privileged user; installs that use a custom user instead of root; MongoDB 5+ where users commonly live in `admin` and dropping them from the target db yields a permission error.
Related errors
- failed to drop database ${dbName}
- failed to load mongodb user ${userName}
- failed to list mongodb databases
- failed to update mongodb user ${userName}
- failed to load mongodb user privileges
AI-assisted analysis of 1Panel-dev/1Panel@5ac7c80881 (2026-08-15).
Data as JSON: /api/errors/df6776778553a925.
Report an issue: GitHub.