prestodb/presto · error · AccessDeniedException

Cannot select from table %s%s

Error message

Cannot select from table %s%s

What it means

Presto throws this AccessDeniedException (PERMISSION_DENIED / ACCESS_DENIED) when the identity is not authorized to read (SELECT) from a table. The connector's AccessControl.checkCanSelectFromTable implementation denied the query via denySelectTable, aborting the query before execution. This is the most common Presto authorization denial: the user simply lacks read access to the table.

Source

Thrown at presto-spi/src/main/java/com/facebook/presto/spi/security/AccessDeniedException.java:217

    public static void denyRenameColumn(String tableName)
    {
        denyRenameColumn(tableName, null);
    }

    public static void denyRenameColumn(String tableName, String extraInfo)
    {
        throw new AccessDeniedException(format("Cannot rename a column in table %s%s", tableName, formatExtraInfo(extraInfo)));
    }

    public static void denySelectTable(String tableName)
    {
        denySelectTable(tableName, null);
    }

    public static void denySelectTable(String tableName, String extraInfo)
    {
        throw new AccessDeniedException(format("Cannot select from table %s%s", tableName, formatExtraInfo(extraInfo)));
    }

    public static void denyInsertTable(String tableName)
    {
        denyInsertTable(tableName, null);
    }

    public static void denyInsertTable(String tableName, String extraInfo)
    {
        throw new AccessDeniedException(format("Cannot insert into table %s%s", tableName, formatExtraInfo(extraInfo)));
    }

    public static void denyDeleteTable(String tableName)
    {
        denyDeleteTable(tableName, null);
    }

    public static void denyDeleteTable(String tableName, String extraInfo)

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Grant SELECT on the table to the user in the security system (Ranger policy, access-control.properties group, Sentry role).
  2. Verify the principal: run SELECT current_user and confirm it matches the account with grants.
  3. Check you are querying the intended catalog/schema (grants are usually per catalog).
  4. If a view should be used, have an admin create a view over the table and grant SELECT on the view instead.

Example fix

// access-control.properties (file-based)
// before
security.read.admin=admin,etl

// after
security.read.admin=admin,etl,analyst   # grant read to the denied user
Defensive patterns

Strategy: try-catch

Validate before calling

// Verify grants before querying
ResultSet g = stmt.executeQuery("SHOW GRANTS ON TABLE " + tableRef);
boolean canSelect = grantsContain(g, currentUser, "SELECT");
if (!canSelect) { /* request access or fall back to a view */ }

Try / catch

try (Statement st = conn.createStatement()) {
    return st.executeQuery("SELECT * FROM " + table);
} catch (SQLException e) {
    if ("ACCESS_DENIED".equals(e.getSQLState())) {
        throw new TableAccessForbiddenException(table, e); // typed app-level error
    }
    throw e;
}

Prevention

When it happens

Trigger: Any SELECT (or CREATE TABLE AS SELECT, view creation) touching a table where the connector's checkCanSelectFromTable(Identity, SchemaTableName) denies the user; column-level checks may also route to denySelectColumns/denySelectTable.

Common situations: BI tools querying restricted tables; stale credentials after team/role changes; wrong catalog selected causing a non-existent permission mapping; file-based access-control.properties missing the user in the right category.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/64dc9b6aa64906b5. Report an issue: GitHub.