EFS装载失败，出现mount.nfs4:服务器拒绝访问

正在尝试装载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实例的剧本，现在它们已经非常完善了。那么，为什么它有时会失败呢？

事实证明，AWS并不总是像通常感觉的那样流畅，有时后端会搞砸。在这种情况下，替换SG实际上可能在UI中起作用，但在后端没有生效。我只是猜测。

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

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

总之，如果新的EFS共享在尝试标准装载时给您mount.nfs4: access denied by server错误(并且您知道其他操作都正确(，请删除它并重新创建它。不要一定认为您做错了什么，AWS服务不会时不时出错。

我遇到了类似的问题，并遵循StartupGuy的步骤。这并没有特别解决我的问题，所以我跟踪了云跟踪事件，并意识到访问策略也需要有挂载访问权限。

这是fs策略的默认操作：

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

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

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

如果您有一个文件系统策略集，并且您正在使用"sudo mount-t nfs"或"nfs4"，则会出现此错误。您可以：

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

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

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

以下是传输中加密的适当/etc/fstab条目：

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

相关内容