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，而不是在创建和中提琴之后替换它，我的剧本又开始工作了。

没有任何直觉(或文档)的理由，我可以想到，为什么从非默认SG应该有任何不同的取代它，当它完全相同的SG。在这两种情况下，您都要设置EFS来使用所选的SG，而EFS并不反对。而且，我以前做过这件事，没有任何问题。所以我认为这是EFS/SG后端的错误，浪费了很多时间来解决问题。

总之，如果一个新的EFS共享在尝试一个标准挂载时给了您mount.nfs4: access denied by server错误(而且您知道您正在正确地执行其他所有操作)--只需删除它并重新创建它。不要想当然地认为你做错了什么，AWS服务也不会时不时地出错。

Answer 2

我面临着一个类似的问题，并跟随StartupGuy的脚步。这并没有特别解决我的问题，所以我跟踪了云跟踪事件，并意识到访问策略也需要挂载访问权限。

这是fs-策略的默认操作：

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

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

Answer 3

当试图通过访问点访问EFS上的目录时，我收到了此错误消息。