

# Data source connectivity issues for Amazon Quick Sight
<a name="troubleshoot-connect-to-datasources"></a>

Use the following section to help you troubleshoot connections to data sources. Before you continue, verify that your database is currently available. Also, verify that you have the correct connection information and valid credentials. 

**Topics**
+ [

# I can't connect although my data source connection options look right (SSL)
](troubleshoot-connect-SSL.md)
+ [

# I can't connect to Amazon Athena
](troubleshoot-connect-athena.md)
+ [

# I can't connect to Amazon S3
](troubleshoot-connect-S3.md)
+ [

# I can't create or refresh a dataset from an existing Adobe Analytics data source
](troubleshoot-connect-adobe-analytics.md)
+ [

# I need to validate the connection to my data source, or change data source settings
](troubleshoot-connect-validate.md)
+ [

# I can't connect to MySQL (issues with SSL and authorization)
](troubleshoot-connect-mysql.md)
+ [

# I can't connect to RDS
](troubleshoot-connect-RDS.md)

# I can't connect although my data source connection options look right (SSL)
<a name="troubleshoot-connect-SSL"></a>

Problems connecting can occur when Secure Sockets Layer (SSL) is incorrectly configured. The symptoms can include the following:
+ You can connect to your database in other ways or from other locations but not in this case.
+ You can connect to a similar database but not this one.

Before continuing, rule out the following circumstances: 
+ Permissions issues
+ Availability issues
+ An expired or invalid certificate
+ A self-signed certificate
+ Certificate chain in the wrong order
+ Ports not enabled
+ Firewall blocking an IP address
+ Web Sockets are blocked
+ A virtual private cloud (VPC) or security group not configured correctly.

To help find issues with SSL, you can use an online SSL checker, or a tool like OpenSSL. 

 The following steps walk through troubleshooting a connection where SSL is suspect. The administrator in this example has already installed OpenSSL.

**Example**  

1. The user finds an issue connecting to the database. The user verifies that they can connect a different database in another AWS Region. They check other versions of the same database and can connect easily. 

1. The administrator reviews the issue and decides to verify that the certificates are working correctly. The administrator searches online for an article on using OpenSSL to troubleshoot or debug SSL connections.

1. Using OpenSSL, the administrator verifies the SSL configuration in the terminal.

   ```
   echo quit
   openssl s_client –connect <host>:port
   ```

   The result shows that the certificate is not working.

   ```
   ...
   ...
   ...
   CONNECTED(00000003)
   012345678901234:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:782:
   ---
   no peer certificate available
   ---
   No client certificate CA names sent
   ---
   SSL handshake has read 7 bytes and written 278 bytes
   ---
   New, (NONE), Cipher is (NONE)
   Secure Renegotiation IS NOT supported
   SSL-Session:
       Protocol  : TLSv1.2
       Cipher    : 0000
       Session-ID:
       Session-ID-ctx:
       Master-Key:
       Key-Arg   : None
       PSK identity: None
       PSK identity hint: None
       Start Time: 1497569068
       Timeout   : 300 (sec)
       Verify return code: 0 (ok)
   ---
   ```

1. The administrator corrects the problem by installing the SSL certificate on the user's database server. 

For more detail on the solution in this example, see [Using SSL to Encrypt a Connection to a DB Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) in the* Amazon RDS User Guide.*

# I can't connect to Amazon Athena
<a name="troubleshoot-connect-athena"></a>


|  | 
| --- |
|    Intended audience:  Amazon Quick administrators  | 

Use this section to help troubleshoot connecting to Athena. 

If you can't connect to Amazon Athena, you might get an insufficient permissions error when you run a query, showing that the permissions aren't configured. To verify that you can connect Amazon Quick Sight to Athena, check the following settings: 
+ AWS resource permissions inside of Amazon Quick Sight
+ AWS Identity and Access Management (IAM) policies
+ Amazon S3 location
+ Query results location
+ AWS KMS key policy (for encrypted datasets only)

For details, see following. For information about troubleshooting other Athena issues, see [Connectivity issues when using Amazon Athena with Amazon Quick Sight](troubleshoot-athena.md).

