Problem:
Invocation of dsmc as a non-root user will result in error message “ANS1501E Trusted agent execution/owner permissions are invalid”. In dsmerror the tcaPath is reported as >/usr/bin/dsmtca< with a return code of 138.
Applies to:
TSM B/A Client running on AIX, Linux, HP-UX, or Solaris.
Related IBM Technote:
“Error message about Trusted Agent execution/owner permissions are invalid”.
Summary:
Non-root users are unable to use the TSM B/A Client to backup or restore their own files, unless the setuid bit is turned on. To backup and restore all files, the TSM B/A Client must be started when logged on as the root user.
SETUID?
In the Unix/Linux world, there is the concept of “setuid”. This is effectuated through ‘chmod u+s’, which causes the executable to run under the name of the owner of the executable, rather than the actual invoker. This way, an unprivileged user can gain powers which they would not ordinarily have. Some TSM executables, such as dsmtca are designed with this in mind; others such as dsmc are not.
Symptoms:
Interactive when running dsmc:
ANS1501E: Trusted agent execution/owner permissions are invalid
In Dsmerror.log:
09/22/2011 14:02:58 ANS0361I DIAG: Unable to locate valid trusted communication agent. 09/22/2011 14:02:58 ANS0361I DIAG: tcaPath is >/usr/bin/dsmtca
09/22/2011 14:02:58 ANS1501E Trusted agent execution/owner permissions are invalid
Cause:
Wrong permissions on the dsmtca file, possibly because of manually changed permissions or changed file ownership after the initial installation; the TSM client was not installed as the root user.
Resolution:
Check to see of there are indeed wrong permissions or incorrect ownership. Below is an example, resulting in wrong permissions because of chown or chmod:
[root@hannibal bin]# ls -l dsmtca
-rwxr-xr-x 1 oracle oracle 4051508 May 16 16:12 dsmtca
If needed, first correct the owner:
[root@hannibal bin]# chown root:root dsmtca
[root@hannibal bin]# ls -l dsmtca
-rwxr-xr-x 1 root root 4051508 May 16 16:12 dsmtca
Correct the SUID bit:
[root@hannibal bin]# chmod u+s dsmtca (or chmod 4755)
[root@hannibal bin]# ls -l dsmtca
-rwsr-xr-x 1 root root 4051508 May 16 16:12 dsmtca
Alternatively, reinstall the TSM B/A Client to get the default set of permissions. First remove the software, and then install it again. This will also reset ownership and permissions on other files.
Background information:
This article contains background information and additions to the listed IBM Technote. In this Technote it is stated that:
“The most common reason for this is when the permission’s on the dsmtca file are invalid. This is generally caused when the product is not installed with the root user ID as stated in the Client Manuals, or when the permissions for the file have been manually changed after installation.”
This is correct, as in this situation the permissions have been changed like this:
chown:/opt/tivoli/tsm/client –R
However, the information in the Technote is not entirely complete. Because, in addition to the changing of permissions, the error can also occur when the owner and group are anything else but the root user and the root group (for example root:root). The permissions below will not work, even though the permissions described in the section “Resolving the problem” in the Technote (4755 – rwsr-xr-x) are used:
[root@hannibal bin]# ls -l dsmtca
-rwsr-xr-x 1 oracle oracle 4051508 May 16 16:12 dsmtca
Another possible cause could be the change of ownership, because than the permissions are altered as well (rws changes to rwx):
[root@hannibal bin]# ls -l dsmtca
-rwsr-xr-x 1 root bin 4051508 May 16 16:12 dsmtca
[root@hannibal bin]# chown oracle:oracle dsmtca
[root@hannibal bin]# ls -l dsmtca
-rwxr-xr-x 1 oracle oracle 4051508 May 16 16:12 dsmtca
Also, I think that the s (the SUID bit) can be stressed out a bit more here, as readers might assume that the well known rwx is correct. This can be seen on some internet newsgroup discussions where users even go as far as issueing chmod 777 and assume that’s ok….they are surprised it isn’t. Keep in mind that chmod 777 will not set the SUID bit. However, the information in the Technote is technically correct and should be read with attention. This will end my Technote comments.
A brief discussion about dsmtca:
The given error message is stating that trusted agent (=dsmtca) execution/owner permissions (=execute permissions (=x)) are invalid (=anything else than rws and anything else than the root user as the owner). Dsmtca is the abbreviation of Distributed Storage Manager Trusted Communication Agent. However, sometimes being referred to at the Trusted Client Agent.
Dsmtca is only available on Linux, AIX, HP-UX, Solaris. Not on Windows. The TSM client uses the trusted dsmtca process to communicate with the ADSM server via a TCP session.
In dsmerror the tcaPath is reported as >/usr/bin/dsmtca< with a return code of 138. API return code 138 suggests someone diddling with permissions, or the software being run from an inappropriate or authority-changed account. The symbolic link should be like this:
[root@hannibal bin]# ls -l /usr/bin/dsmtca lrwxrwxrwx 1 root bin 41 Sep 6 15:03 /usr/bin/dsmtca -> ../../opt/tivoli/tsm/client/ba/bin/dsmtca
Permissions on dsmtca:
[root@hannibal bin]# ls -l dsmtca
-rwsr-xr-x 1 root bin 3073744 Nov 24 2009 dsmtca
As always, feel free to leave a comment if this was helpful for you in any way, or if you can’t resist the urge.
—-Tommy Hueber
