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

Hi, Experts,

 

I have a user who created a data set using EG 7.1 for Windows. The server is on RHEL, so their code looks similar to this:

 

libname myLib "/u01/sasdata/myFolder";

 

data myLib.test;

...[stuff]...

run;

 

I see that the data is now in /u01/sasdata/myFolder, but it has permissions of 660. Normally, this isn't a problem, except that the owner of the file is the user who created it, and the group is also the user who created it, so no one else can see this data. That is, when I do a ls -lart on the directory, I see the data set like this:

 

-rw-rw---- 1 dataCreator dataCreator 131072 Jan 24 13:51 test.sas7bdat

 

What I'd like to see, ideally, is:

 

-rw-rw---- 1 dataCreator    sasvba   131072 Jan 24 13:51 test.sas7bdat

 

...where sasvba is the group for dataCreator.

 

Otherwise, I can apply a umask and get it to look like this:

 

-rw-rw-rw- 1 dataCreator dataCreator 131072 Jan 24 13:51 test.sas7bdat

 

...but that wouldn't be ideal, since everyone could read/write to the data set.

1 ACCEPTED SOLUTION

Accepted Solutions
SenseiCAY
Fluorite | Level 6

We solved it by putting a umask in WorkspaceServer_usermods.sh.

 

Change the line that says "USERMODS_OPTIONS=" to "USERMODS_OPTIONS= umask 022"

 

Also, from SAS TS, note that the instructions located at http://support.sas.com/kb/38/040.html do not mention that the locations to put the umask option are hierarchical, meaning something in sasenv_local will override everything else, something in ObjectSpawner.sh will override anything other than sasenv_local, and so on, which is the problem I was having.

 

View solution in original post

3 REPLIES 3
nhvdwalt
Barite | Level 11

The group=dataCreator is being set because it's the primary group for user=dataCreator

 

You can either change this primary group or consider the use of the GUID on the target folder. From experience I prefer the GUID route since then it's guaranteed the data will land up with the correct group ownership. Using the former method assumes the primary group for the user is always correct, which many times it's not.

 

The forum can't provide specific answers since this design all relies on your security model, which differs from site to site. Your UNIX admins will be able to guide since this is more a UNIX topic than a SAS topic.

SenseiCAY
Fluorite | Level 6

We solved it by putting a umask in WorkspaceServer_usermods.sh.

 

Change the line that says "USERMODS_OPTIONS=" to "USERMODS_OPTIONS= umask 022"

 

Also, from SAS TS, note that the instructions located at http://support.sas.com/kb/38/040.html do not mention that the locations to put the umask option are hierarchical, meaning something in sasenv_local will override everything else, something in ObjectSpawner.sh will override anything other than sasenv_local, and so on, which is the problem I was having.

 

Ready to join fellow brilliant minds for the SAS Hackathon?

Build your skills. Make connections. Enjoy creative freedom. Maybe change the world. Registration is now open through August 30th. Visit the SAS Hackathon homepage.

Register today!
SAS Enterprise Guide vs. SAS Studio

What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 3 replies
  • 1187 views
  • 3 likes
  • 2 in conversation