Metabase 查询报表 Permission Denied 权限拒绝错误怎么排查数据权限？

在 Metabase 里运行问题、看板或 SQL 查询时，如果报错类似 permission denied to <your table>，官方排查文档（Troubleshooting data permissions）给出的第一判断是：这类错误通常要先确认 Metabase 连接数据库所用的账户在数据库侧是否有权限，而不是先改 Metabase 里的权限设置。数据库侧的权限在连接层生效，发生在 Metabase 自身的数据权限和集合（collection）权限之前。

本文的排查路径来自项目文档：在 SQL editor 中最小化复现 → 用同一套数据库凭证在外部客户端交叉验证 → 由数据库管理员修复权限 → 用无痕窗口验证修复结果。你需要能访问 Metabase 的 SQL editor（或请管理员协助），以及数据库的连接凭证（不确定时找数据库管理员）。

第一步：在 SQL editor 中用最小查询复现

1. 打开 Metabase 的 SQL editor。
2. 对报错涉及的表或 schema 运行一条基础查询（将 <your table> 替换为报错信息中实际提到的表名）：

SELECT 1
FROM <your table>;

这一步的作用是把"某个问题查不了"缩小为"这个连接能不能查这张表"。如果这条最小查询也报 permission denied，继续第二步；如果连 SQL editor 本身都进不去，见文末的 SQL editor 无法访问 分支。

第二步：用 Metabase 同一套数据库凭证交叉验证

1. 拿到 Metabase 连接该数据库所使用的凭证。如果你不清楚连接用的是哪个账号，询问数据库管理员。
2. 用另一个应用（数据库 CLI 或 IDE）以同一套凭证连接到同一个数据库，运行第一步的查询。
3. 按文档给出的分支处理：
   • 两边都无法访问该表或 schema：说明是数据库侧权限不足。请数据库管理员二选一：
     • 为 Metabase 正在使用的角色（role）授予数据库权限；或
     • 提供一套权限正确的数据库凭证，更新 Metabase 的数据库连接。
   • 数据库侧可以查到，Metabase 里仍然失败：数据库连接账户不是根因，应转查 Metabase 侧的数据权限，即下一节的"表或 schema 权限"分支。文档将数据权限问题按粒度从细到粗分为三类：行/列权限、原生 SQL 查询权限、表或 schema 权限（见 Troubleshooting data permissions），可对照排查。

数据库侧权限基线（由数据库管理员执行）

Metabase 官方推荐的数据库侧配置（Users, roles, and privileges）：

• 创建专用的 metabase 数据库用户，只授予只读的最小权限；
• 最小权限 = 对数据库的 CONNECT，以及对要用到的 schema/表的 SELECT。

以 Postgres 为例，文档给出的写法如下（"your_database"、"your_password"、"your_schema"、"your_table" 均为占位符，需替换为实际值；原文还包含对整个数据库、整个 schema、或 Postgres 14+ 的 pg_read_all_data 的授权选项，可按需选用）：

-- Create a role named "analytics".
CREATE ROLE analytics WITH LOGIN;

-- Add the CONNECT privilege to the role.
GRANT CONNECT ON DATABASE "your_database" TO analytics;

-- Create a database user named "metabase".
CREATE USER metabase WITH PASSWORD "your_password";

-- Give the role to the metabase user.
GRANT analytics TO metabase;

-- Add query privileges: query anything in a specific TABLE.
GRANT USAGE ON SCHEMA "your_schema" TO analytics;
GRANT SELECT ON "your_table" IN SCHEMA "your_schema" TO analytics;

文档同时提醒：授予 role 权限时，拥有该 role 的所有用户都会获得这些权限，因此建议把权限打包进 role（如 analytics）而不是直接散授给用户。

若症状是"数据不对或看不到"而不是 permission denied

如果你遇到的不是报错，而是某人看到/看不到不该看到的数据，按 Troubleshooting permissions 的路径，先到 Admin > People 检查此人是否属于多个权限互相冲突的组。

表或 schema 权限：多组成员取"最宽松"权限

如果某人组表/ schema 的访问与预期不符（A user group has the wrong access to a table or schema）：

1. 到 Admin > People 检查此人是否属于多个组。
2. 如果是：要么把人移出权限更宽的组，要么到 Admin > Permissions 修改 Data access 权限类型。

原因（Permissions introduction）：权限授予对象是组而非个人；当一个人属于多个组时，Metabase 给予其所有组中权限最宽松的那一级。例如一个组授予某表 "Can view"、另一个组设为 "Blocked"，此人仍能查看数据。另外每个人默认都在 All Users 组里，文档建议先回收 All Users 组的权限，再新建组按需授权。

行/列权限（Row and column security）对 SQL 不生效

行/列安全只作用于查询构建器（query builder）生成的问题，以下是文档明确列出的边界（Row and column security 的 Limitations、Troubleshooting row and column security）：

• SQL 问题不受保护：Metabase 无法解析 SQL 查询，拥有 SQL（native query）访问权限的人对数据库的访问能力等同于连接账户，行/列安全对他们无效；
• SQL editor 权限与行/列安全互斥：如果对某组应用了行/列安全，就不能再给该组原生查询权限；
• 非 SQL 数据源不支持行/列安全；
• 公开分享和 guest embedding 无法被保护：未登录访问时 Metabase 拿不到用户属性或组信息，会显示全部结果；使用 SSO 时，若用户属性没有正确传入，行/列安全策略也会拒绝访问。

SQL editor 本身无法访问

如果某用户组根本打不开 SQL editor（A user group can't access the SQL editor）：

1. 禁用浏览器扩展并刷新，确认脚本能正常加载；
2. 到 Admin > Permissions 选中该组；
3. 找到目标数据库，将 View data 下拉设为 Can view；
4. 将 Create queries 下拉设为 Query builder and native；
5. 按下一节方式验证。

验证修复结果

文档给出的验证方式（Checking someone's access to a table or schema）：

1. 打开一个无痕（incognito）浏览器窗口；
2. 以问题当事人的身份登录 Metabase；
3. 运行一个相关的问题、看板或原生查询，确认能看到其应有权限的数据。

在改完数据库授权或 Metabase 权限设置后，都建议用这套流程复验一遍，而不是只在当前登录的账户下测试。

限制与版本说明

• Blocked 这一级 View data 权限（可以让组无论集合权限如何都看不到该数据库的数据）仅在 Pro 和 Enterprise 版本可用（Data permissions）。
• 开源免费版的 View data 固定默认为 "Can view"，不提供其他选项，该设置界面只在 Pro/Enterprise 中展示。
• 由于 Metabase 不解析 SQL：对某组设置 Blocked 后，即使只 Block 了单个表，该组也看不到查询同一数据库任意表的 native 问题结果；同理，组内只要有一张表是 Blocked 或行/列安全，该组对该数据库所有表的原生查询都会被禁用。

如果以上路径都无法解决，可继续在 Can't view or edit 和 Known issues 中核对是否属于集合权限、缓存或已知限制问题。