I'm trying to Terraform a few EC2 instances, and would like to automate the provisioning steps that involve mounting their filesystems to EFS. The commands to run this manually are as follows:

$  sudo mkdir /var/www/html/efs-mount-point
$  sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport ${module.efs_mount.file_system_dns_name}:/ /var/www/html/efs-mount-point

As you can see from my string interpolation, I have already attempted to set things up in a Terraform provisioner "remote-exec" block when the EC2 instances get created.

This works for the most part, as the directory gets created - but I'm running into errors with the actual mounting step. I believe that Terraform may be trying to mount before everything has established proper network connections. I'll include the full error below.

Is this the right approach? I can't help but feel like I could set up the EC2 AMI to be already mounted or have some startup mount script instead of relying on Terraform provisioners (as they are noted as a last-resort approach in the docs)

Networking Error for context:

│ Error: remote-exec provisioner error
│   with aws_instance.example-instance-with-efs[0],
│   on main.tf line 72, in resource "aws_instance" "example-instance-with-efs":
│   72:   provisioner "remote-exec" {
│ error executing "/tmp/terraform_1760279708.sh": Process exited with status 32
  • I think this is worth checking out => Link Nov 3, 2021 at 16:06
  • 1
    I’m voting to close this question because duplicate of stackoverflow.com/questions/69488032/… Nov 4, 2021 at 7:45
  • @BruceBecker - I've added an answer, which I feel adds value as it highlights a solution to the "approach" part of the original question. The SO duplicate you mention seems to only address the permissions problem that user was facing. Happy to move wherever, but I do feel the answer I provided may be valuable to keep around? Nov 4, 2021 at 14:34
  • Thanks @AndrewGentry! this is useful. Nov 4, 2021 at 16:40

1 Answer 1


A better approach I came to discover was using the user_data of a launch configuration. While it still suffers some of the same issues that provisioners introduce, there's a lot less room for error in terms of permissions and timing as seen in other questions.

For Example:

resource "aws_launch_configuration" "sample" {
  image_id          = "ami-04afe279c8bff9ed8"
  instance_type = "t2.micro"
  security_groups = [

  user_data = <<-EOF
              mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport ${module.efs_mount.file_system_dns_name}:/ /your/mount/point/
  lifecycle {
    create_before_destroy = true

I should note, that this also implies my additional use of an Auto Scaling Group - which may or may not fit into everyone's requirements.

Not the answer you're looking for? Browse other questions tagged or ask your own question.