su: /bin/bash: Permission denied错误的解决方法，遇到类似问题的朋友可以参考下。
客户一个oracle突然当机了，由于业务启动，客户下意识的重启了服务器，系统是起来了，准备切换到oracle用户下启动数据库，可以怎么都无法su切换，真是火上浇油呀，描述如下：
在root用户下，su到一个普通用户oracle，得到如下错误:
而oracle用户也无法通过直接登录，出现同样错误。
这是一个非常奇怪的问题，到底是什么导致的呢？思路如下：
1，程序执行权限问题
2，程序依赖的共享库权限问题
3，目录权限问题
4，根空间问题。
检查/bin/bash，权限正确，检查/home/oracle权限正确，检查/lib/ld-***.so，权限也正确。
继续调试，检查/etc/passwd，将oracle的home设置为/tmp，把/tmp设置为777，这个权限应该是最宽松的。
而su出现同样的错误。
也就是oracle用户无法访问777权限的/tmp。
问题到底出现在哪里呢？
最后
通过slinuxjishu/14048.html target=_blank class=infotextkey>tar命令，看到了问题根本，
[root@localhost ~]#stat /
输出如下：因为你ls是看不到的。
File: “/”
Size: 1024 Blocks: 2 IO Block: 1024 目录
Device: 803h/2051d Inode: 2 Links: 22
Access: (0666/drw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-12-01 22:28:48.000000000 +0800
Modify: 2007-12-01 22:28:34.000000000 +0800
Change: 2007-12-01 23:17:35.000000000 +0800
问题出来了，这里的权限是错误的，X权限的丢失造成的。
[root@localhost ~]#chmod 755 /
修改后,问题消失。
产生上述问题的方法：
第一种，chmod 666 /，可以导致。
或者，
第二种，chmod 700 /lib/ld-xxxx.so，也可以导致su失败。
有兴趣的朋友可以自己试一下。
/ 权限的丢失对于各种运行在自己用户身份上的daemon也存在同样的影响。