opatch apply failed: /u01/app/oraInventory/ContentsXML/oui-patch.xml (Permission denied)
January 27, 2020 8 Comments
Problem:
In the two-node cluster. I applied patch 29342099 on the 1st node successfully. But the patch failed on the 2nd node:
[oracle@stbyrac2 29342099]$ $ORACLE_HOME/OPatch/opatch apply ... Applying interim patch '29342099' to OH '/u01/app/oracle/product/19.3.0/dbhome_1' Patching component oracle.rdbms, 19.0.0.0.0… Patching component oracle.rdbms.rman, 19.0.0.0.0… Patching component oracle.rdbms.rsf, 19.0.0.0.0… ApplySession failed in system modification phase… 'ApplySession::apply failed: java.io.IOException: oracle.sysman.oui.patch.PatchException: java.io.FileNotFoundException: /u01/app/oraInventory/ContentsXML/oui-patch.xml (Permission denied)'
The patch failed in a bad phase, after failure while I was trying to check inventory on that node I was getting:
[oracle@stbyrac2 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory -detail ... Inventory load failed… OPatch cannot load inventory for the given Oracle Home. LsInventorySession failed: Unable to create patchObject Possible causes are: ORACLE_HOME/inventory/oneoffs/29342099 is corrupted. java.lang.RuntimeException: No Patch exists,Please check.
Inventory knew about patch 29342099 but $ORACLE_HOME/inventory/oneoffs/29342099 did not exist.
I decided to copy folder from 1st node (where patch was successful):
[oracle@stbyrac1 ~]$ scp -r $ORACLE_HOME/inventory/oneoffs/29342099 stbyrac2:$ORACLE_HOME/inventory/oneoffs/
After that listing inventory was successful. And patch seemed to be part of the inventory. I tried to rollback it, which failed with the same permission error `/u01/app/oraInventory/ContentsXML/oui-patch.xml (Permission denied)`
Solution:
Check permissions on oui-patch.xml file on both nodes:
[oracle@primrac1 ~]$ ls -la /u01/app/oraInventory/ContentsXML/oui-patch.xml -rw-rw---- 1 grid oinstall 174 Oct 9 20:46 /u01/app/oraInventory/ContentsXML/oui-patch.xml [oracle@primrac1 ~]$ ssh primrac2 ls -la /u01/app/oraInventory/ContentsXML/oui-patch.xml -rw-r--r-- 1 grid oinstall 174 Sep 29 19:38 /u01/app/oraInventory/ContentsXML/oui-patch.xml
They are different. Modify permission of that file to 660:
[root@stbyrac2 ContentsXML]# chmod 660 oui-patch.xml
Rollback and reapply patch:
[oracle@stbyrac2 29342099]$ $ORACLE_HOME/OPatch/opatch apply ... Applying interim patch '29342099' to OH '/u01/app/oracle/product/19.3.0/dbhome_1' Patching component oracle.rdbms, 19.0.0.0.0… Patching component oracle.rdbms.rman, 19.0.0.0.0… Patching component oracle.rdbms.rsf, 19.0.0.0.0… Patch 29342099 successfully applied. Log file location: /u01/app/oracle/product/19.3.0/dbhome_1/cfgtoollogs/opatch/opatch2020-01-27_13-55-44PM_1.log OPatch succeeded.
About Mariami Kupatadze
DBA Knowledge Base 
I was just faced same
issue during the upgrade patching.
Hey Mariami, thanks for posting this issue and solution! I just ran into the exact same issue, and your steps above resolved it. Whew! I also submitted a Service Request with Oracle Support, and have referenced your posting at this link. Hopefully they’ll publish it as a BUG! I couldn’t find any exact matching issue or bug report in MOS, but a Google search for “oui_patch.xml permission denied” came up with your posting first! I’ll try connecting with you on LinkedIn. 🙂
i have faced this issue to when applying 30501910, but did what you did, but after all the clusterware status was in ROLLING UPGRADE mode, more over when i decided to rollback the patch opatchauto was complain:
Patch: /share/19.0/30501910/30489227
Reason: Patch /share/19.0/30501910/30489227 is not applied as part of bundle patch 30501910
i am afraid it is not a solution or workaround, Oracle have to fix the bug.
Update – FYI – I submitted a Service Request with MOS, and as a result.
Oracle finally registered this as a BUG!
—————————————————————————–
Root Cause Analysis:
——————————————————————————
During 19.x GI installation, the file ‘oui-patch.xml’ will be created under the central inventory directory on the OUI node (node where gridSetup.sh was invoked) but not on the other nodes.
This is due to below code defects :
BUG 29859410 [https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=29859410] https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=29859410 – OPATCHAUTO_194:OPATCHAUTO FAILED DUE TO WRONG PERMISSION OF OUI-PATCH.XML IN DIFFERENT USER ENV
BUG 29852638 [https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=29852638] https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=29852638 – OPATCHAUTO_194:OPATCHAUTO RESUME FAILED WITH UNABLE TO CREATE PATCHOBJECT
——————————————————————————
The workaround is :
——————————————————————————
To have the OUI-PATCH.XML file copied in the central inventory of non OUI node from the OUI node with permission for GI Home owner before patching session is initiated.
Thank you! Great comment!!
Hi Mariami, Awesome post, it saved me as well
MOS created an official Support Note on MOS on March 16, 2020 about this after I submitted my Service Request with them: opatchauto apply Results java.io.FileNotFoundException: /ContentsXML/oui-patch.xml (Permission denied) Error in Non-OUI Nodes (Doc ID 2582139.1)
Thanks for the great post, Mariami! You saved my day 🙂