EFS 挂载失败，mount.nfs4：访问被服务器拒绝

Question

尝试挂载 EFS 文件系统。我唯一更改的是删除使用 EFS 组创建的默认 SG，并将其替换为我的 EC2 实例已经在其中的自定义 SG。

AWS 为挂载 NFS 共享提供了必要的命令，它应该逐字运行。很多时候确实如此。但有时你会得到这个：

mount.nfs4: access denied by server while mounting fs-xxxxxxxx.efs.us-west-2.amazonaws.com:/

可悲的是，故障排除文档在“要采取的行动”标题下说：

如果您尝试使用 IAM 挂载文件系统...

...并且绝对零建议您不要尝试使用 IAM 安装 FS。

首先，我很确定我没有做错什么，因为我已经使用了几十次的剧本将 EFS (NFS) 共享挂载到 EC2 实例，现在它们已经非常完善了。那么为什么有时会失败呢？

Answer 1

我遇到了类似的问题并按照 StartupGuy 的步骤进行操作。这并没有特别解决我的问题，因此我跟踪了云跟踪事件，并意识到访问策略也需要具有安装访问权限。

这是fs-policy 的默认操作：

             ...
             "Action": [
                "elasticfilesystem:ClientRootAccess",
                "elasticfilesystem:ClientWrite"
            ]
            ...

您还需要添加到 fs 策略中。 "elasticfilesystem:ClientMount"

Answer 2

当尝试通过接入点访问时，EFS 上的目录不存在，我收到此错误消息。

Answer 3

事实证明，AWS 并不总是像通常感觉的那样圆滑，有时后端会出现问题。在这种情况下，有可能替换 SG 实际上在 UI 中似乎可以工作，但在后端没有生效。我只是猜测。

我所做的只是删除现有的 EFS 并创建完全相同的 EFS。这次我做的唯一不同的是在创建 EFS 时设置我的自定义 EFS SG，而不是在创建和中提琴后替换它，我的剧本又开始工作了。

绝对没有我能想到的直观（或记录）原因，为什么从非默认 SG 开始应该与替换它有任何不同，因为它是完全相同的 SG。无论哪种情况，您都将 EFS 设置为使用您选择的 SG，并且 EFS 不反对。此外，我以前这样做过，没有任何问题。因此，我将此归结为 EFS/SG 后端错误，浪费了大量时间进行故障排除。

总而言之，如果新的EFS 共享mount.nfs4: access denied by server在尝试标准挂载时给您错误（并且您知道其他所有操作都正确） - 只需将其删除并重新创建即可。不必假设您做错了什么并且 AWS 服务不会时不时地搞砸。