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.;
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?
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.
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.