rs.status()报“not authorized”是因为缺少clusterMonitor角色权限，该权限需在admin库显式授予，且仅对副本集节点有效，连mongos时应改用sh.status()。
rs.status() 报错 “not authorized” 不是因为没开认证，而是权限根本没给对——它要的是集群级只读监控权，不是数据库读写权。
rs.status() 底层调用的是 replSetGetStatus 命令
这个命令不属于任何具体数据库（比如 test 或 myapp），而是直接作用于整个副本集。MongoDB 的 RBAC 机制里，数据库角色（如 read、dbOwner）完全不包含该权限。
- 即使你在
admin库创建了用户并授予了root角色，rs.status()在某些版本（如 4.4+）也可能因权限粒度收紧而失败 -
replSetGetStatus是管理命令（admin command），必须由显式拥有该 action 的角色授权 - 错误信息通常是：
"not authorized on admin to execute command { replSetGetStatus: 1, ... }"
必须在 admin 数据库执行 grantRolesToUser 并指定 db: "admin"
权限绑定必须发生在 admin 数据库上下文，且 db 字段不能省略或填错：
- 先切换到
admin：use admin - 再运行：
db.grantRolesToUser("myuser", [{ role: "clusterMonitor", db: "admin" }]) - 如果用户是在其他库（如
myapp）创建的，这次授权仍是有效的——但必须在admin库执行，否则权限不会注册进集群权限系统 - 验证是否生效：
db.runCommand({ rolesInfo: { role: "clusterMonitor", db: "admin" } })，确认输出中包含"replSetGetStatus"
分片集群中 rs.status() 会直接失效
如果你连的是 mongos 而非副本集中的某个 mongod，rs.status() 根本不可用——它只对副本集节点有效。
- 此时应改用
sh.status()，对应需要的是clusterManager或clusterAdmin角色 - 连错入口是常见误操作：检查你连接的 URI 是否含
mongos地址（如mongodb://a.b.c:27017,...），还是直连某mongod（如mongodb://node1:27017） - 另外，4.2+ 版本起
clusterMonitor不再隐式包含hostInfo权限，若还需执行db.runCommand({ hostInfo: 1 })，得额外加hostManager角色
最容易被忽略的一点：权限变更虽实时生效，但旧 shell 连接可能缓存了鉴权上下文；建议新开一个 mongosh 会话，用 mongo -u myuser -p --authenticationDatabase admin 重连后测试。否则你以为授了权，其实还在用旧 session 的权限快照。
