Examples:

d--x-w-r-t 2 1194197678 44975707 90112 Jun 5 1971
d-w--wS--- 2 1145962496 462029306 49152 Dec 31 1969

Even with Root, I can not chown, chmod, or remove these files/directories. What do I do to fix this issue?

Thanks,
Adam

If it's only these, boot a rescue or Live CD and fix it.

These are the ones that I aware of right now. So only booting into a rescue cd can fix these files?

I also have a ton of files in lost+found, some of them have the same permission issues. What can I do with these? Anything?

Even when I boot into a rescue cd, I can not chmod chown or remove the files. Any other ideas?

- what caused this?
- is the partition mounted read-write?
- if it is an ext2/ext3 partition, do files have extended attributes set? (lsattr)
- what is the exact error you get for each of chown/chmod/rm?

this looks like something that I would usually run fsck to fix. but then, you claim that fsck caused it, so I have no idea (maybe run fsck again?)

The system was running fine, and after a reboot, it kernel wouldn't boot, it kept halting at checking a disk. Eventually, it came up and said I had to run fsk manually. I did, and I had to "fix" files about 1,000 times. After that, I had these files messed up. I could try fdisk again.

It is a ext3 partition, mounted as read/write, not sure about extended attributes.

The exact message is "Operation not permitted".

The system was running fine, and after a reboot, it kernel wouldn't boot, it kept halting at checking a disk.
*Something* must have happened for this to occur. Errors like these don't pop up all by themselves. If you are sure you did *nothing* (with all due respect but I can't imagine that), do your syslog files hold any clues?

Check the state of the partition with "tune2fs -l /dev/partitiondevicename | grep state:". If it says "clean" then running fsck again should not be necessary.
Check SELinux is disabled setting "selinux=disabled" in /etc/sysconfig/selinux if you boot a SELinux-enabled kernel (or use setenforce 0).
Check extended file attributes with "lsattr".
Check the directory being chowned root first, then chmodded 0700 before you try to delete files inside an unowned directory. If it still gives errors please give output for a single file this way:
ls -alZ filename 2>&1 | tee /tempdir/file.log
lsattr -a filenname 2>&1 | tee -a /tempdir/file.log
stat filename 2>&1 | tee -a /tempdir/file.log

* Since you're running an RPM-based distro we could try to recover files if 0) they are part of a package, and 1) if your RPM databases in /var/lib/rpm are OK and 2) if the files in lost+found are OK. The remainder we can probably recover running "file" and reading them. Start by dumping the contents of the RPM database to file:
"rpm -qa --dump > /tempdir/rpmsums.log". If the subject is a file then the fourth field will be the MD5sum.
Now md5sum the contents of /lost+found: "md5sum /lost+found/* > /tempdir/lostsums.log". If the subject is a file then the second field will be the MD5sum. Now compare for sums and if you have a match you'll have 0) verified the content of the file is unchanged and 1) the name, rights and location. Need a script for it? :-]