0

I had a support case for Microfocus Data Protector 10.91 that turned out to be a file permission problem eventually. User hpdp had group users instead of the intended omni, so I changed the groups of all affected files and directories after fixing the local user.

Actually the user should have been taken from LDAP, but was created locally with a different group, causing the problem. So I removed the local user and imported the user from LDAP. I had stopped Data Protector, rebooted the machine, and started Data Protector successfully. So everything seemed fine.

Backups work, the reporting Server is refreshed periodically, but suddenly some reports popped up an error saying that user should be removed and recreated.

Looking at the Users context, I see that no users and groups are displayed any more. But the ClassSpec and UserList files (as well as WebAccess) are still there and filled.

Even when I try to recreate the admin group I get an unspecific error "Error while adding group" with identifier 159:9995.

I have no idea what might be wrong, but I checked that the AppServer Java process runs with the correct UID and GID, and the files in question can be read via the GID at least.

In the logs I see something that looks as an SQL statement to look up users.

Additional info

/opt/omni/bin/omniusers -list also outputs nothing.

In DPserver.log I found "Get GroupName: User does not belong to a valid group.".

U. Windl
  • 366
  • 3
  • 17
  • Well, I'd wish those programmers would have created reasonable error messages, not saying *what* did not work, but *why* it did not work, or giving more details where the error originated. – U. Windl Oct 29 '21 at 09:43

1 Answers1

0

I found the problem, that is: At least I solved the problem:

Inspired by the message Get GroupName: User does not belong to a valid group. I suspected that the Java program fails to get the User or Group from LDAP (via nsswitch) (while both getent passwd hpdp and getent group omni did work).

So first I displayed the group entry using getent group omni, then added that line to the local /etc/group file using vigr. Next I did a similar thing for the user entry using getent passwd hpdp to display the entry, and then used vipw to add the entry to the local /etc/passwd file.

Finally when refreshing the Users context in the Data Protector GUI, the users and groups were there again!

My /etc/snnswitch.conf (SLES 12) contains (among other lines):

passwd: compat
group:  files ldap
passwd_compat: ldap

Conclusion: The Java Application Server does not use the system calls to check for users and groups, but accesses the fires directly.

U. Windl
  • 366
  • 3
  • 17