My coworkers cannot edit or properly run my code

[illmatic]

On SAS Studio in SAS Viya 3.5, my colleagues are getting errors regarding permissions on my projects. I am unable to locate a place to give them access. The share and collaborate area does not suffice for our projects as it entails libnames and SAS programs.

I have reached out to SAS cloud support on Jira a week ago, but they don't know how to help.

SAS Cloud hosts our environment and manages our user accounts.

Thank you.

[Quentin]

I won't be able to help (I don't have Viya), but suggest you describe the problem a bit more.

When do your colleagues get an error? When they open a project? When they try to run code?  When they try to edit code?  When they try to save code that has been edited?

What is the error message they get?

Where is the code stored?

On most linux environments, every user has a home directory, which is often accessible only that user.  So if your code is saved in your personal home directory, it might not be accessible to others.  It's also possible the code is readable by others but not writable, so they would get an error when they tried to save any changes.   But it all depends on where your code is saved.  In Viya, I think often the code isn't stored in OS directories.  It's all stored in a "SAS drive", which I think means it's all stored in a database rather than as files sitting in the OS.

[illmatic]

Hi Quentin!

I see the datasets and code saved under our company's parent directory. So, kind of like /corp-name/ and that's it. There are subdirectories there, but none of them attributed to any user. I may have created some subdirectories under the main directory, but it Viya shouldn't automatically make those private.

Anyways, they can see the code and all files, but running the code has issues with input dependencies and editing which is also strange.

I uploaded the messages my colleague is receiving. Hope that helps!

[SASKiwi]

Those error messages relate to permission problems on LIBNAME statements. That suggests that the directories you are setting up for your SAS libraries do not have the correct permissions to be shared with other users. I suggest you investigate to the folder permissions to see what is happening.  

[illmatic]

---

@SASKiwi wrote:

Those error messages relate to permission problems on LIBNAME statements. That suggests that the directories you are setting up for your SAS libraries do not have the correct permissions to be shared with other users. I suggest you investigate to the folder permissions to see what is happening.  

---

That's what I'm thinking as well, but there is no options in Viya that allow me to change permissions of these folders. I can't find it.

Our Viya is being hosted by SAS and I submitted a ticket two weeks ago on Jira, but they also are lost.

[Quentin]

---

@illmatic wrote:

---

@SASKiwi wrote:

Those error messages relate to permission problems on LIBNAME statements. That suggests that the directories you are setting up for your SAS libraries do not have the correct permissions to be shared with other users. I suggest you investigate to the folder permissions to see what is happening.  

---

That's what I'm thinking as well, but there is no options in Viya that allow me to change permissions of these folders. I can't find it.

Our Viya is being hosted by SAS and I submitted a ticket two weeks ago on Jira, but they also are lost.

---

That's scary if the SAS hosting team can't help. Maybe you should try SAS tech support (though one would hope the cloud team might have tried tech support if they are flummoxed).  

I've done that before, where some IT group can't figure out a problem, then I put in a ticket to a different IT group, set up a meeting, introduce the problem, and then try to back out of the room quietly. : )

[Reeza]

---

@illmatic wrote:

I see the datasets and code saved under our company's parent directory. So, kind of like /corp-name/ and that's it. There are subdirectories there, but none of them attributed to any user. I may have created some subdirectories under the main directory, but it Viya shouldn't automatically make those private.

---

Are the libraries that are creating the issues under /corp-name/ or are they subdirectories you may have created?

Have you confirmed that your team mates can access these directories and libraries regardless of your projects?

[illmatic]

---

@Reeza wrote:

---

@illmatic wrote:

I see the datasets and code saved under our company's parent directory. So, kind of like /corp-name/ and that's it. There are subdirectories there, but none of them attributed to any user. I may have created some subdirectories under the main directory, but it Viya shouldn't automatically make those private.

---

Are the libraries that are creating the issues under /corp-name/ or are they subdirectories you may have created?

Have you confirmed that your team mates can access these directories and libraries regardless of your projects?

---

Hi Reeza,

I created the subdirectories under the main directory, that is correct. 

My team can see all the files associated with my projects.

My team can run the code, albeit unsuccessfully.

My team cannot make edits to my code.

I cannot change permissions of the directories. At least, I can't find out how to...no menus in Viya seems to allow me to manage permissions.

[Tom]

Sounds a lot like issues we have had with Unix.

The system folks liked to set the default UMASK setting to 022 so that new files are NOT writable by members of the GROUP that owns the file.  But that makes using shared project folders impossible.

I always tell our SAS users to change the UMASK setting to 002 so that the default when they make a file is that it is writable to both the owner and the group.

On Unix it is also helpful to set the group sticky bit on directories so that when new files are created there they inherit the group from the parent directory instead of the group of the user that created them.

Perhaps something similar is happening under the hood in Viya?

[illmatic]

Thanks Tom. I have no idea and our SAS Admins are equally as confused. I added your comments to our JIRA ticket, but this seems like a major flaw/inconvenience baked into SAS Viya platforms hosted on Unix.

In places where we managed our own SAS environment, I could simply putty in and change permissions, but I don't have that ability anymore since SAS hosts us. 

[SASKiwi]

Yes, that can be the downside of hosted systems. I'm pretty sure the same solution applies on Viya 3.5. Log in remotely and "chmod" the affected folders. One gets the impression that the new folder default permissions are set incorrectly - read/write for the user, but read only for your user group instead of read/write. Really your SAS admins should be more clued up on this.

[Kurt_Bremser]

On our AIX servers we use for SAS we implemented NFS4 access control lists, which are inherited by newly created directories in the tree and override umasks.

[Reeza]

---

I created the subdirectories under the main directory, that is correct. 

My team can see all the files associated with my projects.

My team can run the code, albeit unsuccessfully.

My team cannot make edits to my code.

I cannot change permissions of the directories. At least, I can't find out how to...no menus in Viya seems to allow me to manage permissions.

---

Seeing the files or the libraries and data sets?

And if the data sets can they access them via code not written in your project? 
If not, its very much a permission issues and it's usually fixing how permissions are inherited. 

Git has a similar default set up that's a bit infuriating but it's 'design' not a bug according to them as well. 

[Sajid01]

Hello @illmatic 
The solution to your issue requires an understanding of your environment.

If it is a permission issue the cloud server administrators will be able to resolve the issue. Unix permissions/acl's are fairly straightforward.

[illmatic]

Hi @Sajid01 

Thanks for the input and I think we are in agreement here. It's just that our environment is hosted by SAS and I am amazed that they don't know how to fix/adjust it.

We have escalated the issue through multiple teams at SAS over two weeks and have no received any resolution. It seems blatantly obvious at this point that SAS as a company does not understand the Unix machines they use to sell hosting services on and it's a glaring misstep.