13

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?

17
> 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.

9

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.

  • > Actually for directories x means that someone is able to change to that directory Wow. I keep forgetting that ; thanks. – yPhil Feb 22 '15 at 13:16
6

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.

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

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.

  • 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
2

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"

1
> 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.

1

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

  • 2
    This type of issue always ends up being directory permissions. – doublejosh Feb 24 '13 at 0:48
1

A more concise answer IMO.

Your directory does not have executable permissions, which are required by cd.

Fix:

$ sudo chmod +x ./log

Recursively:

$ sudo chmod -R +x ./log

+x is adding the executable attribute. You can always remove the attribute by doing -x

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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