> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/troubleshooting/signing-in/auth-manager.md).

# Backend exception error when running authentication manager

Diagnosing the gremlin backend exception the authentication manager reports, from a stopped Cassandra node through to rebuilding the entitlements graph.

Effective access is computed from a graph held in JanusGraph, which stores it in Cassandra. The authentication manager reads that graph over the gremlin API, so a fault in either store surfaces here as a backend exception rather than as a database error.

## Symptom

The authentication manager log carries one of these:

{% code overflow="wrap" %}

```
Can't get entitlements graph for User: ID_of_User java.util.concurrent.CompletionException: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Could not execute operation due to backend exception
```

{% endcode %}

{% code overflow="wrap" %}

```
Cannot run application - shutting down java.util.concurrent.CompletionException: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Could not execute operation due to backend exception
```

{% endcode %}

{% code overflow="wrap" %}

```
tinkerpop.gremlin.driver.exception.ResponseException: The traversal source [g] for alias [g] is not configured on the server.
```

{% endcode %}

| Symptom                                                                | Likely cause                                              | Resolution                                                          |
| ---------------------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------- |
| Any of the errors above, and `nodetool status` shows a node down       | JanusGraph has no storage behind it                       | [Check the Cassandra nodes first](#check-the-cassandra-nodes-first) |
| Any of the errors above, every node up, and a vertex count that errors | Cassandra is running but its copy of the graph is damaged | [Clear and repopulate the graph](#clear-and-repopulate-the-graph)   |

{% hint style="info" %}
**The three services have to come up in order: Cassandra → JanusGraph → authentication manager.** Cassandra is JanusGraph's database and the authentication manager is a client of JanusGraph's API, so each one needs the one before it. Stop them in the reverse order.
{% endhint %}

## Check the Cassandra nodes first

{% stepper %}
{% step %}
**Read the cluster status.**

```bash
nodetool -h ::FFFF:127.0.0.1 status
```

{% endstep %}

{% step %}
**Start any node that is down.**

```bash
systemctl start cassandra
```

Then restart JanusGraph and the authentication manager, and read the status again.
{% endstep %}

{% step %}
**If Cassandra will not start**, read its own log in `/var/log/cassandra/` and its unit status:

```bash
systemctl status cassandra
```

Go no further until the cluster is healthy — everything below assumes it is. Once it is, restarting JanusGraph may be enough on its own, and `openiam-auth` recovers without the rest of this page.
{% endstep %}
{% endstepper %}

## If every node is healthy, check the graph itself

Go into `/usr/local/openiam/janusgraph/bin` and open a gremlin console:

```bash
gremlin.sh
```

Then connect to the server and count the vertices:

```
:remote connect tinkerpop.server conf/remote.yaml
:> g.V().count()
```

A count that comes back is a graph that can be read. **If it errors**, Cassandra's copy of the graph is damaged and has to be cleared and repopulated.

## Clear and repopulate the graph

{% hint style="danger" %}
**This destroys the stored graph and empties the cache, and it is not a routine step.** It is the recovery for a graph that cannot be traversed at all — confirm the count above actually errors before starting, and take the Cassandra data directory's backup if you have one. The graph is derived data and is rebuilt from the membership rows, which this does not touch.
{% endhint %}

{% stepper %}
{% step %}
**Stop OpenIAM and all JanusGraph nodes.** The whole services stack has to be down, not just the authentication manager — the cache is cleared further down and a running service will repopulate it from the damaged graph.
{% endstep %}

{% step %}
**Run cleanup on every Cassandra node.**

{% code overflow="wrap" %}

```bash
nodetool -u <CASSANDRA_USER> -pw <CASSANDRA_PASSWORD> cleanup janusgraph
```

{% endcode %}
{% endstep %}

{% step %}
**Confirm the keyspace's data directory is empty.** Check `/var/lib/cassandra/data/janusgraph/`. If anything is left, stop Cassandra on all nodes, remove the directory by hand, then start Cassandra and JanusGraph again.
{% endstep %}

{% step %}
**Clear the Redis cache**, with the OpenIAM services still stopped. Connect to the master sentinel node:

```bash
redis-cli -h <REDIS_HOST>
```

Then authenticate and flush:

```
AUTH <REDIS_PASSWORD>
FLUSHDB
FLUSHALL
```

{% hint style="warning" %}
**`FLUSHALL` empties every database on that instance, not only OpenIAM's.** On a Redis shared with anything else, flush only the database OpenIAM uses.
{% endhint %}
{% endstep %}

{% step %}
**Start OpenIAM**, and read the authentication manager log as it comes up.
{% endstep %}

{% step %}
**Force the graph to rebuild**, once `openiam-esb` and the authentication manager are both started:

{% code overflow="wrap" %}

```bash
curl http://localhost:9080/openiam-esb/authmanager/rebuildGraph
```

{% endcode %}

The request returns as soon as it is accepted — it queues the rebuild rather than waiting for it — so watch the authentication manager log for the outcome and try a login once it settles. See [Rebuild the authorization graph](/administration-guide/operations/rebuild-the-authorization-graph.md) for the log lines that mark a finished and a failed rebuild.
{% endstep %}
{% endstepper %}

## If none of this helps

Raise a support ticket, with the authentication manager log, the `nodetool status` output and the vertex count you got from the gremlin console. [Getting help and escalating](/troubleshooting/getting-help.md) says where to open it and what else to attach.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openiam.com/troubleshooting/signing-in/auth-manager.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.