When adding a new node to an Oracle RAC cluster, the addnode.sh process can sometimes fail because of permission issues inside the Grid Infrastructure home.

Recently, while adding a new RAC node, we encountered the following error:

[FATAL] [INS-32156] Installer has detected that there are non-readable files in oracle home.

The interesting part was that the files reported by the installer were under the AHF (Autonomous Health Framework) directory inside the Grid Infrastructure home.

This blog explains the issue and the solution.

---

Environment

The existing RAC environment had two nodes, and we were adding a third node:

Existing Nodes
--------------
dm01
dm02

New Node
--------
dm03

New VIP
-------
db03-vip

The Grid Infrastructure home was similar to:

/u01/app/19.0.0.0/grid

AHF was located under:

/u01/app/19.0.0.0/grid/suptools/oracle.ahf

---

Starting the RAC Node Addition

We started the node addition using addnode.sh:

./addnode.sh -silent \
"CLUSTER_NEW_NODES={dm03}" \
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={db03-vip}" \
"CLUSTER_NEW_NODE_ROLES={hub}"

However, the installer stopped with:

[FATAL] [INS-32156] Installer has detected that there are non-readable files in oracle home.

The installer then listed several files that it could not read.

For example:

suptools/oracle.ahf/ahf/scripts/ahf_upload_https.pl
suptools/oracle.ahf/ahf/scripts/ahf_crs.sh
suptools/oracle.ahf/ahf/scripts/ahf_error.sh
suptools/oracle.ahf/ahf/bin/uninstallahf.sh
suptools/oracle.ahf/ahf/bin/iwareport
suptools/oracle.ahf/ahf/bin/installAHF.pl
suptools/oracle.ahf/ahf/bin/ahf
suptools/oracle.ahf/ahf/bin/balance
suptools/oracle.ahf/ahf/messages/tfamessages.json
suptools/oracle.ahf/common/jlib
suptools/oracle.ahf/tfa
suptools/oracle.ahf/analyzer
suptools/oracle.ahf/iwa
suptools/oracle.ahf/jre
suptools/oracle.ahf/rpms

The installer also gave us the required action:

ACTION: Ensure the above files are readable by grid.

---

Understanding the Problem

The suptools directory mentioned in the error was part of the Grid Infrastructure home:

<GI_HOME>/suptools/oracle.ahf

The problem was that some files and directories inside AHF did not provide sufficient access to the grid user.

Even though the main Grid Infrastructure installation was working correctly, addnode.sh performs validation against the Oracle Home. When it encountered files that the grid user could not read, the installer stopped with:

INS-32156

So the first step was to correct the permissions.

---

Check the AHF Permissions

Before making any changes, check the AHF directory:

ls -ld <GI_HOME>/suptools/oracle.ahf

For example:

ls -ld /u01/app/19.0.0.0/grid/suptools/oracle.ahf

You can also check the ACL:

getfacl /u01/app/19.0.0.0/grid/suptools/oracle.ahf

If the grid user does not have the required read and directory traversal permissions, the node addition can fail.

---

Grant ACL Permissions to grid

The recommended fix was to grant the grid user read and execute/traverse permissions across the AHF directory.

Switch to the root user.

Set the AHF location:

export AHF_HOME=<GI_HOME>/suptools/oracle.ahf

For example:

export AHF_HOME=/u01/app/19.0.0.0/grid/suptools/oracle.ahf

Then apply the ACL recursively:

setfacl -R -m u:grid:rX "$AHF_HOME"

Here:

-R

applies the ACL recursively.

And:

u:grid:rX

grants the grid user:

• r — read permission
• X — execute/traverse permission where applicable

This is important because directories require execute permission for traversal.

---

Verify the ACL

After applying the ACL, check the permissions:

getfacl "$AHF_HOME"

You should see an entry similar to:

user:grid:r-x

You can also check one of the files reported by the installer:

getfacl "$AHF_HOME/ahf/bin/ahf"

