v0.10.2
When I use terraform plan, getting below error:
Error asking for user input: 1 error(s) occurred:
- provider.azurerm: fork/exec /var/www/terraform/.terraform/plugins/linux_amd64/terraform-provider-azurerm_v0.1.5_x4: permission denied
terraform init is working fine:
Initializing provider plugins...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.azurerm: version = "~> 0.1"
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
Hi @rnkhouse! Sorry for this weird behavior.
This error message suggests that the plugin executable doesn't have the "executable" permission set.
Is there anything unusual about that /var/www/terraform directory with regard to permissions? For example, is it in a partition that's mounted with the noexec option, or on a filesystem that doesn't support permissions, or other reasons that might cause Terraform to be unable to set the "executable" mode on that file?
Alternatively, is terraform running with a restrictive umask that may prevent it from creating a file with execute permissions?
Hi @apparentlymart Thanks for the prompt response. So, far I can just see this error. Previously it wasn't like this though.
May be its because of vagrant configurations but not sure. I have below config in Vagrantfile.
config.vm.synced_folder "./sync_data", "/var/www/", type: "virtualbox", :owner => "www-data", :group => "www-data", :mount_options => ['dmode=0755', 'fmode=0644']
Hi @rnkhouse! Sorry for the delay in following up.
If I understand correctly, it looks like you're running Terraform in a Vagrant-controlled VirtualBox VM, and it's accessing the Terraform configuration over the VirtualBox "Shared Folders" mechanism. Is that right?
I remember that Shared Folders has a number of interesting limitations but I'm not sure of the details. It might be that executable permissions are not allowed on shared folders, or perhaps your host system (Windows?) doesn't support them.
You mentioned that this was working before. At that point, were you running a version of Terraform older than 0.10? In 0.10 we started installing plugins into .terraform/plugins as part of terraform init, whereas before they were included in the main terraform program.
To avoid Terraform trying to run plugins installed in the VirtualBox Shared Folder, the easiest path may be to install the plugins separately prior to running terraform init. If you have a Vagrant provisioning step that's installing Terraform, it could perhaps also download the azurerm provider and extract the zip file into the same directory where the terraform binary is installed. If Terraform finds an existing plugin there, it will skip trying to download and install the plugin itself.
Hi,
I'm facing the same issue using the AWS provider but with a different configuration with vagrant + NFS share.
To install the plugin manually is it possible to have a link to the latest version of a provider (ie. a link to the latest version without number in the URL) ?
As another workaround, is there a way to move .terraform to another location?
I fix the issue by deleting .terraform, reinitialise the terraform by terraform -init, It worked for me.
FWIW. I just had the same issue and found that relaxing the mount permission in the Vagrant file
did the trick I changed :mount_options => ['dmode=0755', 'fmode=0644'] to :mount_options => ['dmode=0755', 'fmode=0774']
Hello! :robot:
This issue relates to an older version of Terraform that is no longer in active development, and because the area of Terraform it relates to has changed significantly since the issue was opened we suspect that the issue is either fixed or that the circumstances around it have changed enough that we'd need an updated issue report in order to reproduce and address it.
If you're still seeing this or a similar issue in the latest version of Terraform, please do feel free to open a new bug report! Please be sure to include all of the information requested in the template, even if it might seem redundant with the information already shared in _this_ issue, because the internal details relating to this problem are likely to be different in the current version of Terraform.
Thanks!
@gete76 Thank you thank you and thank you!!!!
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
I fix the issue by deleting .terraform, reinitialise the terraform by terraform -init, It worked for me.