解决挂载问题 - Amazon Elastic File System
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

如果我们为英文版本指南提供翻译,那么如果存在任何冲突,将以英文版本指南为准。在提供翻译时使用机器翻译。

解决挂载问题

在 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 选项。这会告诉 EFS 挂载帮助程序将您的凭证传递给 EFS 挂载目标。如果您仍然没有访问权限,请检查您的文件系统策略和身份策略,以确保没有适用于您的连接的 DENY 子句,并且至少有一个适用于连接的 ALLOW 子句。

自动挂载失败,并且实例没有响应

如果在实例上自动挂载文件系统,并且未声明 _netdev 选项,则可能会出现该问题。如果缺少 _netdev,您的 EC2 实例可能会停止响应。出现该结果是因为,需要在计算实例启动其网络后初始化网络文件系统。

措施

如果出现该问题,请与 AWS Support 联系。

在 /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 服务文件。

[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

在执行该操作后,运行以下两个命令:

  1. sudo systemctl daemon-reload

  2. sudo systemctl enable mount-nfs-sequentially.service

然后,重新启动您的 Amazon EC2 实例。将按需挂载文件系统,通常在一秒内。

挂载命令失败,并显示“wrong fs type”错误消息

挂载命令失败,并显示如下错误消息。

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.<type> helper program) In some cases useful info is found in syslog - try dmesg | tail or so.

措施

如果收到该消息,请安装 nfs-utils(或 Ubuntu 上的 nfs-common)软件包。有关更多信息,请参阅 安装 NFS 客户端

挂载命令失败,并显示“incorrect mount option”错误消息

挂载命令失败,并显示如下错误消息。

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 Elastic Compute CloudAmazon EC2 的 Amazon 系统映像 (AMI) 列表,请参阅 NFS 支持

在创建文件系统后文件系统挂载立即失败

在创建域名服务 (DNS) 记录的挂载目标后,可能最多需要 90 秒的时间才能在 AWS 区域中完全传播。

措施

如果以编程方式创建和挂载文件系统(例如,使用 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 实例或挂载目标安全组的配置不正确。确保挂载目标安全组具有允许从 EC2 安全组进行 NFS 访问的入站规则。

有关更多信息,请参阅 创建安全组

请验证您所指定的挂载目标 IP 地址是否有效。如果指定的 IP 地址不正确,并且在该 IP 地址中没有任何其他内容以拒绝挂载,则可能会遇到该问题。

使用 DNS 名称的文件系统挂载失败

使用 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

要在 mount 命令中指定一个 DNS 名称,您必须执行以下操作:

  • 确保 Amazon EC2 实例所在的同一可用区中有一个 Amazon EFS 挂载目标。

  • 确保在与 Amazon EC2 实例相同的 VPC 中有一个挂载目标。否则,不能对位于其他 VPC 中的 EFS 挂载目标使用 DNS 名称解析。有关更多信息,请参阅从另一个帐户或vpc安装EFS文件系统

  • 在配置为使用由 Amazon 提供的 DNS 服务器的 Amazon VPC 内连接至您的 Amazon EC2 实例。有关更多信息,请参阅 Amazon VPC 用户指南 中的 DHCP 选项集

  • 确保连接 Amazon EC2 实例的 Amazon VPC 已启用 DNS 主机名。有关更多信息,请参阅 Amazon VPC 用户指南 中的更新 VPC 的 DNS 支持

文件系统挂载失败,返回错误“nfs not responding (nfs 未响应)”

Amazon EFS 文件系统挂载因传输控制协议 (TCP) 重新连接事件失败,返回错误"nfs: server_name still not responding"

措施

请使用 noresvport 挂载选项,以确保在重新建立网络连接时,NFS 客户端将使用新的 TCP 源端口。这样做有助于确保在网络恢复事件后具有不间断的可用性。

挂载目标生命周期状态停滞

挂载目标生命周期停滞在正在创建正在删除状态。

措施

重试 CreateMountTargetDeleteMountTarget 调用。

挂载没有响应

Amazon EFS 挂载看起来没有响应。例如,ls 等命令挂起。

措施

如果另一个应用程序正在将大量数据写入文件系统,则可能会出现该错误。在该操作完成前,可能会阻止对正在被写入的文件的访问。一般来说,尝试访问正在被写入的文件的任何命令或应用程序均可能会显示为挂起状态。例如,ls 命令可能会在访问正在被写入的文件时挂起。出现该结果是因为,某些 Linux 发行版在 ls 命令中使用别名,以便检索文件属性以及列出目录内容。

要解决此问题,请验证另一个应用程序是否正在将文件写入 Amazon EFS 挂载,并验证它是否处于 Uninterruptible sleepD 状态,如下面的示例所示:

$ 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)),这样做可能有助于提高文件系统对其他应用程序的响应能力。但是,在应用程序写入数据时,这种改善可能会牺牲性能。

针对新挂载的文件系统的操作返回“bad file handle”错误

针对新挂载的文件系统执行的操作返回 bad file handle 错误。

如果 Amazon EC2 实例连接到了一个文件系统和一个具有指定 IP 地址的挂载目标,然后该文件系统和挂载目标被删除,则可能会出现该错误。如果您创建新的文件系统和挂载目标,以连接到具有相同挂载目标 IP 地址的 Amazon EC2 实例,则可能会发生该问题。

措施

您可以卸载文件系统,然后在 Amazon EC2 实例上重新挂载文件系统以解决该问题。有关卸载您的 Amazon EFS 文件系统的更多信息,请参阅卸载文件系统

卸载文件系统失败

如果文件系统繁忙,则无法将其卸载。

措施

您可以通过以下方法解决该问题:

  • 等待所有读取和写入操作完成,然后再次尝试执行 umount 命令。

  • 使用 umount 选项强制完成 -f 命令。

    警告

    强制卸载将会中断当前为文件系统执行的任何数据读取或写入操作。