This content has been marked as final. Show 5 replies
OK, let's take a closer, more methodical look
Who am I?
where am I?
oracle:+ASM$ id uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),54322(dba)
What are the permissions on the directory I want to rename?
oracle:+ASM$ pwd /u01/app/oracle/product/188.8.131.52/grid
Everything looks good. I'm 'oracle', I own the directory I want to rename, and there are no other directories with a variant of that name.
oracle:+ASM$ ls -l |grep OP drwxr-xr-x 8 oracle oinstall 4096 Jul 24 14:15 OPatch
Let's try it
Ok, what are the permission on the parent to this directory?
oracle:+ASM$ mv OPatch OPatch.old mv: cannot move `OPatch' to `OPatch.old': Permission denied
oracle:+ASM$ ls -l /u01/app/oracle/product/184.108.40.206 total 4 drwxr-x--- 67 root oinstall 4096 Jul 24 14:26 grid
And how did that get to be owned by root? Investigation continues, but I suspect one of the root* scripts during one of the installation/upgrades.
Film at eleven ..
Just as a final follow-up, I was doing this on a virtual system, in prep for doing it on a live system. I started by rebuilding from the initial install of Oracle Grid Infrastructure 220.127.116.11, and watching as I built it up from there. It turns out that the directory in question .. the one owned by root, is the ORACLE_HOME directory created for the installation of the upgrade of Grid to 18.104.22.168 (out of place upgrade). So it was created with the wrong ownership. And seeing that, I double checked the live system I need to upgrade, and it has the same issue.
Taking this discussion to the ASM forum.
Thanks for the feedback.
As you have discovered, directory maintenance operations such as:
rely on your permissions on the directory containing the object, not those of the object itself. Get these permissions like this:
However, as a courtesy of dubious merit, the GNU version of these tools check the writable status of the object as well so they can complain if you try this:
$ ls -ld .
See, strictly-speaking rm(1) should have removed the file silently, since I have write permissions for foo's resident directory. The original rm(1) did in fact perform the delete.
$ ls -ld . drwx------. 79 tommy tommy 12288 Jul 28 09:32 . $ touch foo $ chmod foo 0444 foo -r--r--r--. 1 tommy tommy 12288 Jul 28 09:33 foo $ rm foo rm: remove write-protected regular empty file `foo'?
Just for fun, try this:
We create a r/w object foo, set the directory to be read-only and then try to delete it. And then try very hard to delete it. And then try even harder.
$ mkdir foo $ cd foo $ date >now $ chmod 0555 . $ rm now $ rm -f now $ cd .. $ rm -rf foo
So, the rule is that permissions for the directory rule.