The purpose is to confirm that the grid user can access the required AHF files.

---

Check for the AHF Symbolic Link

During the troubleshooting process, we also found an AHF symbolic link under the Grid Infrastructure home.

It looked similar to:

<GI_HOME>/oracle.ahf -> /opt/oracle.ahf/

For example:

ls -l /u01/app/19.0.0.0/grid/oracle.ahf

The output was similar to:

oracle.ahf -> /opt/oracle.ahf/

This symbolic link was not required for the node-addition procedure.

The actual AHF directory being checked by the installer was:

<GI_HOME>/suptools/oracle.ahf

Therefore, after confirming that oracle.ahf was only a symbolic link, we removed the link.

---

Remove the Symbolic Link Using unlink

Before removing anything, always verify that the path is actually a symbolic link:

ls -l <GI_HOME>/oracle.ahf

If the output shows:

oracle.ahf -> /opt/oracle.ahf/

we can remove the symbolic link using unlink.

As root:

unlink <GI_HOME>/oracle.ahf

For example:

unlink /u01/app/19.0.0.0/grid/oracle.ahf

The advantage of using unlink here is that it clearly removes the symbolic link itself.

It does not remove the target directory:

/opt/oracle.ahf/

So the target AHF installation remains untouched.

After removing the link, verify:

ls -l /u01/app/19.0.0.0/grid/

Also confirm that the actual AHF directory still exists:

ls -ld /u01/app/19.0.0.0/grid/suptools/oracle.ahf

---

Retry addnode.sh

Once the ACL permissions have been corrected and the unnecessary symbolic link has been removed, retry the RAC node addition.

From the Grid Infrastructure home:

./addnode.sh -silent \
"CLUSTER_NEW_NODES={dm03}" \
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={db03-vip}" \
"CLUSTER_NEW_NODE_ROLES={hub}"

The installer can now validate the Oracle Home without encountering the previous AHF permission problem.

---

Complete Troubleshooting Procedure

For quick reference, the complete solution is:

1. Login as root

su -

2. Define AHF_HOME

export AHF_HOME=<GI_HOME>/suptools/oracle.ahf

Example:

export AHF_HOME=/u01/app/19.0.0.0/grid/suptools/oracle.ahf

3. Grant ACL permissions

setfacl -R -m u:grid:rX "$AHF_HOME"

4. Verify permissions

getfacl "$AHF_HOME"

5. Check the AHF symbolic link

ls -l <GI_HOME>/oracle.ahf

6. Remove the unnecessary symbolic link

Only if it is confirmed to be the unwanted symlink:

unlink <GI_HOME>/oracle.ahf

Example:

unlink /u01/app/19.0.0.0/grid/oracle.ahf

7. Verify the actual AHF directory

ls -ld <GI_HOME>/suptools/oracle.ahf

8. Retry the node addition

su - grid 
--
./addnode.sh -silent \
"CLUSTER_NEW_NODES={drracx9dbadm03}" \
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={drracx9db03-vip}" \
"CLUSTER_NEW_NODE_ROLES={hub}"

---

Final Thoughts

The INS-32156 error during an Oracle RAC node addition can initially look like a problem with the Grid Infrastructure installation itself.

In our case, the actual issue was related to AHF files inside the Grid Infrastructure home that were not sufficiently readable by the grid user.

The fix was straightforward:

export AHF_HOME=<GI_HOME>/suptools/oracle.ahf

setfacl -R -m u:grid:rX "$AHF_HOME"

We also identified an unnecessary symbolic link:

<GI_HOME>/oracle.ahf -> /opt/oracle.ahf/

and removed it safely using:

unlink <GI_HOME>/oracle.ahf

After these changes, the RAC node-addition process could be initiated again.

The main lesson is that when addnode.sh reports INS-32156, don’t only check the core Grid Infrastructure binaries. Check the complete Oracle Home, including AHF directories, permissions, ACLs, and unexpected symbolic links.