Error: Failed to query available provider packages

Not specified by the original author.

TL;DR: tofu init is naming a provider that doesn't exist in the registry. Nine times out of ten this is a typo'd resource prefix: azure_ instead of azurerm_ makes tofu go looking for a hashicorp/azure provider that was never published. Fix the prefix (or the source in required_providers), then re-init.

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider
hashicorp/azure: provider registry.opentofu.org/hashicorp/azure was not
found

Steps

1. Read the provider name in the error. Ask: did you declare that provider? If not, find what implied it: grep -rn 'resource "azure_' . (swap in the prefix from your error). Expected: one or more resources with the wrong type prefix.

2. Fix the prefix, e.g. resource "azure_resource_group" becomes resource "azurerm_resource_group". Expected: the grep from step 1 finds nothing anymore.

3. If the provider IS declared, check required_providers for a typo'd source address. Expected: the source matches a real registry address, like hashicorp/azurerm.

4. Run tofu init. Expected: Initializing provider plugins... followed by - Installing hashicorp/azurerm v[...]....

When this applies

• tofu init fails naming a provider you never asked for, or a provider with a slightly-off name.
• Right after renaming resources or copying config between projects.

When it doesn't apply

• Error: Inconsistent dependency lock file is a lock mismatch; fix with tofu init -upgrade.
• Error: Failed to install provider means the provider exists but the download failed; that's network or disk.

Tool versions

All OpenTofu versions. Provider inference from resource type prefixes works the same across the 1.x line.

Why it happens

tofu infers required providers from resource type prefixes: anything starting azurerm_ implies the hashicorp/azurerm provider. A wrong prefix implies a wrong provider, and tofu only discovers the mistake when it asks the registry for a provider that was never published.

Edge cases

• If EVERY provider fails the same way at once, suspect network or proxy, not naming. A single bogus provider name points at a typo; all of them failing points at connectivity.
• Private registries and network mirrors: check the CLI config file's host credentials and mirror blocks before blaming the config.
• Modules can imply providers too. If the root config looks clean, grep inside .terraform/modules or your module sources for the bad prefix.

Stack Overflow question 79452956, 'OpenTofu fails to query provider packages': tofu init failed because a resource used the azure prefix instead of azurerm, so OpenTofu went looking for a nonexistent hashicorp/azure provider. The accepted answer (by Martin Atkins) identified the wrong resource type prefix as the cause, with the fix being to correct the prefix so tofu resolves the real provider. Source: https://stackoverflow.com/q/79452956/

Not specified by the original author.

Fix terraform "Error: Failed to install provider"

TL;DR: terraform init could not download or verify a provider plugin. Read the line under the error; it names the real cause (network timeout, checksum mismatch, no space left, missing platform package). Fix that cause, then re-run terraform init. Most cases are transient network failures or a stale .terraform.lock.hcl.

The error

Error: Failed to install provider

Error while installing hashicorp/aws v6.47.0: write
.terraform/providers/registry.terraform.io/hashicorp/aws/6.47.0/linux_amd64/terraform-provider-aws_v6.47.0_x5: no space left on
device

(Your sub-line will differ. Common ones: checksum mismatch against the lock file, TLS handshake timeout, registry unreachable.)

Steps

1. Read the sub-error. It is the actual diagnosis. Categorize it:

   • no space left on device: free disk space.
   • doesn't match any of the checksums previously recorded in the dependency lock file: lock file conflict.
   • TLS handshake timeout / connection refused / Could not retrieve the list of available versions: network or proxy.
   • does not have a package available for your current platform: wrong arch (e.g. 32-bit).

2. For lock-file checksum conflicts, regenerate the lock file:

   rm .terraform.lock.hcl
   terraform init

   Expected: providers install, and a fresh lock file is written. Commit it.

3. For network failures, check reachability and retry. Behind a corporate proxy, export the proxy vars first:

   curl -s https://registry.terraform.io/.well-known/terraform.json
   export HTTPS_PROXY=YOUR_PROXY_HOST
   export HTTP_PROXY=YOUR_PROXY_HOST
   terraform init

   Expected: the registry answers and the install proceeds.

4. For repeated flakiness (GitHub CDN TLS timeouts on community providers), retry once or twice; these are usually transient. Expected: a later init succeeds with no config change.

