Change UID (sidadm, sdb)

[Former Member]

Hi

We are on SLES 11.3, MaxDB 7.9 and NetWeaver 7.4 with latest patches. We have a set-up a 2 system transport landscape with a shared usr/sap/trans.

As the UIDs of the respective sidadms differ problems arise during file creation/access.

Now I want to change the UIDs of the sidadms.

The speciality is that I need to swap the UID of sidadm with the user sdb (it appears that, on the first host, sdb was created before sidadm, whilst on the other host sidadm has the lower UID).

The Linux-side procedure is not the problem at all, I guess: I change the UID of sdb to a temporary one, chown all files belonging to sdb to the temporary UID, do the same for sidadm, and do it a third time for the temporary UID of sdb. This is pretty well documented for SAP on Oracle on http://www.dataxstream.com/2009/08/changeuidsidadm/

Afterwards I have two problems:

1. The S-Bits are lost

There are some files and directories in /sapdb as well as /sapmnt/ directory which have SGIDs und SUIDs set. However I can look at the second host to see which files are affected and manually change the permissions.

2. MaxDB does not start

If I run startsap it complains about missing or invalid XUSER entries. User sidadm or sdb is not able to read or change the xuser list. The file system permissions on the .XUSER.65 file in are the same when compared to the second host. So I guess there is some mechanism in place that also checks for UIDs when accessing xuser entries.

Does anybody know how to "repair" the existing xuser file or grant access to a new uid/username combination?

Do I have to delete & re-create the file from scratch?

Any ideas appreciated.

Regards

Michael

[thorsten_zielke · Accepted solution]

Hi,

since you are on 7.9, let me suggest running as root 'sdbverify ... -repair_permissions' regarding the missing s-bits. The 'repair_permission' option automatically fixes missing file permissions. There are some limitations to what it can do, but it actually it is a very good help.

The xuser entries are OS user dependent and you will need to recreate them - if you have access to the SAP notes, please check note 39439.

Thorsten

Message was edited by: Thorsten Zielke oops, it is of course 'sdbverify ... repair_permissions' instead of 'dbmcli...', corrected this in my post...

[Former Member · Accepted solution]

Hi

Thanks for the help.

And thanks for the hint with repair_permissions. I guess along with saproot.sh it'll fix most of the S-Bit issues.

So I'll have to delete the .XUSER-files in userhome (sdb and sidadm) and recreate them as mentioned in note 39439 - or I'm going to xuser list the entries before I change the UID

Michael

[thorsten_zielke · Accepted solution]

Hi,

you should probably list the entries first and print the output to a file - just to have the parameter values at hand if you recreate them.

Yes, just rename the old .XUSER files, until you have finished the UID change and the new xuser keys are working.

Thorsten

PS:

please see my edit above regarding the 'sdbverify' instead of 'dbmcli'...

[Former Member · Accepted solution]

worked like a charm.

Thanks.