January 27, 2020 2:14 pm
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.
Posted by Mariami Kupatadze
Categories: OPatch
Tags: error code 73, opatch apply, oui-patch.xml, Permission denied
Mobile Site | Full Site
Get a free blog at WordPress.com Theme: WordPress Mobile Edition by Alex King.
I was just faced same
issue during the upgrade patching.
By Alok on January 27, 2020 at 9:41 pm
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. 🙂
By Ernest Kalwa on February 8, 2020 at 1:15 pm
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.
By ADam on February 18, 2020 at 6:29 pm
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.
By Ernest Kalwa on February 26, 2020 at 4:14 pm
Thank you! Great comment!!
By Mariami Kupatadze on February 26, 2020 at 7:19 pm
Hi Mariami, Awesome post, it saved me as well
By Joe Glad on July 30, 2020 at 3:38 pm
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)
By ERNEST KALWA on July 31, 2020 at 11:05 am
Thanks for the great post, Mariami! You saved my day 🙂
By Azer on January 26, 2021 at 6:22 pm