我的用户，鲍勃，不能访问他（理论上拥有）的文件。 我正在运行Fedora Core 8.它可能比显示更容易显示：
> 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 ls -al非常奇特。 它会列出我没有权限查看的文件，但不显示我的权限？
所以问题是，这会导致什么？ 我能做些什么来修复它？
> sudo ls -al ./log ... drw-rw-r-- 3 bob bob 4096 Jun 2 04:11 .
它看起来不像Bob对./log执行权限，所以他不能cd 。
但
> ls -al . ... drwxr-xr-x 2 bob bob 4096 June 1 14:22 log
表明他是这样做的。 但它看起来不像是指向相同的文件（不同的权限，不同的modtime）。
尝试使用sudo ls -ail ./log和ls -ail查看inode是否相同。
事情比文件系统损坏或selinux更简单。 正如您所看到的，您缺less日志目录上的x（可执行）权限。 实际上对于目录来说，x意味着有人能够改变到那个目录。 只要做一个“chmod + x日志”修复烫发，你应该能够访问它。
当文件系统被损坏，或者如果你有一个失败的驱动器，我已经看到类似的东西。 修复通常是针对文件系统运行fsck ，并让它纠正find的错误。
另外，检查SE / Linux设置。 有时文件的权限与您是否可以访问权限无关。
这些文件可能具有不可变或仅附加扩展属性集。 我以前有过这种情况，甚至根目录都不能删除这个文件。
扩展属性可以是通过“lsattr”的视图，并通过“chattr”
> sudo ls -al ./log drw-rw-r-- 3 bob bob 4096 Jun 2 04:11
我不知道为什么，但“。” ./log/中的条目不具有执行权限。 权限应该与./log相同。
你可以试试chmod 755 ./log和chmod 755 ./log/。 并查看是否有任何命令修复访问？
除此之外，我会build议你在文件系统上运行fsck，因为它看起来不同步。
你试过把目录的所有权改变给别人，然后回到鲍勃？ Zoredache的build议是更好的 – 只是fsck它！
IMO更简洁的答案。
您的目录不具有cd所需的可执行权限。
固定：
$ sudo chmod +x ./log
recursion：
$ sudo chmod -R +x ./log
+ x是添加可执行属性。 您可以始终通过执行-x来删除该属性