Сбой монтирования EFS с mount.nfs4: доступ запрещен сервером

Пытаюсь смонтировать файловую систему EFS. Единственное, что я изменил, это удалить группу SG по умолчанию, созданную с группой EFS, и заменить ее пользовательской группой SG, в которой уже находятся мои инстансы EC2.

AWS предоставляет необходимую команду для подключения общего ресурса NFS, и она ДОЛЖНА работать дословно. Часто это так. Но иногда вы получаете это:

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

К сожалению, в документации по устранению неполадок под заголовком «Действие, которое необходимо предпринять» говорится:

Если вы пытаетесь смонтировать файловую систему с помощью IAM...

... и не дает абсолютно никаких рекомендаций, что делать, если вы НЕ пытаетесь смонтировать FS с помощью IAM.

Теперь, во-первых, я совершенно уверен, что не делаю ничего неправильного, потому что у меня есть playbooks, которые я использовал десятки раз для подключения общих ресурсов EFS (NFS) к инстансам EC2, они уже достаточно отполированы. Так почему же он иногда терпит неудачу?


ubuntu permissions amazon-efs mount
person StartupGuy    schedule 07.05.2020    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Что ж, как оказалось, AWS не всегда так удобен, как кажется, и иногда что-то идет не так на серверной части. В этом случае вполне возможно, что замена SG действительно могла работать в пользовательском интерфейсе, но на серверной части не подействовала. Я просто предполагаю.

Я просто удалил существующую EFS и создал точно такую ​​же EFS. На этот раз единственное, что я сделал по-другому, это установил свой пользовательский EFS SG при создании EFS, вместо того, чтобы заменить его после создания и альта, мои плейбуки снова заработали.

Я не могу придумать абсолютно никакой интуитивной (или задокументированной) причины, по которой запуск с SG не по умолчанию должен отличаться от замены его, когда это точно такой же SG. В любом случае вы настраиваете EFS для использования выбранной вами SG, и EFS не возражает. Кроме того, я делал это раньше без проблем. Так что я отношу это к ошибкам серверной части EFS/SG, из-за которых было потрачено много времени на устранение неполадок.

Таким образом, если новый общий ресурс EFS выдает ошибку mount.nfs4: access denied by server при попытке стандартного монтирования (и вы знаете, что все остальное делаете правильно), просто удалите его и просто создайте заново. Не обязательно предполагать, что вы делаете что-то не так и что сервисы AWS не могут время от времени ошибаться.

person StartupGuy    schedule 07.05.2020
comment
такое же решение для меня. Я просто воссоздал свой efs, и это сработало. вы должны отметить это как ответ - person AaronHS; 24.10.2020
comment
вот так же, спасибо - person Hermann Steidel; 12.01.2021

arrow_upward
2
arrow_downward

Я получил это сообщение об ошибке, когда каталог в EFS не существовал при попытке доступа через точку доступа.

person HeikoG    schedule 20.01.2021
comment
Из документов AWS: когда вы монтируете файловую систему с точкой доступа, создается корневой каталог для точки доступа, если каталог еще не существует. docs.aws.amazon.com/efs/latest/ ug/efs-точки доступа.html - person Sijmen; 15.03.2021
comment
Из того же документа: Amazon EFS создает корневые каталоги, только если вы указали OwnUid, OwnGID и разрешения для каталога. Если вы не предоставите эту информацию, Amazon EFS не создаст корневой каталог. Если корневой каталог не существует, попытки монтирования с использованием точки доступа завершатся неудачей. - person HeikoG; 15.03.2021