Emergency script help please.

[generic_1]

Hello We have a server that got its group and ownerships toasted and I need some emergency script help please. We have extracted the ownerships from Data Proctector (Omniback) but some of the values are negative,unassigned 2 compliment I think for some odd reason. Also there is some other data there too. I want to replace the -number with the correct positive one I believe by adding 1 to the netagtive number then 65535 to the output to get the proper positive number. There is some comments in the output. Below is a text example of the data I am trying to correct.

chown -h 15267:1039 '/home/'
chown -h -1400:1051 '/var'
#comment that may interfere with columns

I need to be able to keep the same script and correct the negagive value for the owner to a valid pasitive value. I am dealling with hundreds of thousands of file.

Many Many Thanks.

[James R. Ferguson]

Hi Jeff:

If the ownership of a file or directory is shown numerically, this merely suggests that the mapping of number-to-name cannot be made (usually through '/etc/passwd').

Do you have an 'etc/passwd' file? Are you running NIS? Did you restore files, and if so to the correct server?

Regards!

...JRF...

[generic_1]

the UID is showing up negative that is not valid. I am not worried about the entries in password and group. Those are in tact.

[James R. Ferguson]

Hi (again) Jeff:

I don't understand what you restored. If is is only the directory take has the wrong ownership, do something like:

# chown root:sys /home

If you want to recursively 'chown' a directory (and all its subordinate contents!) use:

# chown -R bin:bin /mydir

Be careful here.

Perhaps you want to find files whose ownership doesn't match login accounts on your server:

# find /home -xdev -nouser
# find /home -xdev -nogroup

Does this help?

Regards!

...JRF...

[Bill Hassell]

Negative numbers (for that matter, all numbers) shown with the ll command are just a simple conversion of the integer value stored for the inode. Any number means there is *no* user name for that number in the password file. Again, there's nothing wrong with the invalid number--changing it to a positive value is just cosmetic,although if you change the user number so it matches a UID in /etc/passwd,yopu have just changed ownership for the file. And the same applies for the group number.

Now if the affected files are supposed to be owned by a valid user, then you'll have to extract these filenames (with full path and user/group info) from your backup and create a sceript to change each file (chown/chgrp).