PROC S3: Error reading config file in separate file

[darwinwalters]

We're currently using SAS 9.04.01M5 with SAS Studio Basic 3.71, deployed on an EC2 instance.  Our instance has credentials stored in a location other than ~/.aws/config or ~/.aws/credentials.  

According to the PROC S3 documentation (https://documentation.sas.com/?docsetId=proc&docsetVersion=9.4&docsetTarget=n1volodm4xnj3xn1s99poiem...), we should be able to use AWSCONFIG="AWS-CLI-file-path" if our config file is not in ~/.aws/config.

Here is the code we are using to test S3 connectivity:

PROC S3 AWSCONFIG="/path/to/config";

    list "/bucket-name";

run;

However, we're running into the following errors:

ERROR: The AWS configuration/credentials could not be read.

ERROR: Value could not be placed into buffer provided.

Has anyone encountered this problem before?

Thanks!

[Kurt_Bremser]

I'd log on to the AWS instance (using putty or similar) with the user id running the SAS process, and try to navigate to the config file location, and then display the config file with cat. That should detect any permission or pathname issues.

To get your SAS user id, use

%put &sysuserid.;

[darwinwalters]

I've logged on as one user (the linux user used to install and run SAS), and was able to navigate and cat the contents of my config file (which also contains access key, secret key, and security token information).  The permissions are 666, so reading the file should not be an issue.

However, we plan on having most of our users log into SAS Studio by using the sasauth ldap method.  From my understanding, this will allow users to authenticate with SAS Studio by seeing if they can bind to an LDAP server, but will not actually create a linux system user on the instance. 

Would this cause issues with trying to use PROC S3?

[Kurt_Bremser]

SAS Studio uses an individual (non-pooled) workspace server, which needs a system user to work. AFAIK, there's still a shortcoming in the spawner so that it does not trigger the creation of home directory etc when a LDAP user uses a workspace server for the first time. Which means LDAP users need to log on to the system via commandline first.

(note that this is my current state of knowledge; the issue might have been fixed already, but I'm not working in a LDAP environment at the time)

The SAS install user MUST NOT be used to work with workspace servers, never ever.