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

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

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

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

总而言之，如果一个新的 EFS 共享为您提供mount.nfs4: access denied by server error 在尝试标准安装时（并且您知道您正在正确地执行其他所有操作） - 只需删除它并重新创建它。 不一定要假设您做错了什么，并且 AWS 服务不会时不时地搞砸。

Answer 2

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

Answer 3

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

这是 fs-policy 的默认操作：

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

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

Answer 4

对我来说，问题是我有一个策略要求驱动器在传输过程中加密，而实例创建向导创建了一个错误的 /etc/fstab 条目。

1. 该策略要求使用 tls 安装驱动器。 此处给出了相关说明： https://docs.aws.amazon.com/efs/latest/ug/mounting-fs-mount-helper-ec2-linux.html ，如果您使用挂载助手，并指定 -o tls。
2. 实例创建向导创建的 /etc/fstab 没有执行正确的挂载。 事实上，同一页面上的“使用 NFS 客户端”选项等同于创建的错误条目。

这是传输中加密的正确 /etc/fstab 条目的样子：

fs-0123456789abcdef0:/ /mnt/fs-1 efs tls,_netdev 0 0

Answer 5

如果您设置了文件系统策略并且正在使用“sudo mount -t nfs”或“nfs4”，那么您会收到此错误。 您可以：

• A.) 从文件系统中删除文件系统策略
• B.) 使用以下命令挂载：sudo mount -t efs -o tls,iam...

资料来源： https://docs.aws.amazon.com/efs/latest/ug/mounting-IAM-option.html