BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
EricF0012
Fluorite | Level 6

My org is in the process of migrating SAS from an onsite server to Azure and simultaneously upgrading from 9.4M3 to 9.4M4. 

 

The install of 9.4M4 on Azure and the migration of the metadata seem to have worked, but when I'm testing stored processes using the SAS stored process web portal, I am getting the error "STP: User has insufficient authorization to access \\source code repository\file path".

 

Some of our stored processes are stored in the server metadata & those execute as expected, but the issue seems to be with stored processes with source code with a physical .sas file stored in one of the source code repositories. In SAS Management Console, I can view the source code for these stored processes via the Stored Process Wizard, so read-access IS present at some level. 

 

Further, the SAS System Services user group has the same permissions as our previous server where these stored processes will still execute. Needless to say, I'm stumped. I have a feeling there's an issue with the file path of the source code repositories, but those should remain static during the migration. Any help is appreciated!

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
PaulHomes
Rhodochrosite | Level 12

In addition to the advice from @SASKiwi you may also want to check network/file-system access for the operating system account running the SAS Stored Process server processes. The SAS Stored Process Server is usually configured to launch SAS processes using a service account, often named sassrv. Given that you are using a UNC path for your stored process .sas code, I would verify that the sassrv account (or equivalent in your environment) is able to access the file server containing the .sas code and has appropriate read permissions on the necessary file and directories to be able to access that code.

 

As individual stored processes can also be configured to run on either a SAS Stored Process Server or a SAS Workspace Server (or either), I would also check that, and if necessary verify access for any individuals running stored processes on workspace servers.

View solution in original post

5 REPLIES 5
SASKiwi
PROC Star

How are you accessing Azure? Are you supplying a user name / password to log in or are you using something like IWA (Integrated Windows Authentication) to gain access automatically? If you are using IWA then delegation of permissions can become a problem. If you are, try logging on with a user name / password - do you get the same problem?

 

I've never used Azure but the type of problem I'm describing happens with in-house servers and is likely with cloud-based ones as well.

 

I'd also advise you open a track with SAS Tech Support if you haven't done so already. 

EricF0012
Fluorite | Level 6
We opted to not use IWA due to the permissions issue you're describing. My username/password combo has no issue nor does one of my colleagues, but I believe it has to do with the headless SAS account, sassrv, not having proper permissions to read the file directory as @PaulHomes stated below.
PaulHomes
Rhodochrosite | Level 12

In addition to the advice from @SASKiwi you may also want to check network/file-system access for the operating system account running the SAS Stored Process server processes. The SAS Stored Process Server is usually configured to launch SAS processes using a service account, often named sassrv. Given that you are using a UNC path for your stored process .sas code, I would verify that the sassrv account (or equivalent in your environment) is able to access the file server containing the .sas code and has appropriate read permissions on the necessary file and directories to be able to access that code.

 

As individual stored processes can also be configured to run on either a SAS Stored Process Server or a SAS Workspace Server (or either), I would also check that, and if necessary verify access for any individuals running stored processes on workspace servers.

EricF0012
Fluorite | Level 6
It turns out that the authorized account under the generic SAS General Servers user group was using a local domain in the User ID instead of my org's network domain that has authorization to access the file server. I either missed configuring this in the SAS install or it defaulted to using a local domain without the option to change it. Either way, an easy fix!
PaulHomes
Rhodochrosite | Level 12

Good to hear you got it fixed. Thanks for marking it solved too!

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 5 replies
  • 1758 views
  • 4 likes
  • 3 in conversation