This content has been marked as final. Show 5 replies
Perhaps you already have a file or directory named "OPatch.old" that is not owned by "oracle"?1 person found this helpful
For do this operation you should have permissions write to current directory or to OPatch.old in case this directory olready present.
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/184.108.40.206/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/220.127.116.11 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 18.104.22.168, 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 22.214.171.124 (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.