prestodb/presto · error · AccessDeniedException

Cannot update columns [%s] in table %s%s

Error message

Cannot update columns [%s] in table %s%s

What it means

This AccessDeniedException is thrown by Presto's authorization layer when the active access controller denies an UPDATE statement that modifies specific columns of a table. Connectors with security (e.g. Hive/system access control) call denyUpdateTableColumns when the current identity lacks the UPDATE privilege on the listed columns. It means the privilege decision came from the connector/security mapping, not a SQL problem.

Source

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

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

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

    public static void denyUpdateTableColumns(String tableName, Set<String> updatedColumnNames)
    {
        denyUpdateTableColumns(tableName, updatedColumnNames, null);
    }

    public static void denyUpdateTableColumns(String tableName, Set<String> updatedColumnNames, String extraInfo)
    {
        throw new AccessDeniedException(format("Cannot update columns [%s] in table %s%s", updatedColumnNames, tableName, formatExtraInfo(extraInfo)));
    }

    public static void denyCreateView(String viewName)
    {
        denyCreateView(viewName, null);
    }

    public static void denyCreateView(String viewName, String extraInfo)
    {
        throw new AccessDeniedException(format("Cannot create view %s%s", viewName, formatExtraInfo(extraInfo)));
    }

    public static void denyCreateViewWithSelect(String sourceName, Identity identity)
    {
        denyCreateViewWithSelect(sourceName, identity.toConnectorIdentity());
    }

    public static void denyCreateViewWithSelect(String sourceName, ConnectorIdentity identity)

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Grant the UPDATE privilege on those columns to the user/role in the underlying catalog's access control configuration
  2. Run the UPDATE as an identity that the access controller authorizes
  3. Check the connector's security mapping/system access control file and add the required grants
  4. If the denial is unexpected, inspect the configured AccessControl plugin logs to see which rule denied it

Example fix

// before (hive security mapping denies user)
UPDATE sales SET region='EU' WHERE id=1; -- AccessDeniedException
// after: grant privilege in access control config
GRANT UPDATE ON sales TO USER analyst; -- then re-run UPDATE
Defensive patterns

Strategy: try-catch

Validate before calling

// best effort: attempt the check via system metadata or maintain a grant cache
// Presto has no client-side precheck; ensure the identity holds UPDATE via the catalog admin
boolean hasUpdate = catalogAdmin.userHasPrivilege(user, table, "UPDATE");

Try / catch

try {
    executeUpdate(sql);
} catch (AccessDeniedException e) {
    log.error("UPDATE denied: {}", e.getMessage());
    throw new SecurityException("Grant UPDATE on the target columns to this user", e);
}

Prevention

When it happens

Trigger: Executing UPDATE ... SET col1,col2 on a table when checkCanUpdateTableColumns denies the updated column set; denyUpdateTableColumns is invoked by AccessControlManager.checkCanUpdateTableColumns during query analysis.

Common situations: Running UPDATE as a non-owner/non-admin user; file-based or Hive system access control not granting UPDATE on the schema; connector authorizer plugins (e.g. presto-grpc-api, ranger) restricting column-level updates.

Related errors

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