Troubleshooting Missing ASM Disk Groups During Oracle Database Creation with DBCA - A Step-by-Step Analysis and Solution

When creating a new Oracle database using the Database Configuration Assistant (DBCA), users might encounter a frustrating issue where available ASM disk groups are not displayed. This prevents the selection of storage locations for database files and halts the creation process. This article outlines a detailed troubleshooting process and solution based on a real-world scenario.
Initial Signs of the Problem - DBCA Logs
The first step in diagnosing such issues is always to analyze the logs generated by DBCA. The location of these logs can vary depending on the system, but they are typically found under the cfgtoollogs/dbca
directory within the Oracle installation home. In our case, the path to the logs was:
/u01/app/oracle/cfgtoollogs/dbca
Analysis of the DBCA logs revealed the following entries:
[AWT-EventQueue-0] [ 2025-05-01 14:12:43.355 EDT ] [OsUtilsBase.execProgInheritAddEnvNReturnOutput:2268] Exec prog return code: 1
[AWT-EventQueue-0] [ 2025-05-01 14:12:43.355 EDT ] [KfodUtil.kfodOutput:393] Kfod result
KFOD-00300: OCI error [-1] [OCI error] [ORA-12547: TNS:lost contact
] [12547]
KFOD-00105: Could not open pfile 'init@.ora'
INFO: May 01, 2025 2:12:43 PM oracle.assistants.common.lib.asm.ASMInfo load
INFO: Loading the diskgroups. exception using kfod
KFOD-00300: OCI error [-1] [OCI error] [ORA-12547: TNS:lost contact
] [12547]
KFOD-00105: Could not open pfile 'init@.ora'
INFO: May 01, 2025 2:12:43 PM oracle.assistants.common.view.DiskGroupTableModel setDiskGroups
INFO: Empty diskGroup list is specified
INFO: May 01, 2025 2:12:51 PM oracle.install.commons.util.Application pause
INFO: Pause Database Configuration Assistant
INFO: May 01, 2025 2:12:53 PM oracle.install.commons.util.Application pause
INFO: Resume Database Configuration Assistant
INFO: May 01, 2025 2:12:53 PM oracle.install.commons.util.ExitStatusSet add
INFO: Adding ExitStatus USER_CANCELLED_INSTALL to the exit status set
This log excerpt points to a network connectivity issue with the ASM instance, as indicated by the ORA-12547: TNS:lost contact
error. Additionally, the attempt to open the initialization parameter file 'init@.ora'
suggests an attempt to connect to a remote ASM instance. The failed connection results in the inability to load information about the disk groups.
Further analysis focused on the kfod
utility, which DBCA uses to interact with ASM.
Step 1: Verifying the kfod
Executable
The initial suspicion fell on the kfod
executable itself, typically located in the Grid Infrastructure $ORACLE_HOME/bin
directory. In a clustered environment, this file was checked on all nodes. On one of the nodes (node03-7
), the listing of the kfod
file appeared as follows:
-rwxrwxr-x. 1 grid oinstall 0 04-25 11:44 kfod
The file size of 0 bytes clearly indicated that the file was corrupted. The issue was temporarily resolved by copying a working version of the kfod
file from another node.
Step 2: Further Diagnosis using strace
After repairing the corrupted kfod
executable, the problem persisted. To obtain more detailed information about the kfod
utility's operation, the strace
command was used:
strace kfod op=groups verbose=true
Analysis of the strace
output revealed permission-related errors when accessing the GPNP wallet directory:
stat("/u01/app/19.0.0/grid/gpnp/node03-7/wallets/peer/ ", 0x7ffc58cfc150) = -1 EACCES (Permission denied)
lstat("/u01/app/19.0.0/grid/gpnp/node03-7/wallets/peer/cwallet.sso", 0x7ffc58cfc3c0) = -1 EACCES (Permission denied)
In response to these errors, appropriate permissions were added to the directory:
/u01/app/19.0.0/grid/gpnp/node03-7/wallets/peer/
Step 3: Direct Analysis of kfod
Logs
As the problem continued, the next step involved analyzing the dedicated logs of the kfod
utility, located in the following directory:
/u01/app/oracle/diag/kfod/node01-7/kfod/trace
Analysis of these logs revealed the following critical entry:
************************************************************
Fatal NI connect error 12547, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=beq)(PROGRAM=/u01/app/19.0.0/grid/bin/oracle)(ARGV0=oracle+ASM1_kfod)(ENVS='ORACLE_HOME=/u01/app/19.0.0/grid,ORACLE_SID=+ASM1,ORA_SERVER_BROKER_MODE=NONE')(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(ORACLE_HOME=/u01/app/19.0.0/grid)(SID=+ASM1)(CID=(PROGRAM=kfod.bin)(HOST=node01-7)(USER=oracle)))(SECURITY=(AUTHENTICATION_SERVICE=beq))(enable=setuser))
VERSION INFORMATION:
TNS for Linux: Version 19.0.0.0.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production
Version 19.3.0.0.0
Time: 03-MAY-2025 08:20:27
Tracing not turned on.
Tns error struct:
ns main err code: 12547
TNS-12547: TNS:lost contact
ns secondary err code: 12560
nt main err code: 517
TNS-00517: Lost contact
nt secondary err code: 32
nt OS err code: 0
KFOD-00300: OCI error [-1] [OCI error] [ORA-12547: TNS:lost contact
] [12547]
This log directly indicated a problem with the local connection (BEQ protocol) to the ASM instance (+ASM1). Suspecting an issue with the permissions of the Oracle executable used for the BEQ connection (/u01/app/19.0.0/grid/bin/oracle
), an attempt was made to change its permissions:
chmod 6751 /u01/app/19.0.0/grid/bin/oracle
Missing setuid permissions for the Oracle binary suggested that the BEQ protocol requires the setuid (SUID) bit to be set on this file.
Solution
Setting the permissions 6751
on the file /u01/app/19.0.0/grid/bin/oracle
resolved the issue. After this change, the DBCA utility was able to connect to the ASM instance correctly and display the available disk groups, allowing the database creation process to proceed.
Conclusion
This troubleshooting process highlights the importance of a systematic approach when dealing with Oracle software issues. Analyzing various logs, understanding the functionality of key utilities (such as kfod
and strace
), and having knowledge of connection protocol specifics (like BEQ and its permission requirements) are crucial for effectively identifying and resolving problems. In the future, it is advisable to pay close attention to the permissions of Oracle executables, especially in environments where local connections to instances are utilized.
![[photo]](/media/images/profile_pic/IMG-20181130-WA0003.jpg)
Aleksander Legkoszkur
Database Administrator
A technology fan who likes to stayes at night until he finds a solution. A small handyman who tries to fix everything he can get his hands on. Worked with technologies like:
Windows Server / Linux
Oracle Cloud
Python / T-SQL / PL-SQL / HTML / CSS
Oracle / SQL Server
and knows how to deal with hardware repairment.