user cannot access the cube

[woo]

[have this question under SAS EG section but think of posting here]

hello,

we have a situation where one user can update cube and other user cannot even after having same access for the cube.

we have a sas olap cube, cube1, which is own by user1. user1 and user2 part of group1.

drwxr-xr-x 3 user1 group1 cube1

from sas side,

we have a group called developers where both user1 and user2 part of it. Cube1 has full explicit access (for RM/WM/R) for developers.

Now, only user1 can update the cube and not user2. is it because it is owned by user1 and not user2? I do not have much idea about cubes. anything needs to check?

when user2 try to update the cube using, get below error (background code start with PROC OLAP CUBE=),

NOTE: The cube registration was found.

ERROR: User does not have privileges for the attempted operation.  File =/.../cube1/genmeta.  System Error Code = 13.

ERROR: Insufficient authorization to access /.../cube1/genmeta.

ERROR: An error occurred when accessing the cube GENMETA file.

ERROR: The physical cube cannot be deleted.

[ShelleySessoms]

I have deleted the duplicate post in the EG community, so all communication will be centralized in this community.

[woo]

Thanks Shelley,

[Kurt_Bremser · Accepted solution]

Yes, your problem comes from the fact that your cube was crearted by user1 and has write permission set only for the owner:

d rwx r-x r-x

d denotes that the file in question is a directory

the first triplet after that is the owner's permission (user1), who can read, write and execute (execute on a directory means that you can cd to it)

the second triplet is for the group (group1), and the third for all others.

If group1 is your developer group, you can try if it is sufficient to set write permission for the group on the directory; if you use a sequence of proc olap delete physical and proc olap, this might be enough. For direct updates, you should try to run

chmod -R g+w dir

where dir is the root directory of your cube. This will change the permission recursively on the whole tree.

[JuanS_OCS]

As @Kurt_Bremser said :D. 

Only one more thing to add, just add: towards a final solution, you would perhaps try to set umask settings on your OLAP workspace server session

http://support.sas.com/kb/38/040.html

http://support.sas.com/documentation/cdl/en/mdlmgrag/67039/HTML/default/viewer.htm#n1gwhjs4v8dgy9n1s...

That way, you could prevent this from happening in the future.

[Kurt_Bremser]

One thing to make your work easier:

Consider creating a generic user who "owns" all your production cubes. After testing, developers should copy their cube structure to that user, and all create/update actions should be done by that user in batch. When someone needs to update the cube, they just su to the generic user and run the update. You can set that up via sudo, so that only a certain group of people is allowed to do that (without even entering a password).

This is basically the process we have for all our production work. If I need to run a production job "manually" (outside of the scheduler), I su to the userid that is used by the Control-M scheduler and run the batch job from the commandline. That way I also get all the goodies (error checking, log, protocol) that are built into the (custom) sasbatch.sh.

[woo]

Thanks KurtBremser and JuanS for your thoughts and ideas.

I tried providing write access (775) to group at dir level where cubes are located and also write access for group for "gendata" (...cube1/gendata) where user is getting error but still user is having same authorization error. Also, at cube level from SAS MC, I provided explicit permission for RM/WM/R for group of people where both users are part of it. - not sure why its still a problem,,, 

[Kurt_Bremser]

You might need to go the way of a single userID "owning" the cubes, and use that for all production cubes.