> ## Documentation Index
> Fetch the complete documentation index at: https://openmetadata-docs-release-watchers.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Athena Troubleshooting Guide | OpenMetadata Support

> Resolve OpenMetadata Athena connector issues fast with our comprehensive troubleshooting guide. Fix common database connection problems and errors quickly.

## Troubleshooting

## Workflow Deployment Error

If there were any errors during the workflow deployment process, the
Ingestion Pipeline Entity will still be created, but no workflow will be
present in the Ingestion container.

* You can then Edit the Ingestion Pipeline and **Deploy** it again.
* From the Connection tab, you can also Edit the Service if needed.

## Connector Debug Troubleshooting

This section provides instructions to help resolve common issues encountered during connector setup and metadata ingestion in OpenMetadata. Below are some of the most frequently observed troubleshooting scenarios.

## How to Enable Debug Logging for Any Ingestion

To enable debug logging for any ingestion workflow in OpenMetadata:

1. **Navigate to Services**
   Go to **Settings > Services > Service Type** (e.g., Database) in the OpenMetadata UI.

2. **Select a Service**
   Choose the specific service for which you want to enable debug logging.

3. **Access Agents Tab**
   Go to the **Agents tab** and click the three-dot menu on the right-hand side of the ingestion type, and select Edit.

4. **Enable Debug Logging**
   In the configuration dialog, enable the **Debug Log** option and click **Next**.

5. **Schedule and Submit**
   Configure the schedule if needed and click **Submit** to apply the changes.

## Permission Issues

If you encounter permission-related errors during connector setup or metadata ingestion, ensure that all the prerequisites and access configurations specified for each connector are properly implemented. Refer to the connector-specific documentation to verify the required permissions.

## Test Connection Passes but No Tables Are Ingested

If ingestion completes but imports **0 tables**, check the **GetTables** step on Test Connection. It still shows as passed, but can carry one of two different caveats depending on what's actually missing.

### No Schemas Visible

If no databases were listable in the catalog at all, the caveat reads:

```
No databases were listable in <catalog>. Check the login's Glue/Athena list permissions and Lake Formation DESCRIBE grants, or confirm the catalog and schemaFilterPattern are not excluding everything.
```

This can happen for a few different reasons:

* The IAM role is missing the AWS Glue/Athena permissions needed to list databases.
* The IAM role is missing the AWS Lake Formation **Describe** grant on those databases.
* The connector's catalog or `schemaFilterPattern` setting is excluding every database.

#### Resolution

1. Confirm the IAM role has the Glue/Athena permissions needed to list databases (for example, `glue:GetDatabases`).
2. In the AWS Lake Formation console, open **Data permissions** and confirm the role has **Describe** on the databases you expect to see.
3. Check the catalog name and the connector's `schemaFilterPattern` to make sure they aren't unintentionally excluding every database.
4. Re-run **Test Connection** and check the **GetTables** caveat again.

### No Readable Tables

If databases were visible but no tables inside them were readable, the caveat reads:

```
No tables were readable in any targeted schema. AWS Lake Formation returns an empty list (not an error) when grants are missing, so ingestion would collect 0 tables. Grant Lake Formation DESCRIBE/SELECT on the databases and tables the login should read. If the catalog is genuinely empty or view-only, this is expected.
```

This means the IAM role the connector uses is missing AWS Lake Formation **Describe** and **Select** grants on the target databases or tables. AWS Lake Formation silently filters out results it can't authorize instead of raising an error, so a catalog with missing grants looks identical to a genuinely empty one. Test Connection can't tell the two apart, so it passes with this caveat instead of failing outright, which would incorrectly reject a legitimately empty or view-only catalog.

#### Resolution

1. In the AWS Lake Formation console, open **Data permissions**.
2. Grant the IAM role used by the Athena connector **Describe** and **Select** permissions on each database and table it needs to ingest.
3. Re-run **Test Connection** and check the **GetTables** caveat again. If the catalog genuinely has no tables yet, this caveat is expected and can be ignored.