## Make sure that you authorized Amazon Quick Sight to use Athena
<a name="troubleshoot-connect-athena-authorizing"></a>


|  | 
| --- |
|    Intended audience:  Amazon Quick administrators  | 

Use the following procedure to make sure that you successfully authorized Amazon Quick Sight to use Athena. Permissions to AWS resources apply to all Amazon Quick Sight users.

To perform this action, you must be an Amazon Quick Sight administrator. To check if you have access, verify that you see the **Manage QuickSight** option when you open the menu from your profile at upper right.

**To authorize Amazon Quick Sight to access Athena**

1. Choose your profile name (upper right). Choose **Manage Quick Sight**, and then scroll down to the **Custom permissions** section.

1. Choose **AWS resources** then choose **Add or remove**. 

1. Find Athena in the list. Clear the box by Athena, then select it again to enable Athena. 

   Then choose **Connect both**. 

1. Choose the buckets that you want to access from Amazon Quick Sight. 

   The settings for S3 buckets that you access here are the same ones that you access by choosing Amazon S3 from the list of AWS services. Be careful that you don't inadvertently disable a bucket that someone else uses.

1. Choose **Finish** to confirm your selection. Or choose **Cancel** to exit without saving.

   

1. Choose **Update** to save your new settings for Amazon Quick Sight access to AWS services. Or choose **Cancel** to exit without making any changes.

1. Make sure that you are using the correct AWS Region when you are finished.

   If you had to change your AWS Region as part of the first step of this process, change it back to the AWS Region that you were using before. 

## Make sure that your IAM policies grant the right permissions
<a name="troubleshoot-connect-athena-perms"></a>


|  | 
| --- |
|    Intended audience:  System administrators  | 

Your AWS Identity and Access Management (IAM) policies must grant permissions to specific actions. Your IAM user or role must be able to read and write both the input and the output of the S3 buckets that Athena uses for your query.

If the dataset is encrypted, the IAM user needs to be a key user in the specified AWS KMS key's policy.

**To verify that your IAM policies have permission to use S3 buckets for your query**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Locate the IAM user or role that you are using. Choose the user or role name to see the associated policies.

1. Verify that your policy has the correct permissions. Choose a policy that you want to verify, and then choose **Edit policy**. Use the visual editor, which opens by default. If you have the JSON editor open instead, choose the **Visual editor** tab. 

1. Choose the S3 entry in the list to see its contents. The policy needs to grant permissions to list, read, and write. If S3 is not in the list, or it doesn't have the correct permissions, you can add them here. 

For examples of IAM policies that work with Quick Sight, see [IAM policy examples for Quick](iam-policy-examples.md).

## Make sure that the IAM user has read/write access to your S3 location
<a name="troubleshoot-connect-athena-read-write-access"></a>


|  | 
| --- |
|    Intended audience:  Amazon Quick administrators  | 

