phacility/phabricator · error · AphrontAccessDeniedQueryException

1044, 1142, 1143, 1227

1044, 1142, 1143, 1227

Error message

#%d: %s

This error usually indicates that you need to "GRANT" the MySQL user additional permissions. See "GRANT" in the MySQL manual for help.

What it means

The connected MySQL user is missing a privilege the statement needs: 1044 (database-level), 1142 (table-level), 1143 (column-level), or 1227 (statement-level, e.g. SUPER for SHOW SLAVE STATUS). The library maps all four to AphrontAccessDeniedQueryException and appends explicit 'run GRANT' guidance (task T13622) because the raw MySQL 'access denied' text routinely gets misdiagnosed as an auth failure. The connection itself is fine; only authorization for this statement failed.

Source

Thrown at src/infrastructure/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:360

        // NOTE: In some versions of MySQL we get a key name back here, but
        // older versions just give us a key index ("key 2") so it's not
        // portable to parse the key out of the error and attach it to the
        // exception.
        throw new AphrontDuplicateKeyQueryException($message);
      case 1044: // Access denied to database
      case 1142: // Access denied to table
      case 1143: // Access denied to column
      case 1227: // Access denied (e.g., no SUPER for SHOW SLAVE STATUS).

        // See T13622. Try to help users figure out that this is a GRANT
        // problem.

        $more = pht(
          'This error usually indicates that you need to "GRANT" the '.
          'MySQL user additional permissions. See "GRANT" in the MySQL '.
          'manual for help.');

        throw new AphrontAccessDeniedQueryException("{$message}\n\n{$more}");
      case 1045: // Access denied (auth)
        throw new AphrontInvalidCredentialsQueryException($message);
      case 1146: // No such table
      case 1049: // No such database
      case 1054: // Unknown column "..." in field list
        throw new AphrontSchemaQueryException($message);
    }

    // TODO: 1064 is syntax error, and quite terrible in production.

    return null;
  }

  protected function throwConnectionException($errno, $error, $user, $host) {
    $this->throwCommonException($errno, $error);

    $message = pht(
      'Attempt to connect to %s@%s failed with error #%d: %s.',

View on GitHub (pinned to 5720a38cfe)

Solutions

Identify the failing statement, then grant the missing privilege: GRANT ALL PRIVILEGES ON `phabricator\_%`.* TO 'user'@'host'; or the specific one (e.g. REPLICATION CLIENT, SUPER) and FLUSH PRIVILEGES if you edited grant tables directly
Compare reality vs expectation with SHOW GRANTS FOR CURRENT_USER(); from a Phabricator shell (bin/storage shell or a probe script)
Align the credentials in your Phabricator database configuration with an account that has the required grants
If you cannot widen grants, disable or reconfigure the feature issuing the privileged query

Example fix

-- before: user only has grants on one database
GRANT SELECT, INSERT ON phabricator_worker.* TO 'phab'@'%';
-- ...but code runs: SHOW SLAVE STATUS  => error 1227

-- after: grant what the application actually needs
GRANT ALL PRIVILEGES ON `phabricator\_%`.* TO 'phab'@'%';
GRANT REPLICATION CLIENT ON *.* TO 'phab'@'%';
FLUSH PRIVILEGES;

Defensive patterns

Strategy: validation

Validate before calling

// Preflight at deploy time: assert the grants the application needs.
$grants = queryfx_all($conn, 'SHOW GRANTS FOR CURRENT_USER()');
// Require coverage of `phabricator\_%`.*, plus REPLICATION CLIENT (or SUPER)
// on *.* if replication/cluster status queries run in this deployment.

Try / catch

try {
  queryfx($conn_w, '%s', $sql);
} catch (AphrontAccessDeniedQueryException $ex) {
  // The appended message names the GRANT fix; log it verbatim and alert ops —
  // this is a deployment mismatch, not something to retry.

Prevention

Provision the MySQL account with grants over the whole application namespace (phabricator_%.*) before first deploy
When adding replication/cluster features, check the feature's documented privilege needs and grant them up front
Run SHOW GRANTS FOR CURRENT_USER() from a Phabricator shell after any account change
Include a privileges probe (bin/storage probe) in deployment smoke tests

When it happens

Trigger: Querying a table or column outside the user's grants; running replication/cluster code that executes SHOW SLAVE STATUS / SHOW MASTER STATUS without SUPER or REPLICATION CLIENT; running bin/storage upgrade when the user cannot ALTER tables; accessing a database not covered by the grant pattern.

Common situations: Shared or managed MySQL where the DBA granted only specific databases/tables; a production account provisioned with just SELECT/INSERT; a new Phabricator feature touching INFORMATION_SCHEMA or replication status for the first time; grant pattern like user@'10.0.%' not matching the client host.

Related errors

AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/70c8db21ebef1322. Report an issue: GitHub.