after Admin restore, the permission of /var/opt/ericsson/nms_umts_pms_seg/segment1 become root
nmsadm@wtc2e3admn2:/var/opt/ericsson/nms_umts_pms_seg/segment1$ ls -l
drwxr-xr-x 2 root root 96 Jan 8 23:41 lost+found
the folder under /var/opt/ericsson/nms_umts_pms_seg/segment1 is empty.
Impact: the pm function is not available.
After Admin restore the permission of file /var/opt/ericsson/amos/moshell_logfiles is changed 755 and owner is changed to m78208
148224 0 drwxr-xr-x 3 m78208 nms 96 Jan 10 00:30 ./moshell_logfiles
the users did not have write access to the /var/opt/ericsson/amos/moshell_logfiles except user m78208
Impact : serious impact user useing moshell
How can we check whether the permissions are proper prior to backup and restore through CLI ?
If you believe that NBU restore caused DATA LOSS, then you need to log a Severity 1 call with Veritas and provide all relevant logs.
Any data loss must be seen as serious and escalated appropriately.
A user forum is not the right audience in this case....
lost+found is always owned by root
Plase see link for a describtion of lost+found
Is the target restore server the same as the original backup client? Or are you restoring to an alternate host?
Are any of the restore target folders actually an NFS mount from an NFS server?
Any sticky bits used in the target restore folder tree?
Any overriding umask settings on the target restore host?
So, Sowjanya comes here, make wild statements and accusations and then do not come back to provide feedback or reply to comments?
Maybe time to unpublish this post as this seems to be a none-issue?
I agree - unpublish it.
All we have some "symptomatic" text, and no thoroughly detailed evidence, nor detailed documented procedure which would allow anyone else to re-create the supposed problem.
We don't even have any detail regarding OS versions, NBU versions, file system types, file system versions, volume manager types, volume manager versions.
It could be argued that this post, is to date, purely based upon conjecture.