<!-- Hi there, Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html. If your issue relates to Terraform Cloud/Enterprise, please contact tf-cloud@hashicorp.support. If your issue relates to a specific Terraform provider, please open it in the provider's own repository. The index of providers is at https://github.com/terraform-providers. To fix problems, we need clear reproduction cases - we need to be able to see it happen locally. A reproduction case is ideally something a Terraform Core engineer can git-clone or copy-paste and run immediately, without inventing any details or context. * A short example can be directly copy-pasteable; longer examples should be in separate git repositories, especially if multiple files are needed * Please include all needed context. For example, if you figured out that an expression can cause a crash, put the expression in a variable definition or a resource * Set defaults on (or omit) any variables. The person reproducing it should not need to invent variable settings * If multiple steps are required, such as running terraform twice, consider scripting it in a simple shell script. For example, see [this case](https://github.com/danieldreier/terraform-issue-reproductions/tree/master/25719). Providing a script can be easier than explaining what changes to make to the config between runs. * Omit any unneeded complexity: remove variables, conditional statements, functions, modules, providers, and resources that are not needed to trigger the bug * When possible, use the [null resource](https://www.terraform.io/docs/providers/null/resource.html) provider rather than a real provider in order to minimize external dependencies. We know this isn't always feasible. The Terraform Core team doesn't have deep domain knowledge in every provider, or access to every cloud platform for reproduction cases. --> ### Terraform Version <!--- Run `terraform version` to show the version, and paste the result between the ``` marks below. If you are not running the latest version of Terraform, please try upgrading because your issue may have already been fixed. --> Was able to reproduce it on a variety of versions starting from 0.13.5 and up to the latest. ### Terraform Configuration Files <!-- Paste the relevant parts of your Terraform configuration between the ``` marks below. For Terraform configs larger than a few resources, or that involve multiple files, please make a GitHub repository that we can clone, rather than copy-pasting multiple files in here. For security, you can also encrypt the files using our GPG public key at https://www.hashicorp.com/security. --> ```terraform # main.tf resource "null_resource" "cluster" {} resource "random_string" "random" { length = 5 } ``` ### Expected Behavior <!-- What should have happened? --> ``` 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. ``` ### Actual Behavior <!-- What actually happened? --> ``` Error: Failed to install provider from shared cache Error while importing hashicorp/null v3.1.0 from the shared cache directory: after linking registry.terraform.io/hashicorp/null from provider cache at /Users/kryvenkd/repos/tmp/tf-plugin-cache it is still not detected in the target directory; this is a bug in Terraform. ``` ### Steps to Reproduce <!-- Please list the full steps required to reproduce the issue, for example: 1. `terraform init` 2. `terraform apply` --> 1. `export TF_PLUGIN_CACHE_DIR=~/repos/tmp/tf-plugin-cache` 2. `tf init` 3. `rm -rf ${TF_PLUGIN_CACHE_DIR}/registry.terraform.io/hashicorp/random` 4. `tf init` This is tricky one to reproduce - there must be at least two providers at play, and also deleting `null` provider doesn't reproduce this - but other providers does. ### Additional Context <!-- Are there anything atypical about your situation that we should know? For example: is Terraform running in a wrapper script or in a CI system? Are you passing any unusual command line options or environment variables to opt-in to non-default behavior? --> The goal here is basically to do as explained here https://learn.hashicorp.com/tutorials/terraform/automate-terraform#plan-and-apply-on-different-machines. In my CI I archive everything from the workspace during the plan and then restore for apply. The trick is `TF_PLUGIN_CACHE_DIR` volume might be different than have used during the plan, and it might not have providers that were previously installed during the plan. That resulting in `.terraform/providers` having broken symlinks. I think TF should not freak out if the symlink leads to nowhere but simply fallback to re-downloading the provider.