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

  1. 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
  2. If the credential is stale, update the app install's username/password in 1Panel to the real root account and retry the delete
  3. Run the drop manually to see the raw server error: `db.getSiblingDB("<dbName>").runCommand({dropAllUsersFromDatabase:1})` inside the container and read `codeName`/`errmsg`
  4. 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

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


AI-assisted analysis of 1Panel-dev/1Panel@5ac7c80881 (2026-08-15). Data as JSON: /api/errors/df6776778553a925. Report an issue: GitHub.