Packer looks for AWS credentials file in the wrong place under Cygwin

[smitelli]

Since version 1.1.0, running Packer in a Cygwin shell causes an issue where the .aws/credentials file isn't correctly located.

Under Cygwin, the $HOME environment variable points to a path like /home/smitelli. Under the hood, Cygwin mounts / to C:\Cygwin, so the final translated path is C:\Cygwin\home\smitelli. A credentials file at ~/.aws/credentials or $HOME/.aws/credentials is actually stored on disk at C:\Cygwin\home\smiteli\.aws\credentials. The AWS CLI has no trouble with this setup and, as recently as version 1.0.4, Packer had no trouble either.

Starting with version 1.1.0, this setup leads to failed runs of the amazon-ebs builder and most likely anything that works with AWS:

$ packer build packer.json
amazon-ebs output will be in this color.

==> amazon-ebs: Prevalidating AMI Name...
==> amazon-ebs: Error querying AMI: NoCredentialProviders: no valid providers in chain
==> amazon-ebs: caused by: EnvAccessKeyNotFound: failed to find credentials in the environment.
==> amazon-ebs: SharedCredsLoad: failed to load profile, .
==> amazon-ebs: EC2RoleRequestError: no EC2 instance role found
==> amazon-ebs: caused by: RequestError: send request failed
==> amazon-ebs: caused by: Get http://169.254.169.254/latest/meta-data/iam/security-credentials: dial tcp 169.254.169.254:80: connectex: A socket operation was attempted to an unreachable network.
Build 'amazon-ebs' errored: Error querying AMI: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: failed to find credentials in the environment.
SharedCredsLoad: failed to load profile, .
EC2RoleRequestError: no EC2 instance role found
caused by: RequestError: send request failed
caused by: Get http://169.254.169.254/latest/meta-data/iam/security-credentials: dial tcp 169.254.169.254:80: connectex: A socket operation was attempted to an unreachable network.

==> Some builds didn't complete successfully and had errors:
--> amazon-ebs: Error querying AMI: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: failed to find credentials in the environment.
SharedCredsLoad: failed to load profile, .
EC2RoleRequestError: no EC2 instance role found
caused by: RequestError: send request failed
caused by: Get http://169.254.169.254/latest/meta-data/iam/security-credentials: dial tcp 169.254.169.254:80: connectex: A socket operation was attempted to an unreachable network.

==> Builds finished but no artifacts were created.

It appears either Packer or the underlying SDK is detecting Windows but not Cygwin, and using the %UserProfile% environment variable to construct the path instead of $HOME (%UserProfile% is something like C:\Users\smitelli; not the same place as Cygwin's homedir). I have confirmed that copying the .aws directory from Cygwin's $HOME location to Windows' %UserProfile% fixes the issue completely, but duplication of config files is not a satisfactory solution in my personal opinion.

• packer version: Packer v1.1.0
• uname -a: CYGWIN_NT-6.1 myhostname 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin
• PACKER_LOG=1 shows nothing useful that the UI didn't show

[rickard-von-essen]

We updated the aws-go-sdk in 1.1.0.

[smitelli]

I hate to be the type of person that bumps, but... bump? I'm stuck on v1.0.4; every version since has had this problem.

[SwampDragons]

I'm sorry to say this is not going to make it into the next release because we've already over-loaded it a bit. I understand that this is frustrating for you and I'm not giving you a satisfying answer, but one of the reasons it hasn't been highly prioritized is that it sounds like this issue can be worked around with a symlink or by using environment variables instead of a config file; we tend to not highly prioritize issues with viable workarounds, in favor of bugs that don't have workarounds.

That said, this does seem like a good issue for a new contributor to take a stab at, if they find it worth looking into before we get to it. I'll make sure it's marked as such so it's easier to find.

[SwampDragons]

Is this still an issue with current Packer? We updated the aws sdk several times since this issues was opened.

[SwampDragons]

Looks like this was introduced in aws/aws-sdk-go#1308 and was intentionally written to prevent HOME from being used on Windows. Since this was a conscious decision by the maintainers of the aws sdk, I'm going to close this as a "wontfix"; the solution is to make sure that "USERPROFILE" is set if you are on windows, regardless of whether you are in a unix-style shell.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.