To cut a long story short, I've accidentally recursively ran chown on a directory (actually a bunch of 'em). Not a problem in itself, but I had a slight error in the code I used to get the list of directories and ended up with a comment in the file ownership.
For example, I now have directories full of stuff like:
$ ll php
total 40
drwxr-xr-x 4 # Scott - staff 136 3 Oct 12:37 .
drwxr-xr-x 14 root system 476 5 Oct 16:24 ..
-rw------- 1 # Scott - staff 12288 3 Oct 12:39 .swp
-rwxr--r-- 1 # Scott - staff 4817 3 Oct 10:14 test.php
Hi scott, do you remember whaat you typed? (hehe so I can corrupt my machine also...)
I cant recreate the situation so difficult to give any suggestion for now...
A while ago I was asked to remove some users from a production system. Rather than removing them I commented them out in /etc/passwd
i.e.
# Scott - removed 16.09.12 - userX:*:12345:45678.....
I also removed a symbolic link in /home to the actual home directory, and renamed the actual home directory to something else (i.e. /app/some/dir/prod/userX_DELETEME).
This was handy because a few days later I was asked to put some of the users back!
It's quite a few users so I thought I would write a script to do it recreate the link and rename the directories.
I've generated code to grab the username from the /etc/password but somehow got "# Scott" instead, and for reasons unbeknown seem to have run chown -R on the directory using "# Scott" as the owner, instead of the username.
I'm not quite sure why I ran chown but I have, and now I have a whole bunch of home directories which, when listed, show the owner as "#Scott -". ls -ln .
Yes, I agree, it's seeing # Scott from the /etc/passwd as the userid of the UID lookup from that file.
If you know the root userid password and can login as God then you should be able to change ownership of any files (single or recursive) by using a UID only, for example:
chown 3645 <filename>
The 3645 should appear in /etc/passwd as a valid UID of a user.
(You could change it to any UID number of your choice (not a valid user) but this may give you denied access later (which is what you've already done).
Login as God, use chown with a UID that matches up to a user in /etc/passwd.
getpwuid() reads /etc/passwd to translate the struct stat
uid_t st_uid
into a username - parses the file using : as a field sep. Using # to "comment out" lines in /etc/passwd
is non-standard so you confused getpwuid() into returning '# scott' as the the username.
If the account really no longer existed you would see a numeric uid because translation failed. Like when you tar from a foreign system.
I never had to to do tentative user remove like that.
Yes, I had a feeling some of the users would need to be re-instated, is why they were tentatively removed.
Just tested on Linux (using RHEL) and it handles it quite differently.
On Linux with only the "commented-out" line in /etc/passwd, ls -l shows me the UID, as I'd expected. If then I add the user back by copying the line and removing the comment, ls shows the username (regardless of whether I put the new entry before or after the commented-out one).
Mind you Scott I have also been doing the same, but now i will add the space after #... the reason is more for me on some servers (e.g. statistics office...) applications may be user/group developped, not being member of the office I dont remember or know all the changes in their staff.. for me to solve their issues I have to give names of people (for half - owners of specific application...) for them to tell me who is responsible of the application. on another server Im testing moving of obsoleted home dir saved elsewhere to have names but found cases where things took more time : The UID name didnt teach you much on the User true name and could not find a copy of /etc/passwd of the time to help you...
So I tend to comment out in these cases (UID/GID dependant code) and reaffect them to people when they are replacing the previous in usage (and so responsible of the code...) and give new Id to new staff