Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

7 Answers

up vote 11 down vote accepted
> 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.

share|improve this answer
add comment

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.

share|improve this answer
    
I did this just about an hour ago on one of my file servers. +1 –  Thomas Denton Jun 2 '09 at 21:53
add comment

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.

share|improve this answer
add comment

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"

share|improve this answer
add comment

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.

share|improve this answer
1  
I Agree with @David Mackintosh. If SELinux is enabled and if the files/directories were created by someone else and then changed ownership to bob, this is likely to happen. as the context of files remains with the original author and wont be accessible till the context is also changed to Bob user. –  viky Jun 3 '09 at 3:36
add comment
> sudo ls -al ./log
drw-rw-r-- 3 bob bob      4096 Jun  2 04:11 .

I am not sure why but the "." entry in ./log/ doesn't have execute permissions. The permissions should be identical to those for ./log.

Can you try chmod 755 ./log and chmod 755 ./log/. and see if either command fixes the access?

Other than that I would advise that you run an fsck on the filesystem because it looks like it is out of sync.

share|improve this answer
add comment

Have you tried changing ownership of the directory to someone else, then back to Bob? Zoredache's advice is better, though - just fsck it!

share|improve this answer
1  
This type of issue always ends up being directory permissions. –  doublejosh Feb 24 '13 at 0:48
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.