I had to do a recovery and restore from backup (using ignite & backups from fbackup job) on hpux 10.20.

Problem is, all users (except root) receive error 'unknown user' when logging in (during script that checks quotas).

They can still successfully log in to the system.
However, the files when viewed by the user using command ls -l show UID and groupID as opposed to the user & owner names (it should show the user name & group, not the IDs) Commands and databases can't be accessed/executed though, because they are 'unknown users'. What happened from the frecover to cause this? The users are all in the /home directory. The files are all intact.

Somehow the users must now have different uids and gids in /etc/passwd. You need to recover and install a copy of /etc/passwd.

it turns out the permissions on the /etc/passwd and /etc/group files are not set for reading for other...not sure why/how that happened...

anyone with ideas? i'm afraid there will be other key files i will need to adjust permissions on as we go along, but i'd rather find out why/how this happened.

Something similar happened to me ages ago on an aix :no one except root could connect to the box... was /etc/hosts and aix equivalent files to nsswitch.cong and resolv.conf set as 600...
Was probably the result of an admin trying fancy umask (but unfortunatly with root acount)

All the best

My issue is just why/how did my permissions get changed?

im also having trouble performin certain informix functions from my database-again, i think it's due to DBTEMP or some other area/files that can't be accessed.

I'm guessing there was some sort of problem with the restoration of the backup...

The Informix problem is probably due to permissions in the volume group files. /dev/vg2/lvol2... stuff like that. They probably used to be writable by informix but no longer are. frecover gets permissions right. so i guess I suspect the ignite process. Where did /etc/passwd come from...ignite or frecover?

even if i temporary change the permissions on the vg groups in /dev i still have same result. after changing, do i need umount then remount for changes to really take affect?

the messages indicate it's trying to write to a temp file but can't. unix uses /tmp as a default. Permissions are OK on that directory, and it's not full.

any other ideas? thanks.