Can we restart SAS services on linux with a different UID, that the one used for installation

[draghun9]

Hello,

Need some advise with below issue.

Our SAS 9.4 app sits on linux server. Recently, to fix some AD authentication issue on our server, they have applied some patch/ solution, And from the, i see that the UID of the installation ID (rtdmsas) is different than what used to be during the installation and they are no so positive  about retreiving the old UID. So, Need your adwise on what can be done to start services as now i get permission denied error accessing the SAS install/config folders itself.

I know , its not advisable on opening up the permissions on the folders and start services. So, is there any other option you guys could suggest.

[JuanS_OCS]

Hello @draghun9,

it should be fine as long as you take the required counter measures. Meaning:

- assing same group memberships to the new sasinst user than the old one: sas, sasusers, sudo-ers (if apply), etc

- change the files ownership from the old sasinst user to the new one

   The bin/sashome, config, logs ... all SAS folders: https://documentation.sas.com/?docsetId=biig&docsetTarget=p0eqop8dtbe081n1xl4tgs69a15z.htm&docsetVer...

   And anything else you can think of where the old sasinst user was owner.

- Ensure the same changes of the user in the SAS Metadata, to ensure SAS can pick up the new user (and password if needed)

Of course, have a very good snapshot or full backup, before the change, restart services and hope that you did not miss anything.

PS: indeed, better not to think about 777 permissions and such. Endless Nightmares.

[draghun9]

Thank you for your response.

[Kurt_Bremser · Accepted solution]

As the superuser, do the following:

find / -user old_uid -exec chown new_user {} \;

where old_uid is the previous numerical id, and new_user is the username.

Do such operations only when a current backup of the whole system is available. Make sure that old_uid is not accidentally used by another user on the same system (you never know with things like AD).

[SimonDawson]

On Linux there are certain administration functions inside the SAS Deployment Manager where a comparison of the username of the SAS installation user that was used during the installation is compared with the one currently executing the task. I've seen first hand an instance of where the case of the username changed and this stopped the task from being able to be performed. I don't recall specifically which task in the SDM was being used. This is something to be mindful of.

[Kurt_Bremser]

From what I take from the original post (and the acceptance of my suggestion as the solution points to it), the username has not changed, but the underlying numerical uid that is supplied by the LDAP source for that username.

Something that should never happen, but can happen when a move to LDAP is implemented without proper planning and design. Or when a new business unit is added to an existing LDAP database, and collisions of the numerical uid's need to be dealt with. If the later, I'd actually recommend to also do a new setup of the SAS installation from scratch once the migration of the userbase has concluded successfully.