When this applies

• terraform init fails at the "Installing ..." step with any sub-error.
• You changed provider versions, platforms, or the lock file.

When it does NOT apply

• Init fails earlier at "Finding ... versions" with Failed to query available provider packages. That is version-constraint or registry-access, a different fix.
• The provider installs but plan fails with auth errors. That is provider configuration, not installation.

Tool and version compatibility

• Terraform CLI 0.13+ (provider source model) through 1.x.
• registry.terraform.io and community providers hosted on GitHub releases.

Why it happens

Init downloads each provider binary for your platform and verifies it against .terraform.lock.hcl checksums. Anything that breaks that chain (no disk, no network, a lock file written on another platform, a registry namespace that moved like zscaler.com/zpa to zscaler/zpa) fails the whole install.

Edge cases and pitfalls

• Deleting the lock file and re-running init on a different platform than your team (M1 Mac vs Linux CI) writes platform-specific hashes. Regenerate for all target platforms with terraform providers lock -platform=linux_amd64 -platform=darwin_arm64 and commit the result.
• Fully offline environments: download the provider zip, unpack it into the local plugin dir layout, and init works without the network.
• Do not hand-edit checksums in the lock file. Regenerate it.

A user reported terraform init failing with Error: Failed to install provider for the cloudstack provider, with a TLS handshake timeout reaching GitHub's CDN. The confirmed diagnosis was a network path problem between their machine and the CDN endpoint; the suggested fix was to retry from a different network or install the provider binary locally into the plugin directory, after which init succeeded. Source: HashiCorp Discuss thread, https://discuss.hashicorp.com/t/error-when-installing-terraform-cloudstack-provider-plugin/59691

Not specified by the original author.

TL;DR: tofu can't download the provider: the registry asked for auth credentials, or the connection failed. Read the tail of the message. requires authentication credentials on registry.opentofu.org has been a transient registry-side incident; TLS timeouts are your network. Retry first, then check proxy and mirrors.

Error: Failed to install provider

Error while installing hashicorp/random v3.7.2: host registry.opentofu.org
requires authentication credentials

Steps

1. Read the tail of the error (the part after the provider name and version). It distinguishes the causes:

   • requires authentication credentials / 403 Forbidden: registry-side or proxy issue.
   • TLS handshake timeout / could not connect: your network.
   • checksum mismatch: lock file problem, different fix.

   Expected: you can name the cause.

2. Retry once. Registry-side blips and rate limits are transient. Expected: the second tofu init succeeds.

3. If it persists, check the path to the registry: proxy env vars (HTTPS_PROXY), egress firewall rules, and whether curl -sI https://registry.opentofu.org answers from the same machine. Expected: you find the broken hop.

4. For air-gapped or flaky networks, install via a filesystem mirror: download the provider zip once, unpack it under the documented local mirror directory layout, and re-run init. Expected: init uses the local copy without touching the network.

When this applies

• tofu init fails on Error while installing [provider] v[version]: with a registry, auth, or network complaint.
• It worked before with no config change (points at transient/registry-side).

When it doesn't apply

• Error: Failed to query available provider packages fails earlier, at version LISTING; this error fails at DOWNLOAD.
• Checksum mismatches (doesn't match any of the checksums previously recorded) are a lock-file problem; fix with tofu providers lock.

Tool versions

All OpenTofu versions.

Why it happens

Installing is a plain HTTPS download from the registry (or a mirror). Anything that breaks HTTPS here, broken proxy, egress block, expired CA bundle, registry incident, surfaces as this error, after version resolution already succeeded.

Edge cases

• Corporate MITM proxies: the Go HTTP client needs the proxy CA in the system trust store, or every registry call fails TLS.
• Don't "fix" a 403 by adding registry credentials to your CLI config unless you actually use a private registry. The public registry needs no auth; a 403 there is an incident or a proxy mangling the request.
• CI runners with IPv6-only egress have hit discovery-document failures; forcing IPv4 or fixing egress is the fix, not the config.

Asked: how to fix Error: Failed to install provider. Verified answer: Fixes OpenTofu's 'Error: Failed to install provider' when the registry demands auth or the download fails. The fix steps above were cross-checked against the accepted community answer at https://github.com/opentofu/registry/issues/2614, which confirms the same resolution.