🚨 OpenStack Error Guide: 'Could not find project' — Fix Keystone Scope & Project Lookup Failures

Overview

Could not find project is the Keystone error returned when a request tries to authenticate or scope a token to a project that Keystone cannot resolve — because the project ID/name doesn’t exist, was deleted, lives in a different domain than assumed, or the credential names it incorrectly. Since almost every OpenStack API call carries a project-scoped token, this failure blocks the client entirely with a 404/401 before any service logic runs.

The literal errors you will see:

Could not find project: 9f8e7d6c5b4a39281706... (HTTP 404)

keystoneauth1.exceptions.http.NotFound: Could not find project: myproject
The request you have made requires authentication. (HTTP 401)

It occurs at authentication/scoping time: running openstack commands, a service using a service account, or Horizon switching projects. The tell is that the token itself may be valid, but the project it should scope to can’t be found — a naming/domain/lifecycle problem, not a password problem.

Symptoms

• openstack commands fail with Could not find project (404) or a scoping 401.
• One user/tenant is affected while others authenticate fine.
• A service account starts failing after a project cleanup or rename.

openstack token issue -c project_id -f value

Could not find project: 9f8e7d6c5b4a39281706... (HTTP 404)

docker logs keystone 2>&1 | grep -iE "Could not find project|ProjectNotFound" | tail -3

WARNING keystone.common.wsgi Could not find project: 9f8e7d6c... 

Common Root Causes

1. Project was deleted

The project referenced by OS_PROJECT_ID/OS_PROJECT_NAME no longer exists.

openstack project list --domain <domain> -c ID -c Name | grep -i <project>
env | grep -E 'OS_PROJECT'

# no matching row -> project does not exist
OS_PROJECT_ID=9f8e7d6c5b4a39281706...

If the ID in the environment has no matching project, it was deleted or never existed.

2. Wrong domain scope

Project names are unique only within a domain; scoping by name without the correct OS_PROJECT_DOMAIN_NAME resolves to nothing.

env | grep -E 'OS_PROJECT_DOMAIN|OS_USER_DOMAIN'
openstack project list --domain Default -c Name
openstack project list --domain <other-domain> -c Name

OS_PROJECT_DOMAIN_NAME=Default   # but the project lives in 'customers'

The same project name in a different domain won’t be found under Default.

3. Stale OS_PROJECT_ID in the rc file / clouds.yaml

A recreated project gets a new ID; an old sourced rc file or clouds.yaml still carries the previous ID.

grep -E 'project_id|project_name|project_domain' ~/.config/openstack/clouds.yaml 2>/dev/null
openstack project show <project-name> -c id -f value

project_id: 9f8e7d6c...   # old
# actual current id: 1a2b3c4d...

4. User has no role on the project

If the user lost their role assignment, scoping to the project fails (sometimes surfacing as not-found on strict setups).

openstack role assignment list --user <user> --project <project> --names

# empty -> no role on that project

5. Service account points at a renamed/moved project

A service’s keystone_authtoken or app credential references a project that was renamed or moved between domains.

docker exec nova_api grep -E 'project_name|project_domain_name|username' \
  /etc/nova/nova.conf
openstack project show <that-name> 2>&1 | tail -1

project_name = service
No project with a name or ID of 'service' exists.

6. Federation/auto-provisioning didn’t create the project

In federated setups, a mapping expected to auto-create a project may not have, leaving nothing to scope to.

docker logs keystone 2>&1 | grep -iE "mapping|autoprovision|Could not find project" | tail -5

Diagnostic Workflow

Step 1: Read what the client is asking for

env | grep -E 'OS_PROJECT|OS_.*DOMAIN'
grep -E 'project_id|project_name|.*domain' ~/.config/openstack/clouds.yaml 2>/dev/null

Step 2: Confirm the project exists and in which domain

openstack project list --all --long -c ID -c Name -c "Domain ID" 2>/dev/null | grep -i <project>
openstack project show <project> 2>&1 | tail -3

Step 3: Match ID vs name vs domain

Compare the ID/name/domain the client sends against what project show returns — a mismatch on any of the three causes the not-found.

Step 4: Verify the user’s role on the project

openstack role assignment list --user <user> --project <project> --names

Step 5: For services, check the auth section

docker exec <service>_api grep -E 'project_name|project_domain_name|auth_url' \
  /etc/<service>/<service>.conf

Example Root Cause Analysis

A CI service account that provisions test instances suddenly fails every call:

Could not find project: qa-sandbox (HTTP 404)

The account authenticates fine (the password is accepted) but can’t scope to qa-sandbox. Listing projects across domains:

openstack project list --all --long -c Name -c "Domain ID" | grep -i qa-sandbox

| qa-sandbox | 7c1f...  (domain: qa)      |

The project exists — but in the qa domain, while the service credential scopes it under Default:

docker exec ci_runner grep -E 'project_name|project_domain_name' /etc/ci/clouds.yaml

project_name: qa-sandbox
project_domain_name: Default

The project was migrated into a dedicated qa domain during a cleanup, but the CI credential still assumes Default. Fixing the domain in the credential resolves it:

# set project_domain_name: qa in the CI clouds.yaml, then:
openstack --os-cloud ci token issue -c project_id -f value   # now succeeds

Longer term, reference projects by ID (immutable) in service credentials, and coordinate domain migrations with the teams whose accounts scope into them.

Prevention Best Practices

• Prefer project IDs over names in service credentials and automation; IDs are immutable, while names collide across domains and change on recreation.
• Always set OS_PROJECT_DOMAIN_NAME/project_domain_name explicitly — name-only scoping is ambiguous and the top cause of this error.
• Coordinate project deletions, renames, and domain migrations with the owners of any service accounts or rc files that reference them.
• After recreating a project, update every sourced rc file and clouds.yaml with the new ID — a stale ID looks like a deleted project.
• Audit role assignments when access breaks; a lost role on a project can surface as a scoping failure.
• In federated setups, verify auto-provisioning actually created the mapped project before assuming it exists.
• Paste the failing command’s env/clouds.yaml and the Keystone log into the free incident assistant to pinpoint the ID/name/domain mismatch, and see more OpenStack guides.

Quick Command Reference

# What is the client asking for?
env | grep -E 'OS_PROJECT|OS_.*DOMAIN'
grep -E 'project_id|project_name|.*domain' ~/.config/openstack/clouds.yaml 2>/dev/null

# Does the project exist, and in which domain?
openstack project list --all --long -c ID -c Name -c "Domain ID" | grep -i <project>
openstack project show <project>

# User role on the project
openstack role assignment list --user <user> --project <project> --names

# Service auth section
docker exec <service>_api grep -E 'project_name|project_domain_name|auth_url' /etc/<service>/<service>.conf

# Keystone log
docker logs keystone 2>&1 | grep -iE "Could not find project|ProjectNotFound" | tail -5

Conclusion

Could not find project means Keystone can’t resolve the project a token should scope to — the credential is otherwise valid. Typical root causes:

1. The project was deleted.
2. Wrong domain scope (name is only unique within a domain).
3. A stale OS_PROJECT_ID in an rc file or clouds.yaml after recreation.
4. The user lost their role on the project.
5. A service account referencing a renamed or moved project.
6. Federation auto-provisioning that didn’t create the project.

Compare the ID, name, and domain the client sends against openstack project show first — a mismatch on any of the three is the cause, and using immutable project IDs in automation prevents most recurrences.