To access Athena data from Quick Sight, first make sure that Athena and its S3 location are authorized in **Manage QuickSight** screen. For more information, see [Make sure that you authorized Amazon Quick Sight to use Athena](#troubleshoot-connect-athena-authorizing). 

Next, verify the relevant IAM permissions. The IAM user for your Athena connection needs read/write access to the location where your results go in S3. Start by verifying that the IAM user has an attached policy that [allows access to Athena](https://docs.aws.amazon.com/athena/latest/ug/setting-up.html#attach-managed-policies-for-using-ate), such as `AmazonAthenaFullAccess`. Let Athena create the bucket using the name that it requires, and then add this bucket to the list of buckets that QuickSight can access. If you change the default location of the results bucket (`aws-athena-query-results-*`), be sure that the IAM user has permission to read and write to the new location.

Verify that you don't include the AWS Region code in the S3 URL. For example, use `s3://awsexamplebucket/path` and not `s3://us-east-1.amazonaws.com/awsexamplebucket/path`. Using the wrong S3 URL causes an `Access Denied` error. 

Also verify that the bucket policies and object access control lists (ACLs) [allow the IAM user to access the objects in the buckets](https://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html). If the IAM user is in a different AWS account, see [Cross-account Access](https://docs.aws.amazon.com/athena/latest/ug/cross-account-permissions.html) in the *Amazon Athena User Guide*.

If the dataset is encrypted, verify that the IAM user is a key user in the specified AWS KMS key's policy. You can do this in the AWS KMS console at [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).

**To set permissions to your Athena query results location**

1. Open the Athena console at [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home).

1. Verify that you have selected the workgroup you want to use:
   + Examine the **Workgroup** option at the top. It has the format **Workgroup: *group-name***. If the group name is the one that you want to use, skip to the next step.
   + To choose a different workgroup, chose **Workgroup** at the top. Choose the workgroup that you want to use, and choose **Switch workgroup**.

1. Choose **Settings** at upper right. 

   (Not common) If you get an error that your workgroup is not found, use these steps to fix it:

   1.  Ignore the error message for now, and instead find **Workgroup: *group-name*** on the **Settings** page. Your workgroup's name is a hyperlink. Open it.

   1. On the **Workgroup: *<groupname>*** page, choose **Edit workgroup** at left. Now close the error message. 

   1. Near **Query result location**, open the S3 location selector by choosing the **Select** button that has the file folder icon.

   1. Choose the small arrow at the end of the name of the S3 location for Athena. The name must begin with `aws-athena-query-results`. 

   1. (Optional) Encrypt query results by selecting the **Encrypt results stored in S3** check box.

   1. Choose **Save** to confirm your choices.

   1. If the error doesn't reappear, return to **Settings**.

      Occasionally, the error might appear again. If so, take the following steps:

      1. Choose the workgroup and then choose **View details**. 

      1. (Optional) To preserve your settings, take notes or a screenshot of the workgroup configuration. 

      1. Choose **Create workgroup**.

      1. Replace the workgroup with a new one. Configure the correct S3 location and encryption options. Note the S3 location because you need it later.

      1. Choose **Save** to proceed.

      1. When you no longer need the original workgroup, disable it. Make sure to carefully read the warning that appears, because it tells you what you lose if you choose to disable it. 

1. If you didn't get this by troubleshooting in the previous step, choose **Settings** at upper right and get the S3 location value shown as **Query result location**. 

1. If **Encrypt query results** is enabled, check whether it uses SSE-KMS or CSE-KMS. Note the key. 

1. Open the S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/), open the correct bucket, and then choose the **Permissions** tab.

1. Check that your IAM user has access by viewing **Bucket Policy**.

   If you manage access with ACLs, make sure that the access control lists (ACLs) are set up by viewing **Access Control List**.

1. If your dataset is encrypted (**Encrypt query results** is selected in the workgroup settings), make sure that the IAM user or role is added as a key user in that AWS KMS key's policy. You can access AWS KMS settings at [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).

**To grant access to the S3 bucket used by Athena**

1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

1. Choose the S3 bucket used by Athena in the **Query result location**. 

1. On the **Permissions** tab, verify the permissions.

For more information, see the AWS Support article [When I run an Athena query, I get an "Access Denied" error](https://aws.amazon.com/premiumsupport/knowledge-center/access-denied-athena/).

# I can't connect to Amazon S3
<a name="troubleshoot-connect-S3"></a>

To successfully connect to Amazon S3, make sure that you configure authentication and create a valid manifest file inside the bucket you are trying to access. Also, make sure that the file described by the manifest is available.

To verify authentication, make sure that you authorized Amazon Quick Sight to access the S3 account. It's not enough that you, the user, are authorized. Amazon Quick Sight must be authorized separately. 

**To authorize Amazon Quick Sight to access your Amazon S3 bucket**

1. In the AWS Region list at upper right, choose the US East (N. Virginia) Region. You use this AWS Region temporarily while you edit your account permissions. 

1. Inside Amazon Quick Sight, choose your profile name (upper right). Choose **Manage Quick Sight**, and then scroll down to the **Custom permissions** section. 

1. Choose **AWS resources** then choose **Add or remove**. 

1. Locate Amazon S3 in the list. Choose one of the following actions to open the screen where you can choose S3 buckets:
   + If the check box is clear, select the check box next to Amazon S3. 
   + If the check box is selected, choose **Details**, and then choose **Select S3 buckets**. 

1. Choose the buckets that you want to access from Amazon Quick Sight. Then choose **Select**.

1. Choose **Update**.

1. If you changed your AWS Region during the first step of this process, change it back to the AWS Region that you want to use.

We strongly recommend that you make sure that your manifest file is valid. If Amazon Quick Sight can't parse your file, it gives you an error message. That might be something like "We can't parse the manifest file as valid JSON" or "We can't connect to the S3 bucket."

**To verify your manifest file**

1. Open your manifest file. You can do this directly from the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). Go to your manifest file and choose **Open**.

1. Make sure that the URI or URLs provided inside the manifest file indicate the file or files that you want connect to.

1. Make sure that your manifest file is formed correctly, if you use a link to the manifest file rather than uploading the file. The link shouldn't have any additional phrases after the word `.json`. You can get the correct link to an S3 file by viewing its **Link** value in the details on the S3 console.

1. Make sure that the content of the manifest file is valid by using a JSON validator, like the one at [https://jsonlint.com](https://jsonlint.com). 

1. Verify permissions on your bucket or file. In the [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/), navigate to your Amazon S3 bucket, choose the **Permissions** tab, and add the appropriate permissions. Make sure that the permissions are at the right level, either on the bucket or on the file or files. 

1. If you are using the `s3://` protocol, rather than `https://`, make sure that you reference your bucket directly. For example, use *s3://awsexamplebucket/myfile.csv* instead of *s3://s3-us-west-2.amazonaws.com/awsexamplebucket/myfile.csv*. Doubly specifying Amazon S3, by using `s3://` and also `s3-us-west-2.amazonaws.com`, causes an error.

   For more information about manifest files and connecting to Amazon S3, see [Supported formats for Amazon S3 manifest files](supported-manifest-file-format.md).

In addition, verify that your Amazon S3 dataset was created according to the steps in [Creating a dataset using Amazon S3 files](create-a-data-set-s3.md).

If you use Athena to connect to Amazon S3, see [I can't connect to Amazon Athena](troubleshoot-connect-athena.md).

# I can't create or refresh a dataset from an existing Adobe Analytics data source
<a name="troubleshoot-connect-adobe-analytics"></a>

As of May 1, 2022, Quick Sight no longer supports legacy OAuth and version 1.3 and SOAP API operations in Adobe Analytics. If you experience failures while trying to create or refresh a dataset from an existing Adobe Analytics data source, you might have a stale access token.

**To troubleshoot failures while creating or refreshing a dataset from an existing Adobe Analytics data source**

1. Open Quick Sight and choose **Data** at left.

1. Choose **New** then **Dataset**.

1. On the **Create a dataset** page, choose the Adobe Analytics data source that you want to update from the list of existing data sources.

1. Choose **Edit data source**.

1. On the **Edit Adobe Analytics data source** page that opens, choose **Update data source** to reauthorize the Adobe Analytics connection.

1. Try recreating or refreshing the dataset again. The dataset creation or refresh should succeed.

# I need to validate the connection to my data source, or change data source settings
<a name="troubleshoot-connect-validate"></a>

In some cases, you might need to update your data source, or you got a connection error and need to check your settings. If so, take the following steps.

**To validate your connection to the data source**

1. From the Quick Sight homepage, choose **Data** at left.

1. Choose **New** then **Dataset**.

1. You will see a list of existing data sources.

1. Choose the data source that you want to test or change.

1. If the option is offered, choose **Edit/Preview data**.

1. Choose **Validate connection**.

1. Make any changes that you want to make, then choose **Update data source**.

# I can't connect to MySQL (issues with SSL and authorization)
<a name="troubleshoot-connect-mysql"></a>

To check on some common connection issues in MySQL, use the following steps. This procedure helps you find out if you have enabled SSL and granted usage rights.

**To find solutions for some common connection issues in MySQL**

1. Check `/etc/my.cnf` to make sure SSL is enabled for MySQL.

1. In MySQL, run the following command.

   ```
   show status like 'Ssl%';
   ```

   If SSL is working, you see results like the following.

   ```
   +--------------------------------+----------------------+
   | Variable_name                  | Value                |
   +--------------------------------+----------------------+
   | Ssl_accept_renegotiates        | 0                    |
   | Ssl_accepts                    | 1                    |
   | Ssl_callback_cache_hits        | 0                    |
   | Ssl_cipher                     |                      |
   | Ssl_cipher_list                |                      |
   | Ssl_client_connects            | 0                    |
   | Ssl_connect_renegotiates       | 0                    |
   | Ssl_ctx_verify_depth           | 18446744073709551615 |
   | Ssl_ctx_verify_mode            | 5                    |
   | Ssl_default_timeout            | 0                    |
   | Ssl_finished_accepts           | 0                    |
   | Ssl_finished_connects          | 0                    |
   | Ssl_session_cache_hits         | 0                    |
   | Ssl_session_cache_misses       | 0                    |
   | Ssl_session_cache_mode         | SERVER               |
   | Ssl_session_cache_overflows    | 0                    |
   | Ssl_session_cache_size         | 128                  |
   | Ssl_session_cache_timeouts     | 0                    |
   | Ssl_sessions_reused            | 0                    |
   | Ssl_used_session_cache_entries | 0                    |
   | Ssl_verify_depth               | 0                    |
   | Ssl_verify_mode                | 0                    |
   | Ssl_version                    |                      |
   +--------------------------------+----------------------+
   ```

   If SSL is disabled, you see results like the following.

   ```
   +--------------------------------+-------+
   | Variable_name                  | Value |
   +--------------------------------+-------+
   | Ssl_accept_renegotiates        | 0     |
   | Ssl_accepts                    | 0     |
   | Ssl_callback_cache_hits        | 0     |
   | Ssl_cipher                     |       |
   | Ssl_cipher_list                |       |
   | Ssl_client_connects            | 0     |
   | Ssl_connect_renegotiates       | 0     |
   | Ssl_ctx_verify_depth           | 0     |
   | Ssl_ctx_verify_mode            | 0     |
   | Ssl_default_timeout            | 0     |
   | Ssl_finished_accepts           | 0     |
   | Ssl_finished_connects          | 0     |
   | Ssl_session_cache_hits         | 0     |
   | Ssl_session_cache_misses       | 0     |
   | Ssl_session_cache_mode         | NONE  |
   | Ssl_session_cache_overflows    | 0     |
   | Ssl_session_cache_size         | 0     |
   | Ssl_session_cache_timeouts     | 0     |
   | Ssl_sessions_reused            | 0     |
   | Ssl_used_session_cache_entries | 0     |
   | Ssl_verify_depth               | 0     |
   | Ssl_verify_mode                | 0     |
   | Ssl_version                    |       |
   +--------------------------------+-------+
   ```

1. Make sure that you have installed a supported SSL certificate on the database server. 

1. Grant usage for the specific user to connect using SSL.

   ```
   GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL;                        
   ```

**Note**  
TLS 1.2 for MySQL connections requires MySQL version 5.7.28 or higher. If your MySQL server enforces TLS 1.2 only (for example, `tls_version = TLSv1.2`) and the server version is below 5.7.28, the SSL handshake fails with a `Communications link failure` error. To resolve this, upgrade your MySQL or Aurora MySQL database to version 5.7.28 or higher.

For more detail on the solution in this example, see the following:
+ [SSL Support for MySQL DB Instances](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.SSLSupport.html) in the *Amazon RDS User Guide*.
+ [Using SSL to Encrypt a Connection to a DB Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) in the *Amazon RDS User Guide*.
+ [MySQL documentation](https://dev.mysql.com/doc/refman/5.6/en/using-encrypted-connections.html)

# I can't connect to RDS
<a name="troubleshoot-connect-RDS"></a>

For details on troubleshooting connections to Amazon RDS, see [Creating a dataset from a database](create-a-database-data-set.md). 

You can also refer to the Amazon RDS documentation on troubleshooting connections, [Cannot Connect to Amazon RDS DB Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Connecting)*.*