TSM Backup issue on HP server

[Becke]

Dear Guys,

Our TSM daily incremental backup is getting failed with the below error

"Node Name: HPPROD03
ANS2050E TSM needs to prompt for the password but cannot prompt because the process is running in the background.
ANS2050E TSM needs to prompt for the password but cannot prompt because the process is running in the background.
ANS1025E Session rejected: Authentication failure"

Please be aware that there is nothing wrong with the daily tsm backup script which does a tsm backup to tsm server using dsmc command as it has been working before and its also working in all other servers without any problems.

the above server is a tsm client and "RUNASSERVICE" does not appear to be a setting available to UNIX TSM clients, there is no mention in the manual. I think its not authenticating the password in the tsm server registry and may be that's why its giving out this error

Apart from that, thje doco says that TSM client stores a password by simply running a general command such as 'dsmc query session'. This is generally used when a local TSM scheduler service is used.

As im not a tsm admin and only have a limited knowledge in tsm so I require urgent assistance here in order to resolve the above error.

Please advise
Thanks Team
Raf

[Volker Borowski]

Hi,

look for the TSM.PWD file on the client.
May be it is lost or unmounted, so the client can not look up the password.

Second option, if you do not run the backups as root, is that the backup user has no write access to TSM.PWD.

In this case most likely the root s-bit on one of the tsm-client files is missing and the client is unable to update the password in TSM.PWD.

Volker

[Becke]

Thanks Volker for your quick response.

I have tried to update the TSM password by running the set password command, this has successfully updated the password in TSM.PWD file as I can see the time and date stamp ie -rw------- 1 root system 148 May 10 10:25 TSM.PWD

Now my question is which tsm client file you are reffering to where root's bit is missing? are u referring to DSM.OPT client option file??

The permissions on DSM.OPT is same as on some of the other servers where its working, we have 444 permissions on dsm.opt file??

Thanks so much for your help mate. Look forward to hearing from you
Raf

[Volker Borowski]

Sorry I do not know exactly.
Currently I am off from any clients site that tend to use TSM and I am not that sure from memory where that beast is located.

Temporaryly you can easyly chmod TSM.PWD to 644 and check if this gets you back working.
If yes, it is surely a permission Problem on TSM.PWD. Since 600 is correct for security reasons, the TSM client file needs to be suid. Otherwise it can not access that thing.

We had some trouble with this on SAP systems, when the filesystem backup changed the password and the SAP-Backup with the TDPR3 integration failed after that, because the permissions have been reset during that password change.
I mind to rememeber there was a patch for the tsm client for that, but not so sure.
Our workaround until the patch was deliverd was to set the File

root:dba and 660

Groupaccess for dba was to make the SAP Integration working again.

On Solaris the clientfiles resided under /opt/tivoli/tsm/client/ ...

Look if you have any sbit files underneath this tree (or yours /usr/tivoli ???, if not /opt/tivoli/ is used). I think there should be one or two suid-files.

Volker