

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 对 Lake Formation 问题进行故障排除
<a name="troubleshooting"></a>

如果您在使用 Amazon Lake Formation 时遇到问题，请查阅本节中的主题。

**Topics**
+ [一般故障排除](#trouble-general)
+ [对跨账户访问问题进行故障排除](#trouble-cross-account)
+ [对蓝图和工作流问题进行故障排除](#trouble-workflows)
+ [的已知问题 Amazon Lake Formation](limitations.md)
+ [更新了错误消息](error-message-update.md)

## 一般故障排除
<a name="trouble-general"></a>

使用此处的信息可帮助您诊断和修复各种 Lake Formation 问题。

### 错误：对 <Amazon S3 位置> 的 Lake Formation 权限不足
<a name="trouble-location"></a>

试图创建或更改数据目录资源，但不具有对该资源指向的 Amazon S3 位置的数据位置权限。

如果数据目录数据库或表指向 Amazon S3 位置，则在授予 Lake Formation 权限 `CREATE_TABLE` 或 `ALTER` 时，您还必须授予对该位置的 `DATA_LOCATION_ACCESS` 权限。如果要向外部账户或组织授予这些权限，您必须包含授予选项。

向外部账户授予这些权限后，该账户中的数据湖管理员必须向该账户中的主体（用户或角色）授予这些权限。在授予从其他账户获得的`DATA_LOCATION_ACCESS`权限时，必须指定所有者Amazon 账户的目录 ID（账户 ID）。拥有者账户是注册了该位置的账户。

有关更多信息，请参阅[基础数据访问控制](access-control-underlying-data.md)和[授予数据位置权限](granting-location-permissions.md)。

### 错误：“Glue API 的加密密钥权限不足”
<a name="trouble-encryption-grant"></a>

有人试图向Lake Formation授予对加密数据目录的 Amazon KMS 加密密钥的权限，但没有 Amazon Identity and Access Management (IAM) 权限。

### 我 Amazon Athena 或使用清单的 Amazon Redshift 查询失败了
<a name="trouble-manifest-query"></a>

Lake Formation 不支持使用清单的查询。

### 错误：“Lake Formation 权限不足：需要在目录上创建标签”
<a name="permission-create-tag"></a>

 user/role 必须是数据湖管理员。

### 删除无效的数据湖管理员时出错
<a name="delete-admins"></a>

您应同时删除所有无效的数据湖管理员（已删除定义为数据湖管理员的 IAM 角色）。如果尝试单独删除无效的数据湖管理员，Lake Formation 会引发无效主体错误。

## 对跨账户访问问题进行故障排除
<a name="trouble-cross-account"></a>

使用此处的信息可帮助您诊断和修复跨账户访问问题。

**Topics**
+ [我授予了跨账户 Lake Formation 权限，但接收者看不到资源。](#troubleshooting-problem1)
+ [接收者账户中的主体可以看到数据目录资源，但无法访问基础数据](#troubleshooting-problem11)
+ [接受 Amazon RAM 资源共享邀请时出现错误：“由于调用方未获得授权，关联失败”](#troubleshooting-cross-acct-accepting)
+ [错误：“无权授予对资源的权限”](#troubleshooting-problem2)
+ [错误：“检索 Amazon 组织信息的访问权限被拒绝”](#troubleshooting-problem3)
+ [错误：“未找到组织 <organization-ID>”](#troubleshooting-problem4)
+ [错误：“Lake Formation 权限不足：非法组合”](#troubleshooting-problem5)
+ [ConcurrentModificationException 在 grant/revoke 向外部账户发出的请求时](#troubleshooting-problem6)
+ [使用 Amazon EMR 访问通过跨账户共享的数据时出错](#toubleshooting-problem7)

### 我授予了跨账户 Lake Formation 权限，但接收者看不到资源。
<a name="troubleshooting-problem1"></a>
+ 接收者账户中的用户是否为数据湖管理员？ 只有数据湖管理员才能在共享时看到资源。
+ 您是否在使用命名资源方法与组织外部的账户共享？ 如果是，则收件人账户的数据湖管理员必须接受 Amazon Resource Access Manager (Amazon RAM) 中的资源共享邀请。

  有关更多信息，请参阅 [接受来自的资源共享邀请 Amazon RAM](accepting-ram-invite.md)。
+ 您是否在 Amazon Glue 中使用账户级（数据目录）资源策略？ 如果是，则如果您使用命名资源方法，则必须在策略中包含一条特殊语句，以授权 Amazon RAM 代表您共享策略。

  有关更多信息，请参阅 [使用 Amazon Glue 和 Lake Formation 管理跨账户权限。](hybrid-cross-account.md)。
+ 您是否拥有授予跨账户访问权限所需的 Amazon Identity and Access Management (IAM) 权限？

  有关更多信息，请参阅 [先决条件](cross-account-prereqs.md)。
+ 您已对其授予权限的资源不得具有向 `IAMAllowedPrincipals` 组授予的任何 Lake Formation 权限。
+ 账户级策略中是否有关于资源的 `deny` 语句？ 

### 接收者账户中的主体可以看到数据目录资源，但无法访问基础数据
<a name="troubleshooting-problem11"></a>

收款人账户中的委托人必须具有必需的 Amazon Identity and Access Management (IAM) 权限。有关更多信息，请参阅 [访问共享表的基础数据](cross-account-read-data.md)。

### 接受 Amazon RAM 资源共享邀请时出现错误：“由于调用方未获得授权，关联失败”
<a name="troubleshooting-cross-acct-accepting"></a>

在向其他账户授予对资源的访问权限后，当接收账户尝试接受资源共享邀请时，操作将失败。

```
$ aws ram get-resource-share-associations --association-type PRINCIPAL --resource-share-arns arn:aws:ram:aws-region:444444444444:resource-share/e1d1f4ba-xxxx-xxxx-xxxx-xxxxxxxx5d8d
{
    "resourceShareAssociations": [
        {
            "resourceShareArn": "arn:aws:ram:aws-region:444444444444:resource-share/e1d1f4ba-xxxx-xxxx-xxxx-xxxxxxxx5d8d
",
            "resourceShareName": "LakeFormation-MMCC0XQBH3Y",
            "associatedEntity": "5815803XXXXX",
            "associationType": "PRINCIPAL",
            "status": "FAILED",
            "statusMessage": "Association failed because the caller was not authorized.",
            "creationTime": "2021-07-12T02:20:10.267000+00:00",
            "lastUpdatedTime": "2021-07-12T02:20:51.830000+00:00",
            "external": true
        }
    ]
}
```

发生此错误的原因是，当接收账户接受资源共享邀请时，Amazon Glue 会调用 `glue:PutResourcePolicy`。要解决此问题，请允许 producer/grantor 账户使用的代入角色执行`glue:PutResourcePolicy`操作。

### 错误：“无权授予对资源的权限”
<a name="troubleshooting-problem2"></a>

试图授予对另一个账户拥有的数据库或表的跨账户权限。当与您的账户共享数据库或表时，作为数据湖管理员，您只能向账户中的用户授予对数据库或表的权限。

### 错误：“检索 Amazon 组织信息的访问权限被拒绝”
<a name="troubleshooting-problem3"></a>

您的账户是 Or Amazon ganizations 管理账户，并且您没有检索组织信息（例如账户中的组织单位）所需的权限。

有关更多信息，请参阅 [Required permissions for cross-account grants](cross-account-prereqs.md#cross-account-permissions-needed)。

### 错误：“未找到组织 <organization-ID>”
<a name="troubleshooting-problem4"></a>

尝试与组织共享资源，但未启用与 Organizations 的共享。启用与 Organizations 的资源共享。

有关更多信息，请参阅《*Amazon RAM 用户指南》*中的 [“启用与 Org Amazon anizations 共享](https://docs.amazonaws.cn/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)”。

### 错误：“Lake Formation 权限不足：非法组合”
<a name="troubleshooting-problem5"></a>

用户共享了数据目录资源，同时向 `IAMAllowedPrincipals` 组授予了该资源的 Lake Formation 权限。在共享资源之前，用户必须撤销 `IAMAllowedPrincipals` 的所有 Lake Formation 权限。

### ConcurrentModificationException 在 grant/revoke 向外部账户发出的请求时
<a name="troubleshooting-problem6"></a>

当用户根据 LF-Tag 策略向委托人提出多个并发授予 and/or 撤销权限请求时，Lake Formation 就会抛出。 ConcurrentModificationException用户需要捕获异常，然后重试失败的 grant/revoke 请求。使用`GrantPermissions`/`RevokePermissions`API操作的批处理版本，[BatchGrantPermissions](https://docs.amazonaws.cn/lake-formation/latest/APIReference/API_BatchGrantPermissions.html)并通过减少并发 grant/revoke 请求的数量在一定程度上[BatchRevokePermissions](https://docs.amazonaws.cn/lake-formation/latest/APIReference/API_BatchRevokePermissions.html)缓解此问题。

### 使用 Amazon EMR 访问通过跨账户共享的数据时出错
<a name="toubleshooting-problem7"></a>

使用 Amazon EMR 从其他账户访问与您共享的数据时，某些 Spark 库会尝试调用 `Glue:GetUserDefinedFunctions` API 操作。由于 Amazon RAM 托管权限的版本 1 和版本 2 不支持此操作，因此您会收到以下错误消息：

`"ERROR: User: arn:aws:sts::012345678901:assumed-role/my-spark-role/i-06ab8c2b59299508a is not authorized to perform: glue:GetUserDefinedFunctions on resource: arn:exampleCatalogResource because no resource-based policy allows the glue:GetUserDefinedFunctions action"`

要解决此错误，创建资源共享的数据湖管理员必须更新附加到资源共享的 Amazon RAM 托管权限。托管权限的版本 3 Amazon RAM 允许主体执行 `glue:GetUserDefinedFunctions` 操作。

如果您创建新的资源共享，Lake Formation 会默认应用最新版本的 Amazon RAM 托管权限，您无需执行任何操作。要为现有资源共享启用跨账户数据访问权限，您需要将 Amazon RAM 托管权限更新为版本 3。

您可以在中查看分配给与您共享的资源的 Amazon RAM 权限 Amazon RAM。版本 3 中包含以下权限：

```
Databases
  AWSRAMPermissionGlueDatabaseReadWriteForCatalog 
  AWSRAMPermissionGlueDatabaseReadWrite
    
Tables
  AWSRAMPermissionGlueTableReadWriteForCatalog
  AWSRAMPermissionGlueTableReadWriteForDatabase
    
AllTables
  AWSRAMPermissionGlueAllTablesReadWriteForCatalog
  AWSRAMPermissionGlueAllTablesReadWriteForDatabase
```

**更新现有资源共享的 Amazon RAM 托管权限版本**  
您（数据湖管理员）可以按照*Amazon RAM 用户指南*中的说明将[Amazon RAM 托管权限更新到新版本](https://docs.amazonaws.cn/ram/latest/userguide/working-with-sharing-update-permissions.html)，也可以撤消资源类型的所有现有权限并重新授予这些权限。如果您撤消权限，则 Amazon RAM 会删除与该 Amazon RAM 资源类型关联的资源共享。重新授予权限时， Amazon RAM 会创建新的资源共享，并附上最新版本的 Amazon RAM 托管权限。

## 对蓝图和工作流问题进行故障排除
<a name="trouble-workflows"></a>

使用此处的信息可帮助您诊断和修复蓝图和工作流问题。

**Topics**
+ [我的蓝图失败，显示 “用户：<user-ARN>无权执行：iam：PassRole 在资源上：<role-ARN>”](#problem-bp-1)
+ [我的工作流程失败，出现 “用户：<user-ARN>无权执行：iam：PassRole 在资源上：<role-ARN>”](#problem-bp-2)
+ [我的工作流中的爬网程序失败，并显示“资源不存在或请求者无权访问请求的权限”](#problem-bp-3)
+ [我的工作流程中的爬虫失败，显示 “调用 CreateTable 操作时出现错误 (AccessDeniedException)...”](#problem-bp-4)

### 我的蓝图失败，显示 “用户：<user-ARN>无权执行：iam：PassRole 在资源上：<role-ARN>”
<a name="problem-bp-1"></a>

用户尝试创建蓝图，但该用户没有足够的权限来传递所选角色。

更新用户的 IAM 策略以便能够传递角色，或者要求用户选择具有所需 passrole 权限的其他角色。

有关更多信息，请参阅 [Lake Formation 角色和 IAM 权限参考](permissions-reference.md)。

### 我的工作流程失败，出现 “用户：<user-ARN>无权执行：iam：PassRole 在资源上：<role-ARN>”
<a name="problem-bp-2"></a>

您为工作流指定的角色没有允许角色自行传递的内联策略。

有关更多信息，请参阅[（可选）为工作流创建 IAM 角色](initial-lf-config.md#iam-create-blueprint-role)。

### 我的工作流中的爬网程序失败，并显示“资源不存在或请求者无权访问请求的权限”
<a name="problem-bp-3"></a>

一个可能的原因是传递的角色没有足够的权限在目标数据库中创建表。向该角色授予对数据库 `CREATE_TABLE` 权限。

### 我的工作流程中的爬虫失败，显示 “调用 CreateTable 操作时出现错误 (AccessDeniedException)...”
<a name="problem-bp-4"></a>

一个可能的原因是工作流角色对目标存储位置没有数据位置权限。向该角色授予数据位置权限。

有关更多信息，请参阅 [`DATA_LOCATION_ACCESS`](lf-permissions-reference.md#perm-location)。