某位仁兄新装一套Oracle 11gR2 RAC的过程中，在GI的安装配置阶段遇到了安装目录无法写入的报错，于是他便将$GRID_HOME下所有目录和文件属主改成了grid:oinstall，将$GRID_HOME下所有目录和文件权限改成了757，将$ORACLE_HOME下所有的目录和文件权限改成了757，侥幸过了安装这一关，紧接着麻烦就找上门了：使用srvctl无法启动数据库，症状如下：
$ /oracle/app/oracle/product/11.2.0/db_1/bin/srvctl start database -d shpboss -o open
PRCR-1079 : Failed to start resource ora.shpboss.db
CRS-2503: Resource 'ora.shpboss.db' is in UNKNOWN state and must be stopped first
CRS-2680: Clean of 'ora.shpboss.db' on 'qzp750707b' failed
CRS-5802: Unable to start the agent process ps -ef|grep oraagent
grid 15663174 1 0 14:28:38 - 0:01 /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent.bin
oracle 10944808 1 0 14:28:44 - 0:03 /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent.bin
grid 20578696 1 0 14:27:32 - 0:00 /oracle/app/grid/product/11.2.0/grid_1/bin/oraagent.bin
但事发当时却找不到oracle用户下的这个agent进程，只有grid用户下的两个。
$GRID_HOME下的安装目录及文件权限比DB要复杂的多，常见的有两种属主：root:oinstall和grid:oinstall，找了另一个11.2.0.4的RAC环境作为参照，$GRID_HOME目录下应该有以下一些目录的属主是root:oinstall的：
grid@qc740701a:/oracle/app/grid/product/11.2.0/grid_1>ls -lrt | awk '$3~/root/'
drwxr-xr-x 17 root oinstall 4096 Jul 31 2014 crs
drwxr-x--- 3 root oinstall 256 Jul 31 2014 gnsd
drwxr-xr-x 3 root oinstall 256 Jul 31 2014 osysmond
drwxr-xr-x 3 root oinstall 256 Jul 31 2014 ologgerd
drwxr-xr-x 3 root oinstall 256 Jul 31 2014 ctss
drwxr-x--- 4 root oinstall 256 Jul 31 2014 crf
drwxrwxrwt 6 root oinstall 256 Jul 31 2014 auth
drwxr-xr-x 3 root oinstall 12288 Jul 31 2014 lib
drwxr-xr-x 2 root oinstall 16384 Jul 31 2014 bin
drwxr-xr-x 4 root system 256 Jul 31 2014 tfa
而如今这些目录都清一色刷成了grid.oinstall，以下命令自然就没有输出了
root@qzp750707b:/oracle/app/grid/product/11.2.0/grid_1>ls -lrt | awk '$3=root'
srvctl 命令启动db时无法吊起的agent进程对应的可执行文件oraagent.bin正是位于$GRID_HOME/bin目录下，这样的诡异报错不免驱动我先去解决权限，先把错误的权限改对了再说。如果仅是手动改这些目录的属主还能接受，也就十来个，关键是目录下还有子目录和文件，这些子目录和文件的属主也root.oinstall的，手工逐个修改肯定不现实，难道要重装GI？ 多番查找终于找到一个较为省力且可靠的方法：
在PSU >=11.2.0.3.6的版本下可以通过root用户执行/crs/install/rootcrs.pl -init来恢复GRID_HOME目录下部分权限被篡改的文件或者目录的权限（为什么仅是部分，不是全部后面再解释），这条命令执行用时很快，不到5秒钟就返回命令行提示符了
root@qzp750707b:/home/grid>/oracle/app/grid/product/11.2.0/grid_1/crs/install/rootcrs.pl -init
Using configuration parameter file: /oracle/app/grid/product/11.2.0/grid_1/crs/install/crsconfig_params
查看一下效果，的确都改过来了
root@qzp750707b:/oracle/app/grid/product/11.2.0/grid_1>ls -lrt | awk '$3~/root/'
drwxr-xr-x 17 root oinstall 4096 Feb 23 19:29 crs
drwxr-xr-x 3 root oinstall 256 Feb 23 19:29 osysmond
drwxr-xr-x 3 root oinstall 256 Feb 23 19:29 ologgerd
drwxr-x--- 3 root oinstall 256 Feb 23 19:29 gnsd
drwxr-xr-x 3 root oinstall 256 Feb 23 19:29 ctss
drwxr-x--- 4 root oinstall 256 Feb 23 19:29 crf
drwxr-xr-x 3 root oinstall 12288 Feb 23 19:29 lib
drwxr-xr-x 2 root oinstall 16384 Feb 23 19:31 bin
在另一个节点如法炮制，终于srvctl 能够正常启动了db了，这还不放心，在两个节点上都执行了一边crsctl stop crs->crsctl start crs，对GI做一次完整的停启操作，该启的资源都能起来，GI和DB的alert.log里都没有报错，悬着的心这才放下。
之前我们曾提到rootcrs.pl -init运行耗时5秒钟就返回了，如果是对于GRID_HOME下所有的文件都检查并修正一边权限和属主5秒钟是远远不够的，这一点相信使用过chmod和chown的童鞋都有体会，经过我的进一步测试发现rootcrs.pl脚本修改的只是$GRID_HOME目录里这些子目录及其下的文件
drwxr-xr-x 17 root oinstall 4096 Feb 23 19:29 crs
drwxrwxr-x 5 grid oinstall 256 Feb 23 19:29 log
drwxrwxr-x 9 grid oinstall 256 Feb 23 19:29 cv
drwxr-xr-x 3 root oinstall 256 Feb 23 19:29 osysmond
drwxr-xr-x 3 root oinstall 256 Feb 23 19:29 ologgerd
drwxr-x--- 3 grid oinstall 256 Feb 23 19:29 ohasd
drwxr-x--- 3 grid oinstall 256 Feb 23 19:29 mdns
drwxr-x--- 3 root oinstall 256 Feb 23 19:29 gnsd
drwxr-x--- 3 grid oinstall 256 Feb 23 19:29 gipc
drwxr-xr-x 3 root oinstall 256 Feb 23 19:29 ctss
drwxr-x--- 4 root oinstall 256 Feb 23 19:29 crf
drwxr-xr-x 3 root oinstall 12288 Feb 23 19:29 lib
drwxr-xr-x 2 root oinstall 16384 Feb 23 19:31 bin
drwxrwxr-x 5 grid oinstall 256 Feb 23 19:31 cdata
drwxr-x--- 6 grid oinstall 256 Feb 23 19:36 gpnp
drwxrwxr-x 5 grid oinstall 4096 Feb 25 13:07 cfgtoollogs
drwx--x--x 6 grid oinstall 256 Feb 23 19:02 css
drwxr-x--- 7 grid oinstall 256 Feb 23 19:02 evm
从名称上可以看出这些都是GI后台核心进程的工作目录，猜测rootcrs.pl -init的功能只是修复各GI组件密切相关目录与文件的权限，保证GI能够正常启动与停止，但是对于其它目录则不管不问，于是我们可以看到$GRID_HOME目录下仍有大部分目录的权限还处在757
root@qzp750707b:/oracle/app/grid/product/11.2.0/grid_1>ls -lrt
total 176
-rwxr-xrwx 1 grid oinstall 59 Feb 22 16:05 oraInst.loc
drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 demo
drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 csmig
drwxr-xrwx 6 grid oinstall 256 Feb 23 18:57 assistants
drwxr-xrwx 6 grid oinstall 256 Feb 23 18:57 nls
drwxr-xrwx 5 grid oinstall 256 Feb 23 18:57 md
drwxr-xrwx 7 grid oinstall 256 Feb 23 18:57 javavm
drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 hs
drwxr-xrwx 4 grid oinstall 256 Feb 23 18:57 has
drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 diagnostics
drwxr-xrwx 4 grid oinstall 256 Feb 23 18:57 owm
drwxr-xrwx 7 grid oinstall 256 Feb 23 18:57 ord
drwxr-xrwx 4 grid oinstall 256 Feb 23 18:57 oracore
drwxr-xrwx 3 grid oinstall 256 Feb 23 18:57 wwg
drwxr-xrwx 5 grid oinstall 256 Feb 23 18:57 usm
。。。。。还有，此处省略了
为避免留下后遗症，我们需要将rootcrs.pl弃之不管的目录与文件的权限、属主也修复一下，怎么修复？MOS 1515018.1提供了现成的perl脚本，这个脚本使用方法很简单：从一台权限正常的服务器上抓取GRID_HOME、ORACLE_HOME下的所有文件与目录权限，生成shell脚本，然后在权限错误的主机上执行这个脚本，简单演示一下：
先把permission.pl下载下来复制到一台权限正常的服务器上，并赋予执行权限，这台主机上必须要有perl的执行环境
chmod u+x permission.pl
抓取$ORACLE_HOME下所有目录与文件的属主、权限，可以使用oracle用户或者root用户执行
./permission.pl /oracle/app/oracle/product/11.2.0/db_1
Following log files are generated
logfile : permission-Thu-Mar-10-14-25-31-2016
Command file : restore-perm-Thu-Mar-10-14-25-31-2016.cmd
Linecount : 38734
生成了两个文件，ls -lrt
-rw-r----- 1 oracle oinstall 7890011 Mar 10 14:25 restore-perm-Thu-Mar-10-14-25-31-2016.cmd
-rw-r----- 1 oracle oinstall 4061205 Mar 10 14:25 permission-Thu-Mar-10-14-25-31-2016
其中permission*开头的是/oracle/app/oracle/product/11.2.0/db_1目录及其下的所有子目录与文件列表，例如：
755 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1
640 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1/oraInst.loc
750 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1/root.sh
755 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1/EMStage
775 oracle oinstall /oracle/app/oracle/product/11.2.0/db_1/EMStage/PAF
。。。省略部分内容
restore*开头的包含了执行修改权限修复所需的脚本，例如：
chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1
chmod 755 /oracle/app/oracle/product/11.2.0/db_1
chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1/oraInst.loc
chmod 640 /oracle/app/oracle/product/11.2.0/db_1/oraInst.loc
chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1/root.sh
chmod 750 /oracle/app/oracle/product/11.2.0/db_1/root.sh
chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1/EMStage
chmod 755 /oracle/app/oracle/product/11.2.0/db_1/EMStage
chown oracle:oinstall /oracle/app/oracle/product/11.2.0/db_1/EMStage/PAF
chmod 775 /oracle/app/oracle/product/11.2.0/db_1/EMStage/PAF
。。。省略部分内容
抓取$GRID_HOME下所有目录与文件的属主、权限，必须使用root用户执行
./permission.pl /oracle/app/grid/product/11.2.0/grid_1
Following log files are generated
logfile : permission-Thu-Mar-10-14-21-28-2016
Command file : restore-perm-Thu-Mar-10-14-21-28-2016.cmd
Linecount : 60115
结果也生成了两个文件
ls -lrt
-rw-r----- 1 root system 13372037 Mar 10 14:24 restore-perm-Thu-Mar-10-14-24-03-2016.cmd
-rw-r----- 1 root system 6805988 Mar 10 14:24 permission-Thu-Mar-10-14-24-03-2016
在目标主机上执行restore*开头的两个脚本，root用户执行
将restore*脚本复制到目标主机后，执行
chmod u+x restore-perm-Thu-Mar-10-14-25-31-2016.cmd restore-perm-Thu-Mar-10-14-24-03-2016.cmd
./restore-perm-Thu-Mar-10-14-25-31-2016.cmd
./restore-perm-Thu-Mar-10-14-24-03-2016.cmd
总结：
在安装有GI的环境下，权限、属主是严格被设定的，任何对于它们的错误修改容易引发一系列的问题，而且这些问题往往都很诡异很难按照常规的思路去诊断。万一权限或属主被修改了可以通过rootcrs.pl -init及permission.pl进行修复，rootcrs.pl –init仅修复GI的核心目录，所以其修复速度较快，如果遇到GI无法启动的问题，建议首选这种方法以使GI能够快速启动，但其缺点在于无法全量的进行修复，GI虽然正常了，并不能保证之后的运行过程中不出现这样那样的问题，这时就需要permission.pl出场了，permission.pl的运行模式决定了源库(权限正确的库)与目标库(权限错误的库)间的软件版本尽可能的一致，所以源库一定要选好，否则问题会更糟，另外如果源、目标两个库的安装目录不一样还需要对permission*脚本作调整后再执行。
补充说明一点rootcrs.pl –init是在PSU>11.2.0.3.6下执行的，如果PSU