16

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?

Gordon Wilson
  • 263
  • 1
  • 3
  • 6

8 Answers8

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

OtherDevOpsGene
  • 2,532
  • 20
  • 16
13

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.

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.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
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.

David Mackintosh
  • 14,293
  • 7
  • 49
  • 78
  • 2
    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 03 '09 at 03: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"

Haakon
  • 1,325
  • 7
  • 11
2

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

Jenny D
  • 27,780
  • 21
  • 75
  • 114
Justin Fortier
  • 820
  • 6
  • 9
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.

Russell Heilling
  • 2,557
  • 19
  • 21
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!

RainyRat
  • 3,730
  • 1
  • 24
  • 29