Introduction

The AWS CLI error "unable to locate credentials" means the CLI could not find usable credentials in any of the places it normally checks. In Bash workflows, that is usually a configuration problem rather than a shell problem: the script is running, but the process environment, selected profile, or credentials files are not what you think they are.

Start by Asking the CLI What It Sees

The fastest first check is:

aws configure list

This command shows where the CLI thinks its access key, secret key, region, and profile values are coming from. That is much more useful than guessing whether the shell exported the right variables.

A second good check is:

aws sts get-caller-identity

If that succeeds, your credentials are valid and discoverable. If it fails with "unable to locate credentials," the CLI still has no usable identity source.

Understand the Common Credential Sources

The AWS CLI usually looks for credentials in places such as:

• environment variables
• the shared credentials and config files under ~/.aws
• a named profile selected with --profile or AWS_PROFILE
• IAM role credentials on AWS compute

Environment-variable example:

export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...   # only for temporary credentials

Shared credentials file example:

[default]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

The important point is that your Bash script only sees what the process actually inherits. A terminal where credentials work interactively is not proof that a cron job, CI runner, container, or subshell sees the same configuration.

Profiles Are a Very Common Cause

One of the most common mistakes is configuring a non-default profile and then running a script that never selects it.

aws s3 ls --profile myprofile

Or:

export AWS_PROFILE=myprofile
aws s3 ls

If your credentials live under [myprofile] and the script assumes [default], the CLI may report that it cannot locate credentials even though the files exist.

This is especially common on developer machines with several AWS accounts configured side by side.

Containers, CI, and sudo Change the Environment

Credential problems often appear only when the command moves from your shell into another execution context:

• Bash script under cron
• Docker container
• CI job
• command run with sudo

Those contexts may use a different home directory, different user, or stripped environment variables. For example, if a container does not mount ~/.aws, the CLI inside the container cannot read the host's credential files.

That is why a command working locally in your terminal but failing in automation is a strong sign that the credential source is not actually present in the runtime context.

Common Pitfalls

• Assuming the credentials configured for one profile will be used automatically when the script never selects that profile.
• Forgetting AWS_SESSION_TOKEN when using temporary credentials.
• Running the command under sudo, cron, or Docker and expecting the same home directory and environment as the interactive shell.
• Debugging the Bash syntax when the real problem is simply that the AWS CLI cannot see any credentials.

Summary

• "Unable to locate credentials" means the AWS CLI could not find usable credentials in its normal provider chain.
• Start with aws configure list and aws sts get-caller-identity to see what the CLI actually sees.
• Check environment variables, shared credentials files, and named profiles explicitly.
• Be careful with scripts running in containers, CI, cron, or under sudo, because they often have a different environment.
• In Bash workflows, the fix is usually credential visibility and profile selection, not shell syntax.