2016-03-08 21:37:34 +01:00
---
layout: "docs"
page_title: "Command: untaint"
sidebar_current: "docs-commands-untaint"
description: |-
The `terraform untaint` command manually unmarks a Terraform-managed resource as tainted, restoring it as the primary instance in the state.
---
# Command: untaint
The `terraform untaint` command manually unmarks a Terraform-managed resource
as tainted, restoring it as the primary instance in the state. This reverses
either a manual `terraform taint` or the result of provisioners failing on a
resource.
This command _will not_ modify infrastructure, but does modify the state file
in order to unmark a resource as tainted.
~> **NOTE on Tainted Indexes:** In certain edge cases, more than one tainted
2019-08-06 21:18:20 +02:00
instance can be present for a single resource. When this happens, you need to specify the index after the resources, e.g. `my-resource-example[2]` . You can use the `terraform show` command to inspect the state and
2016-03-08 21:37:34 +01:00
determine which index holds the instance you'd like to restore. In the vast
majority of cases, there will only be one tainted instance, and the `-index`
flag can be omitted.
## Usage
Usage: `terraform untaint [options] name`
The `name` argument is the name of the resource to mark as untainted. The
format of this argument is `TYPE.NAME` , such as `aws_instance.foo` .
The command-line flags are all optional (with the exception of `-index` in
certain cases, see above note). The list of available flags are:
* `-allow-missing` - If specified, the command will succeed (exit code 0)
even if the resource is missing. The command can still error, but only
in critically erroneous cases.
* `-backup=path` - Path to the backup file. Defaults to `-state-out` with
the ".backup" extension. Disabled by setting to "-".
2017-04-04 19:48:59 +02:00
* `-lock=true` - Lock the state file when locking is supported.
* `-lock-timeout=0s` - Duration to retry a state lock.
2016-03-08 21:37:34 +01:00
* `-module=path` - The module path where the resource to untaint exists.
By default this is the root path. Other modules can be specified by
a period-separated list. Example: "foo" would reference the module
"foo" but "foo.bar" would reference the "bar" module in the "foo"
module.
* `-no-color` - Disables output with coloring
* `-state=path` - Path to read and write the state file to. Defaults to "terraform.tfstate".
2021-01-15 23:13:53 +01:00
Ignored when [remote state ](/docs/language/state/remote.html ) is used.
2016-03-08 21:37:34 +01:00
* `-state-out=path` - Path to write updated state file. By default, the
2016-08-08 02:59:28 +02:00
`-state` path will be used. Ignored when
2021-01-15 23:13:53 +01:00
[remote state ](/docs/language/state/remote.html ) is used.
backend: Validate remote backend Terraform version
When using the enhanced remote backend, a subset of all Terraform
operations are supported. Of these, only plan and apply can be executed
on the remote infrastructure (e.g. Terraform Cloud). Other operations
run locally and use the remote backend for state storage.
This causes problems when the local version of Terraform does not match
the configured version from the remote workspace. If the two versions
are incompatible, an `import` or `state mv` operation can cause the
remote workspace to be unusable until a manual fix is applied.
To prevent this from happening accidentally, this commit introduces a
check that the local Terraform version and the configured remote
workspace Terraform version are compatible. This check is skipped for
commands which do not write state, and can also be disabled by the use
of a new command-line flag, `-ignore-remote-version`.
Terraform version compatibility is defined as:
- For all releases before 0.14.0, local must exactly equal remote, as
two different versions cannot share state;
- 0.14.0 to 1.0.x are compatible, as we will not change the state
version number until at least Terraform 1.1.0;
- Versions after 1.1.0 must have the same major and minor versions, as
we will not change the state version number in a patch release.
If the two versions are incompatible, a diagnostic is displayed,
advising that the error can be suppressed with `-ignore-remote-version`.
When this flag is used, the diagnostic is still displayed, but as a
warning instead of an error.
Commands which will not write state can assert this fact by calling the
helper `meta.ignoreRemoteBackendVersionConflict`, which will disable the
checks. Those which can write state should instead call the helper
`meta.remoteBackendVersionCheck`, which will return diagnostics for
display.
In addition to these explicit paths for managing the version check, we
have an implicit check in the remote backend's state manager
initialization method. Both of the above helpers will disable this
check. This fallback is in place to ensure that future code paths which
access state cannot accidentally skip the remote version check.
2020-11-13 22:43:56 +01:00
* `-ignore-remote-version` - When using the enhanced remote backend with
Terraform Cloud, continue even if remote and local Terraform versions differ.
This may result in an unusable Terraform Cloud workspace, and should be used
with extreme caution.