试图挂载一个EFS文件系统。我唯一改变的是删除了与EFS组一起创建的默认SG，并将其替换为我的EC2实例已经在的自定义SG。
AWS提供了挂载NFS共享的必要命令，它应该逐字逐句地工作。通常情况下，它确实如此。但有时你会得到这样的结果。
mount.nfs4: access denied by server while mounting fs-xxxxxxxx.efs.us-west-2.amazonaws.com:/
可悲的是，故障排除文档在 "应采取的行动 "标题下写道："如果你正在尝试挂载NFS共享
如果你想用IAM挂载文件系统... ...
......但绝对没有任何建议，说明你不是在尝试使用IAM挂载FS。
现在首先，我很确定我没有做错什么，因为我有我已经用了几十次的游戏本来挂载EFS（NFS）共享到EC2实例，现在他们已经很完善了。那为什么有时会失败呢？
好吧，事实证明，AWS并不总是像它通常的感觉那样光滑，有时事情在后端会弄巧成拙。在这种情况下，有可能替换SG实际上可能在UI中出现了工作，但在后端没有生效。我只是在猜测。
我所做的只是删除现有的EFS，然后创建一个完全相同的EFS。这次我唯一不同的是在创建EFS时设置了我的自定义EFS SG，而不是在创建后替换它，然后，我的游戏本又开始工作了。
在我看来，绝对没有任何直观的（或有文件记载的）理由，为什么用非默认SG开始和替换它有什么不同。不管是哪种情况，你都是在设置EFS使用你选择的EFS，而EFS并没有反对。此外，我以前也这样做过，没有问题。所以，我把这个问题归结为EFSSG后台出了问题，浪费了很多时间去排查。
综上所述，如果一个 新的 EFS共享给你的是 mount.nfs4: access denied by server 当尝试标准挂载时出现错误（而且你知道你做的其他事情都是正确的）--只要删除它，然后重新创建它就可以了。不要一定认为你做错了什么，AWS服务不可能时不时地搞砸。