本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 解决挂载问题 您可以在下文中找到有关排查 EFS 文件系统挂载问题的信息。 ## 在 Windows 实例上挂载文件系统失败 在 Microsoft Windows 上的 Amazon EC2 实例上挂载文件系统失败。 **要采取的操作** 请勿将 Amazon EFS 与 Windows EC2 实例一起使用，不支持该配置。 ## 服务器拒绝访问 文件系统挂载失败，并显示以下消息： ``` /efs mount.nfs4: access denied by server while mounting 127.0.0.1:/ ``` 如果您的 NFS 客户端没有挂载文件系统的权限，则可能会出现此问题。 **要采取的操作** 如果您尝试使用 IAM 挂载文件系统，请确保您在挂载命令中使用了 `-o iam` 或 -o tls 选项。这会告诉 EFS 挂载帮助程序将您的凭证传递给 EFS 挂载目标。如果您仍然没有访问权限，请检查您的文件系统策略和身份策略，以确保没有适用于您的连接的 DENY 子句，并且至少有一个适用于连接的 ALLOW 子句。有关更多信息，请参阅[使用 IAM 控制文件系统访问](iam-access-control-nfs-efs.md)和[创建文件系统策略](create-file-system-policy.md)。 ## 自动挂载失败，并且实例没有响应 如果在实例上自动挂载文件系统，并且未声明 `_netdev` 选项，则可能会出现该问题。如果缺少 `_netdev`，您的 EC2 实例可能会停止响应。出现该结果是因为，需要在计算实例启动其网络后初始化网络文件系统。 **要采取的操作** 如果出现此问题，请联系 Supp AWS ort。 ## 在 /etc/fstab 中挂载多个 Amazon EFS 文件系统失败 如果实例使用的 systemd 初始化系统在 `/etc/fstab` 中具有两个或更多 Amazon EFS 条目，有时可能会没有挂载其中的部分或全部条目。在这种情况下，`dmesg` 输出显示类似于以下内容的一行或多行。 ``` NFS: nfs4_discover_server_trunking unhandled error -512. Exiting with error EIO ``` **要采取的操作** 在这种情况下，我们建议您在 `/etc/systemd/system/mount-nfs-sequentially.service` 中创建新的 systemd 服务文件。文件中包含的代码取决于您是手动挂载文件系统，还是使用 Amazon EFS 挂载帮助程序进行挂载。 + 如果要手动装载文件系统，则该`ExecStart`命令必须指向网络文件系统 (NFS4)。在此文件中包含以下代码： ``` [Unit] Description=Workaround for mounting NFS file systems sequentially at boot time After=remote-fs.target [Service] Type=oneshot ExecStart=/bin/mount -avt nfs4 RemainAfterExit=yes [Install] WantedBy=multi-user.target ``` + 如果您使用的是 Amazon EFS 挂载帮助程序，则该`ExecStart`命令必须指向 EFS，而不是使用传输层安全 (TLS)。 NFS4 在此文件中包含以下代码： ``` [Unit] Description=Workaround for mounting NFS file systems sequentially at boot time After=remote-fs.target [Service] Type=oneshot ExecStart=/bin/mount -avt efs RemainAfterExit=yes [Install] WantedBy=multi-user.target ``` 创建此文件后，运行以下两个命令： 1. `sudo systemctl daemon-reload` 1. `sudo systemctl enable mount-nfs-sequentially.service` 然后，重新启动您的 Amazon EC2 实例。将按需挂载文件系统，通常在一秒内。 ## 挂载命令失败，并显示“错误的 fs 类型”错误消息 挂载命令失败，并显示如下错误消息。 ``` mount: wrong fs type, bad option, bad superblock on 10.1.25.30:/, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount. helper program) In some cases useful info is found in syslog - try dmesg | tail or so. ``` **要采取的操作** 如果收到该消息，请安装 `nfs-utils`（或 Ubuntu 上的 `nfs-common`）软件包。有关更多信息，请参阅 [安装 NFS 客户端](mounting-fs-install-nfsclient.md)。 ## 挂载命令失败，并显示“不正确的挂载选项”错误消息 挂载命令失败，并显示如下错误消息。 ``` mount.nfs: an incorrect mount option was specified ``` **要采取的操作** 此错误消息很可能意味着你的 Linux 发行版不支持网络文件系统版本 4.0 和 4.1 (NFSv4)。要确认是否属于这种情况，您可以运行以下命令。 ``` $ grep CONFIG_NFS_V4_1 /boot/config* ``` 如果上述命令返回 `# CONFIG_NFS_V4_1 is not set`，则表明您的 Linux 发行版不支持 NFSv4.1。有关 NFSv4支持 .1 的亚马逊弹性计算云 (Amazon EC2) 的亚马逊系统映像 (AMI) 列表，请参阅。[NFS 支持](mounting-fs-old.md#mounting-fs-nfs-info) ## 使用接入点挂载失败 使用接入点进行挂载时，挂载命令失败，并显示以下错误消息： ``` mount.nfs4: mounting access_point failed, reason given by server: No such file or directory ``` **要采取的操作** 此错误消息表示指定的 EFS 路径不存在。确保您提供接入点根目录的所有权和权限。EFS 将使用此信息创建根目录。有关更多信息，请参阅 [使用接入点工作](efs-access-points.md)。 如果未指定任何根目录所有权和权限，并且根目录尚不存在，EFS 将不会创建根目录。发生这种情况时，使用接入点挂载文件系统的任何尝试都将失败。 ## 在创建文件系统后文件系统挂载立即失败 在创建域名服务（DNS）记录的挂载目标后，可能需要长达 90 秒的时间才能在整个 AWS 区域中传播。 **要采取的操作** 如果您以编程方式创建和挂载文件系统（例如使用 CloudFormation 模板），我们建议您实现等待条件。 ## 文件系统挂载挂起，然后失败，并显示超时错误 文件系统挂载命令挂起一两分钟，然后失败，并显示超时错误。下面的代码显示了一个示例。 ``` $ sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport mount-target-ip:/ mnt [2+ minute wait here] mount.nfs: Connection timed out $  ``` **要采取的操作** 出现该错误的原因可能是，Amazon EC2 实例或挂载目标安全组的配置不正确。确保挂载目标安全组具有支持使用端口 2049 从 EC2 安全组进行 NFS 访问的入站规则。有关更多信息，请参阅 [使用 VPC 安全组](network-access.md)。 请验证您所指定的挂载目标 IP 地址是否有效。如果指定的 IP 地址不正确，并且在该 IP 地址中没有任何其他内容以拒绝挂载，则可能会遇到该问题。 ## 使用 NFS 通过 DNS 名称挂载文件系统失败 尝试使用 NFS 客户端（不使用 `amazon-efs-utils` 客户端）通过文件系统的 DNS 名称挂载文件系统失败，如以下示例所示： ``` $ sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport file-system-id.efs.aws-region.amazonaws.com:/ mnt mount.nfs: Failed to resolve server file-system-id.efs.aws-region.amazonaws.com: Name or service not known. $  ``` **要采取的操作** 请检查您的 VPC 配置。如果使用自定义 VPC，请确保已启用 DNS 设置。有关更多信息，请参阅《Amazon VPC 用户指南》**中的 [VPC 的 DNS 属性](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)。此外，文件系统和挂载目标 DNS 名称还无法从它们存在的 VPC 外部进行解析。 您必须先执行以下操作，然后才能在 `mount` 命令中使用文件系统的 DNS 名称来挂载文件系统： + 确保 Amazon EC2 实例所在的同一可用区中有一个 Amazon EFS 挂载目标。 + 确保在与 Amazon EC2 实例相同的 VPC 中有一个挂载目标。否则，不能对位于其他 VPC 中的 EFS 挂载目标使用 DNS 名称解析。有关更多信息，请参阅 [从其他 AWS 账户 或 VPC 挂载 EFS 文件系统](manage-fs-access-vpc-peering.md)。 + 在配置为使用由 Amazon 提供的 DNS 服务器的 Amazon VPC 内连接至您的 Amazon EC2 实例。有关更多信息，请参阅《Amazon VPC 用户指南》**中的 [Amazon VPC 中的 DHCP 选项集](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)。 + 确保连接 Amazon EC2 实例的 Amazon VPC 已启用 DNS 主机名。有关更多信息，请参阅《Amazon VPC 用户指南》**中的 [VPC 中的 DNS 属性](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support)。 ## 文件系统挂载失败，并显示错误“nfs 未响应” Amazon EFS 文件系统挂载因传输控制协议（TCP）重新连接事件失败，并返回错误 `"nfs: server_name still not responding"`。 **要采取的操作** 请使用 `noresvport` 挂载选项，以确保在重新建立网络连接时，NFS 客户端将使用新的 TCP 源端口。这样做有助于确保在网络恢复事件后具有不间断的可用性。 ## 挂载目标生命周期状态停滞 挂载目标生命周期停滞在**正在创建**或**正在删除**状态。 **要采取的操作** 重试 `CreateMountTarget` 或 `DeleteMountTarget` 调用。 ## 挂载目标生命周期状态显示错误 挂载目标生命周期状态显示为**错误**。 **要采取的操作** 如果虚拟私有云（VPC）的托管区相互冲突，Amazon EFS 无法为新的文件系统挂载目标创建必要的域名系统（DNS）记录。Amazon EFS 无法在客户拥有的托管区内创建新记录。如果您需要维护具有冲突的 `efs..amazonaws.com` DNS 范围的托管区，请在单独的 VPC 中创建托管区。有关 VPC 的 DNS 注意事项的更多信息，请参阅[您的 VPC 的 DNS 属性](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)。 要解决此问题，请从 VPC 中删除冲突的 `efs..amazonaws.com` 主机，然后重新创建挂载目标。有关删除挂载目标的更多信息，请参阅[管理挂载目标](accessing-fs.md)。 ## 挂载没有响应 Amazon EFS 挂载看起来没有响应。例如，`ls` 等命令挂起。 **要采取的操作** 如果另一个应用程序正在将大量数据写入文件系统，则可能会出现该错误。在该操作完成前，可能会阻止对正在被写入的文件的访问。一般来说，尝试访问正在被写入的文件的任何命令或应用程序均可能会显示为挂起状态。例如，`ls` 命令可能会在访问正在被写入的文件时挂起。出现该结果是因为，某些 Linux 发行版在 `ls` 命令中使用别名，以便检索文件属性以及列出目录内容。 要解决该问题，请验证另一个应用程序是否正在将文件写入 Amazon EFS 挂载，并验证它是否处于 `Uninterruptible sleep`（`D`）状态，如下面的示例所示： ``` $ ps aux | grep large_io.py root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python large_io.py /efs/large_file ``` 在已验证确属这种情况之后，您可以通过等待其他写入操作完成或通过实施一种变通解决办法来解决问题。在 `ls` 示例中，您可以直接使用 `/bin/ls` 命令，而不是使用别名。这样做可以继续执行命令，而不会在写入的文件处挂起。通常，如果写入数据的应用程序可能会定期强制执行数据刷新（可能使用 `fsync(2)`），这样做可能有助于提高文件系统对其他应用程序的响应能力。但是，在应用程序写入数据时，这种改善可能会牺牲性能。 ## 挂载的客户端断开连接 挂载到 Amazon EFS 文件系统的客户端偶尔会由于多种原因而断开连接。NFS 客户端旨在在出现中断时自动重新连接，从而最大限度地减少例行断开连接对应用程序性能和可用性的影响。在大多数情况下，客户端会在几秒钟内以透明的方式重新连接。 但是，旧版 Linux 内核（版本 v5.4 及更低版本）中包含的 NFS 客户端软件包含一种行为，该行为会导致 NFS 客户端在断开连接时尝试在同一 TCP 源端口上重新连接。此行为不符合 TCP RFC 要求，并且可能会阻止这些客户端快速重新建立与其 EFS 服务器（在本例中为 EFS 文件系统）的连接。 要解决此问题，我们强烈建议您使用 Amazon EFS 挂载帮助程序来挂载 EFS 文件系统。EFS 挂载帮助程序使用针对 Amazon EFS 文件系统优化了的挂载设置。有关 EFS 客户端和挂载帮助程序的更多信息，请参阅[安装 Amazon EFS 客户端](using-amazon-efs-utils.md)。 如果您无法使用 EFS 挂载帮助程序，我们强烈建议您使用 `noresvport` NFS 挂载选项，该选项会指示 NFS 客户端使用新的 TCP 源端口重新建立连接，以避免出现此问题。有关更多信息，请参阅 [推荐的 NFS 挂载设置](mounting-fs-nfs-mount-settings.md)。 ## 对新挂载的文件系统的操作返回“坏文件句柄”错误 针对新挂载的文件系统执行的操作返回 `bad file handle` 错误。 如果 Amazon EC2 实例连接到了一个文件系统和一个具有指定 IP 地址的挂载目标，然后该文件系统和挂载目标被删除，则可能会出现该错误。如果您创建新的文件系统和挂载目标，以连接到具有相同挂载目标 IP 地址的 Amazon EC2 实例，则可能会发生该问题。 **要采取的操作** 您可以卸载文件系统，然后在 Amazon EC2 实例上重新挂载文件系统以解决该问题。有关卸载您的 Amazon EFS 文件系统的更多信息，请参阅[卸载文件系统](unmounting-fs.md)。 ## 卸载文件系统失败 如果文件系统繁忙，则无法将其卸载。 **要采取的操作** 您可以通过以下方法解决该问题： + 使用延迟卸载 **umount -l**，它会在运行时将文件系统从文件系统层次结构中分离出来，然后在文件系统不再忙碌时立即清理对文件系统的所有引用。 + 等待所有读取和写入操作完成，然后再次尝试执行 **umount** 命令。 + 使用 **umount -f** 命令强制卸载。 **警告** 强制卸载将会中断当前为文件系统执行的任何数据读取或写入操作。有关使用此选项的更多信息和指导，请参阅[卸载手册页](https://man7.org/linux/man-pages/man8/umount.8.html)。