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.
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)
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.
What about /var ? is it:
drwxr-xr-x 23 bin bin 1024 Apr 12 2005 var
os:/var $ ll|more
total 28
-rw-r--r-- 1 12929 users 66 Dec 12 1995 OITAPE.TID
drwxrwxrwx 2 root sys 96 Dec 9 2003 PSS
drwxr-xr-x 3 bin bin 96 May 1 1999 X11
drwxr-xr-x 14 adm adm 1024 May 7 2007 adm
drwxr-xr-x 4 root sys 1024 Jun 13 2007 dt
drwxrwxr-x 2 root sys 1024 Apr 12 2005 lost+found
drwxrwxr-x 2 bin mail 1024 Oct 1 2007 mail
lrwxr-xr-x 1 root sys 8 Apr 7 2005 ncs -> /etc/ncs
drwxrwxrwx 2 bin bin 96 Mar 5 1997 news
dr-xr-xr-x 17 bin bin 1024 Jun 18 1999 opt
drwxrwxrwx 2 bin bin 96 Mar 5 1997 ppl
drwxrwxrwx 2 bin bin 1024 Mar 28 2006 preserve
drwxrwxrwx 2 bin bin 96 Mar 5 1997 rbootd
dr-xr-xr-x 3 bin bin 96 Dec 14 2005 run
dr-xr-xr-x 8 bin bin 1024 Mar 31 18:07 sam
dr-xr-xr-x 16 bin bin 1024 Dec 1 2006 spool
drwxr-xr-x 4 root sys 96 Mar 5 1997 statmon
drwxrwxrwx 5 root other 96 May 1 1999 stm
drwxrwxrwx 5 bin bin 2048 Apr 11 17:18 tmp
drwxr-xr-x 2 root root 2048 Dec 14 2005 tombstones
dr-xr-xr-x 6 bin bin 96 Mar 5 1997 uucp
drwxr-xr-x 2 root sys 96 May 22 2006 vue
drwxr-xr-x 3 root sys 1024 Mar 5 1997 yp
This isn't about changing the permissions on things that you mount. Databases often use raw unmounted space. If you mount all of your disk volumes, then this won't apply to you.
i can access things with no issues in test, but some things are not accessible in prod-items where informix seems to be needing to creating temp files.
my guess somehow permissions are not correct somewhere. I can access data through INformix SQL and some forms, but not others. programs that are being accessed the permissions are accurate, so again, it must be the temp space.