How to Fix Terraform Permission Denied on Ubuntu 22.04

Troubleshooting Guide: “Terraform Permission Denied” on Ubuntu 22.04

As a Senior DevOps Engineer, encountering “Permission Denied” errors with Terraform is a common hurdle, especially on Linux systems like Ubuntu 22.04. This guide provides a direct, professional approach to diagnose and resolve these issues.

1. The Root Cause: Why This Happens on Ubuntu 22.04

Terraform, at its core, needs to write files. This includes:

  • The .terraform directory: This is where Terraform stores providers, modules, state backups, and other working files.
  • The terraform.tfstate file: This crucial file holds the current state of your managed infrastructure.
  • Log files or temporary files: Depending on your configuration and provider.

The “Permission Denied” error arises when the user account executing Terraform lacks the necessary read, write, or execute permissions for these files or directories. On Ubuntu 22.04, this most frequently occurs due to:

  1. Mismatched Ownership: Terraform was previously run with sudo (as the root user), or by a different user, leading to files/directories being owned by root or another user. Subsequent attempts by your regular user account will fail.
  2. Incorrect Permissions: The file or directory permissions themselves are too restrictive (e.g., read-only for the current user).
  3. Inherited Permissions: Project directories copied from other locations might retain original ownership or permissions.
  4. umask Issues: While less common for direct “Permission Denied” on existing files, an overly restrictive umask could prevent new files or directories from being created with sufficient permissions for the current user.

2. Quick Fix (CLI)

The most common solution involves adjusting file ownership and permissions. Execute these commands from within your Terraform project directory.

# 1. Identify potential problematic files/directories
#    The error message will often point to the specific file or directory.
#    Common culprits are 'terraform.tfstate' and the '.terraform' directory.
ls -l terraform.tfstate
ls -ld .terraform

# 2. Change Ownership: Recursively set ownership of the current directory
#    and its contents to your current user and group.
#    Replace '$USER' with your actual username if not set, e.g., 'your_username'.
#    This is typically the most effective step.
sudo chown -R $USER:$USER .

# 3. Change Permissions: Recursively grant read/write/execute permissions
#    for the owner (your user) and read/execute for others.
#    This ensures you can modify files and traverse directories.
sudo chmod -R u+rwX,go+rX,go-w .

# 4. (Optional) If the .terraform directory seems corrupted or problematic,
#    you can remove it and re-initialize Terraform to regenerate it.
#    This is safe to do, as providers will be re-downloaded.
rm -rf .terraform
terraform init

Important Note on sudo: While sudo can temporarily bypass permission issues (by running Terraform as root), it is strongly discouraged for regular Terraform operations. Running terraform apply with sudo can create infrastructure owned by root and lead to further permission issues down the line, both locally and potentially with remote backends. Use sudo only for the chown and chmod commands to fix the underlying issue.

3. Configuration Check

After applying the quick fixes, verify the permissions on key Terraform assets.

  • Project Directory:

    ls -ld .

    Expectation: The owner and group should be your current user account (e.g., youruser youruser).

  • .terraform Directory:

    ls -ld .terraform

    Expectation: The owner and group should be your current user account, and your user should have write permissions.

  • terraform.tfstate File:

    ls -l terraform.tfstate

    Expectation: The owner and group should be your current user account, and your user should have write permissions (typically rw-r--r-- or 644).

  • Backend Configuration: If you’re using a remote backend (e.g., S3, Azure Blob Storage, GCS), while local file permissions are less of a concern for the state file itself, local caching in the .terraform directory can still be problematic. Also, ensure your AWS/Azure/GCP credentials have the necessary IAM permissions for the remote state bucket/container. This is a separate concern from local “Permission Denied” but can manifest in similar ways.

  • umask: Check your current user’s umask value:

    umask

    Expectation: A default umask of 0022 or 0002 is typical and usually sufficient. A umask of 0077 or similar would be too restrictive for collaborative work or standard tool operation.

4. Verification

To confirm the “Permission Denied” issue is resolved, execute standard Terraform commands.

  1. Initialize Terraform (again, if you removed .terraform):

    terraform init

    Expected Outcome: Successful initialization, downloading providers without permission errors.

  2. Generate a Plan:

    terraform plan

    Expected Outcome: Terraform successfully reads the state, refreshes, and generates an execution plan without permission errors. This is a good test as it reads the state and potentially writes temporary files to .terraform.

  3. Apply Changes (if applicable):

    terraform apply

    Expected Outcome: Terraform successfully applies the configuration and updates the terraform.tfstate file without any “Permission Denied” messages.

After successful plan or apply, re-check the ownership and permissions of terraform.tfstate and .terraform to ensure they remain consistent with your user account. If the error persists, carefully review the exact path mentioned in the error message and apply the chown and chmod commands specifically to that resource.

⚡ Related Troubleshooting Guides