Monthly Archives: July 2026

[INS-30515] Insufficient space available in the selected disks

Posted on by
Reply

by Brian Fitzgerald

Introduction

This article covers “[INS-30515] Insufficient space available in the selected disks” during grid launch.

System

Installing Oracle Clusterware 19c on top of Red Hat Linux.

Installation notes

In this article, the grid owner is oracle, group dba. The grid home is /u01/app/oracle_grid/product/1930/grid. Oracle base is /u01/app/oracle

The error

You run gridSetup.sh as oracle and you see this error:

Launching Oracle Grid Infrastructure Setup Wizard... 
[FATAL] [INS-30508] Invalid ASM disks. 
 CAUSE: The disks [ORCL:ORA_ASM_GRID1_03, ORCL:ORA_ASM_GRID1_02, ORCL:ORA_ASM_GRID1_01] were not valid. 
 ACTION: Please choose or enter valid ASM disks. 
 [FATAL] [INS-30515] Insufficient space available in the selected disks. 
 CAUSE: Insufficient space available in the selected Disks. At least, 8 MB of free space is required. 
 ACTION: Choose additional disks such that the total size should be at least 8 MB.

The cause is almost never insufficient space. Read on.

Logs

In /u01/app/oracle_grid/product/1930/grid/cfgtoollogs/oui/GridSetupActions2026-07-28_03-40-30PM:

... Executing ... kfod ...
INFO: [Jul 28, 2026 3:40:33 PM] Parsing Error 49802 initializing ADR at /u01/app/oracle 
INFO: [Jul 28, 2026 3:40:33 PM] Parsing ERROR!!! could not initialize the diag context

The cause

A tool can’t run under the oracle account because the log directory is owned by root.

drwxr-x---. 3 root root 27 Jul 29 20:05 /u01/app/oracle/diag/kfod

The log directory is owned by root because the tool previously ran as root and created a root-owned log directory. kfod ran during troubleshooting or a previous gridSetup attempt.

Later, gridSetup.sh ran as oracle. gridSetup.sh called kfod, which failed because it could not create a log file.

The fix

chown -R oracle:dba /u01/app/oracle/diag

gridSetup.sh ran fine immediately after this fix.

Not the cause

None of these was the cause here; any of them can be:

  • Disks too small
  • Disk ownership
  • Disk not initialized
  • Re-used disk. Disk not clean.
  • ASM search string
  • asmlib filtering
  • selinux
  • udev rules
  • kfod reset disk ownership
  • /tmp mounted noexec
  • NAS files not zero-padded
  • multipath setup

Research

If you reached this article by searching for “[INS-30515] Insufficient space available in the selected disks”, consider that there are over 15 articles that address this message. Few of those articles reach a conclusion.

The reason for the proliferation of articles is the prevalence of the failure itself. The reason why few articles document a solution is, first, the difficulty of finding one, and second, the needlessness of the knowledge: Once solved, the knowledge is needless to the discoverer. The article is for the next person.

Error handling

In many Oracle software modules, the error message matches the purpose of the module. If the purpose is to check disk space, then for any failure, the message says the same thing about disk space.  “[INS-30515] Insufficient space available in the selected disks”.

When I write code, I handle errors differently. In fact, I rarely handle errors at all. I simply make sure that any failure causes the script to stop and display its error message unfiltered. I rarely write try – catch blocks. My functions do not return null; they throw an exception (which, as I said, I don’t catch).

I get a lot of pushback on this. The counterargument goes that if there is an error, it is imperative that we write code that handles it. The problem is that people sometimes write only the catching part and save the correct handling part for later. If later never arrives, the error gets absorbed. In gridSetup.sh, the coder put “try” around everything and wrote one error message.

“try – catch” is meant in the figurative sense: the implementation depends on the language. Code intercepts a useful error message and replaces it with an unhelpful one.

The Unix Philosophy

The Unix Philosophy states principles of clean, capable software design. Among those principles is the Rule of Repair: “Repair what you can — but when you must fail, fail noisily and as soon as possible.” Code should fail in a manner that is easy to localize and diagnose. Refer to The Art of Unix Programming (2003) by Eric Raymond.

If you are not sold on the Unix philosophy, consider that the writer of gridSetup.sh was not sold on it either.

Conclusion

Oracle software error handling follows a defective pattern: gridSetup.sh is not the only example. Oracle software prints a misleading error message. Pertinent facts are in the logs, GridSetupActions.log in this case.

“Successful discovery of 0 disks” during Oracle cluster launch

Posted on by
Reply

by Brian Fitzgerald

Introduction

This article covers “Successful discovery of 0 disks” errors during grid launch. I know of three fixes.

System

Installing Oracle Clusterware 19c on top of ASMLIB 3.0 on Red Hat Linux.

