'Permission denied' to a file I own?
My user, bob, can't access files that he (theoretically owns). I'm running Fedora Core 8. It probably easier to shown than tell:
> ls -al .
total 32
drwxrwxr-x 7 bob bob 4096 May 18 14:33 .
drwxrwxr-x 4 bob bob 4096 May 12 15:44 ..
drwxr-xr-x 2 bob bob 4096 June 1 14:22 log
> cd ./log
-bash: cd: log/: Permission denied
> ls -al ./log
ls: cannot access log/..: Permission denied
ls: cannot access log/the.log: Permission denied
ls: cannot access log/.: Permission denied
total 0
d????????? ? ? ? ? ? .
d????????? ? ? ? ? ? ..
-????????? ? ? ? ? ? the.log
> sudo ls -al ./log
drw-rw-r-- 3 bob bob 4096 Jun 2 04:11 .
drwxrwxr-x 7 bob bob 4096 May 18 14:33 ..
-rw-rw-r-- 1 bob bob 0 Jun 1 04:12 the.log
The ls -al
stands out as very odd. It will list the files that I don't have permissions to see, but not show me the permissions?
So the questions are, what would cause this? And what can I do to repair it?
> sudo ls -al ./log
...
drw-rw-r-- 3 bob bob 4096 Jun 2 04:11 .
It doesn't look like Bob has execute permissions for ./log, so he can't cd
to it.
But
> ls -al .
...
drwxr-xr-x 2 bob bob 4096 June 1 14:22 log
shows that he does. But it doesn't look like they are pointing to the same file (different permissions, different modtime).
Try sudo ls -ail ./log
and ls -ail
to see if the inode is the same.
Things are more simpler than filesystem corruption or selinux. As you can see you are missing the x (executable) permission on the log directory. Actually for directories x means that someone is able to change to that directory. Just do an "chmod +x log" to fix that perm and you should be able to access it.
I have seen things like that when the filesystem has been corrupted, or if you have a failing drive. The fix usually is to run fsck against the filesystem and let it correct errors it has found.
Also, check SE/Linux settings. Sometimes the permissions on the file don't have anything to do with whether or not you can access it.
The files may have the immutable or append only extended attributes set. I've had this happen before and not even root could delete the file.
Extended attributes can be views via "lsattr" and altered via "chattr"