What causes "No storage namespace configured!" in phacility/phabricator?

phacility/phabricator · error · Exception

No storage namespace configured!

Error message

No storage namespace configured!

What it means

Every PhabricatorLiskDAO computes its database name from a storage namespace: a per-request stack (set for unit tests, shell tools, re-namespacing) falling back to the storage.default-namespace configuration. If the stack is empty and the configuration is null or empty, no database name can be built and the DAO refuses to continue with this Exception. It is a bootstrap/configuration failure, not a database failure.

Source

Thrown at src/infrastructure/storage/lisk/PhabricatorLiskDAO.php:46

  }

  /**
   * @task config
   */
  public static function getDefaultStorageNamespace() {
    return PhabricatorEnv::getEnvConfig('storage.default-namespace');
  }

  /**
   * @task config
   */
  public static function getStorageNamespace() {
    $namespace = end(self::$namespaceStack);
    if (!strlen($namespace)) {
      $namespace = self::getDefaultStorageNamespace();
    }
    if ($namespace === null || !strlen($namespace)) {
      throw new Exception(pht('No storage namespace configured!'));
    }
    return $namespace;
  }

  public function setForcedStorageNamespace($namespace) {
    $this->forcedNamespace = $namespace;
    return $this;
  }

  /**
   * @task config
   */
  protected function establishLiveConnection($mode) {
    $namespace = self::getStorageNamespace();
    $database = $namespace.'_'.$this->getApplicationName();

    $is_readonly = PhabricatorEnv::isReadOnly();

View on GitHub (pinned to 5720a38cfe)

Solutions

Set the namespace: phabricator/bin/config set storage.default-namespace phabricator (or your chosen prefix)
Make sure scripts use the standard bootstrap (bin/init.php / PhabricatorEnv initialization) before touching DAOs
Verify the configuration actually loads: phabricator/bin/config get storage.default-namespace should print a non-empty value in the environment you run
For tests and tooling that must target a scratch database, push a namespace with setForcedStorageNamespace()/the namespace stack instead of leaving it empty

Example fix

# before: DAOs touched before configuration exists
$ php my_script.php   # => No storage namespace configured!

# after: set the default namespace, and bootstrap like other tools
phabricator/bin/config set storage.default-namespace phabricator
# my_script.php:
#   require_once __DIR__.'/../__init_script__.php';

Defensive patterns

Strategy: validation

Validate before calling

// At bootstrap, before any DAO use, confirm configuration is live:
if (!strlen((string)PhabricatorEnv::getEnvConfig('storage.default-namespace'))) {
  throw new Exception(
    'storage.default-namespace is unset; run setup or set it via bin/config.');
}

Prevention

Always enter through the standard Phabricator bootstrap (__init_script__.php) in custom scripts
Set storage.default-namespace as the first step of provisioning a new environment
For tests/tools targeting scratch databases, use setForcedStorageNamespace() / the namespace stack rather than leaving it empty
Smoke-test new environments with bin/storage probe before enabling traffic

When it happens

Trigger: Using any DAO before PhabricatorEnv and configuration are initialized; a fresh install where storage.default-namespace was never set; scripts that include Lisk code without the standard Phabricator script bootstrap; a config file missing the key after hand-editing.

Common situations: New deployments that skipped setup; custom scripts, cron jobs, or tests invoking Lisk directly; config regenerated/restored without the storage keys; running tools with a config selection that resolves to nothing.

Related errors

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