Installation notes

In this article, the grid owner is oracle, group dba. The ASM disks are named ORA_ASM_GRID1_01, and so on, and you can refer to them that way:

/dev/disk/by-label/ORA_ASM_GRID1_01

and so on.

The error

After running gridSetup.sh as the grid owner, the DBA runs root.sh. On the first node, the error happens in step 16 of 19: ‘InitConfig’. On the second node, the failure appears at step 17 of 19: ‘StartCluster’. root.sh runs for 10 minutes and fails.

The root.sh refers to a log such as $ORACLE_HOME/install/root_$(hostname)$(date…).log, which begins:

Performing root user operation.

On the first node, the error is:

[FATAL] [DBT-30002] Disk group GRID1 creation failed.
ORA-15018: diskgroup cannot be created
ORA-15031: disk specification 'ORCL:ORA_ASM_GRID1_01' matches no disks
ORA-15031: disk specification 'ORCL:ORA_ASM_GRID1_02' matches no disks
ORA-15031: disk specification 'ORCL:ORA_ASM_GRID1_03' matches no disks

And on the second, you will find:

CRS-1705: Found 0 configured voting files but 1 voting files are required, terminating to ensure data integrity; details at (:CSSNM00065:) in /u01/app/oracle/diag/crs/<hostname>/crs/trace/ocssd.trc
CRS-2883: Resource 'ora.cssd' failed during Clusterware stack start.

ocssd.trc shows this message repeating for 10 minutes:

2026-07-15 10:23:54.351 : CSSD:1956423232: [ INFO] clssnmvDiskVerify: Successful discovery of 0 disks
2026-07-15 10:23:54.351 : CSSD:1956423232: [ INFO] clssnmCompleteInitVFDiscovery: Completing initial voting file discovery
2026-07-15 10:23:54.351 : CSSD:1956423232: [ INFO] clssnmvFindInitialConfigs: No voting files found
2026-07-15 10:23:54.353 : CSSD:1956423232: [ INFO] (:CSSNM00070:)clssnmCompleteInitVFDiscovery: Voting file not found. Retrying discovery in 15 seconds

Cause

The error appears if you have disabled asmlib filtering. Linux tends to change disk device ownership to root. Disabling filtering breaks a handler that tends to change disk device ownership back to oracle.

Oracle ships a per-event ownership handler (/usr/lib/oracleasm/iofilter-asm-disk-addmap, invoked by udev). When filtering is disabled, the handler exits before reaching its chown. With no rule asserting ownership, udev’s defaults set devices to root:disk whenever device nodes are reprocessed or recreated.

1. Workaround while root.sh is running

While root.sh is running, you have plenty of time to correct the underlying issue. Run:

ls -Ll /dev/disk/by-label/ORA_ASM_GRID1_0?

If you see root ownership

brw-rw----. 1 root   disk 8, 193 Jul 26 12:52 /dev/disk/by-label/ORA_ASM_GRID1_01

and so on, then simply run

chown oracle:dba /dev/disk/by-label/ORA_ASM_GRID1_0?

root.sh will resume and run to successful completion. Finish the gridSetup.sh installation. Chances are, the system will give you no trouble after that, even if you reboot the cluster.

2. Enable filtering

crsctl stop crs
or
crsctl stop has
oracleasm configure -f y
Configuration changes only come into effect after the 
Oracle ASM system service is restarted. 
Please run 'systemctl restart oracleasm' after making changes.
systemctl restart oracleasm
crsctl start crs
or
crsctl start has

Caution: my own testing shows unless you restart ASM, filtering will not protect your data as it is designed to.

3. udev rule

If you have decided not to implement filtering, then install this file at /etc/udev/rules.d/99-oracle-asm.rules. That way, whenever something else changes device ownership to root, the rule will change it back. “Something else” is any non-Oracle tool, such as partprobe.

# Brian Fitzgerald
# 2026-07-22

# RHEL 9 / ASMLIB 3 / grid 19c workaround for gridSetup.sh, root.sh
# failing on node a, step 16 'InitConfig', and on node b, step 17, 'StartCluster'.
# ocssd.trc was showing "clssnmvDiskVerify: Successful discovery of 0 disks"
#
# The rule fires whenever a disk is discovered, or is written to and closed.
#
# Firing condition:
# 1. block device
# 2. labeled with oracleasm createdisk

# Action:
# 1. Change the ownership to oracle:dba
# 2. Change the mode to 0660

SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="oracleasm", OWNER="oracle", GROUP="dba", MODE="0660"

Run:

udevadm control --reload-rules
udevadm trigger --subsystem-match=block

Conclusion

The launch failure is a configuration interaction, and any of the three fixes above closes it permanently.