WARNING: [May 18, 2026 1:26:22 PM] Verification of target environment returned with errors. WARNING: [May 18, 2026 1:26:22 PM] [WARNING] [INS-13001] Oracle Database is not supported on this operating system. Installer will not perform prerequisite checks on the system.
CAUSE: This operating system may not have been in the certified list at the time of the release of this software.
ACTION: Refer to My Oracle Support portal for the latest certification information for this operating system. Proceed with the installation if the operating system has been certified after the release of this software..
 |
Checking /etc/redhat-release and /etc/os-release on both machines confirms they are both pristine, matching copies of RHEL 9.6. So why is one failing while the other succeeds?
[oracle@SERVER1]$cat /etc/redhat-release
Red Hat Enterprise Linux release 9.6 (Plow)
[oracle@SERVER1]$cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.6 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.6"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.6 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
...etc
[oracle@SERVER2]$cat /etc/redhat-release
Red Hat Enterprise Linux release 9.6 (Plow)
Red Hat Enterprise Linux release 9.6 (Plow)
[oracle@SERVER1]$cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.6 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.6"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.6 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
...etc
[oracle@SERVER2]$cat /etc/redhat-release
Red Hat Enterprise Linux release 9.6 (Plow)
[oracle@SERVER2]$cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.6 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.6"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.6 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
...etc
We also did the research and found out that REHL9.6 is fully certified.
The answer usually isn't your OS version at all, it's OS security hardening policy. Here is why this happens and how to fix it in under two minutes.
The Secret Culprit: noexec on /tmp
During the initialization phase, the Oracle Universal Installer (OUI) extracts temporary architecture and OS-validation binaries into the system's /tmp directory and attempts to execute them.
On many production-hardened Linux servers, corporate security policies dictate that the /tmp partition must be mounted with the noexec flag. When the installer's background detection scripts get blocked from running, the OUI hits a generic failure and defaults to its catch-all warning: “OS not supported.”
How to Verify the Issue
Run the following command on both servers to check the mount permissions of your temporary directory:
$ mount | grep /tmp
If the failing server outputs noexec inside the configuration brackets, you have officially found the culprit.
The Solution: Redirect Oracle's Temp Directory or mount the /tmp with "exec"
You don’t need to ask your security team to compromise server hardening rules by remounting /tmp. Instead, you can simply instruct the Oracle installer to use a directory where the oracle user naturally has execution permission, such as their own home directory.
Log into your failing server as the oracle installation user, and run these commands in the terminal before launching the installer:
# 1. Create a dedicated temp directory in the oracle home folder
$ mkdir -p /home/oracle/oratmp
# 2. Redirect the installer's environment variables
$export TMP=/home/oracle/oratmp
$export TMPDIR=/home/oracle/oratmp
# 3. Launch the installer from this same terminal session
$./runInstaller
By changing these variables, the installer bypasses /tmp entirely, successfully reads your RHEL 9 configuration from /home/oracle/oratmp, and allows the setup to proceed seamlessly.
Thanks & Regards
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
...etc
We also did the research and found out that REHL9.6 is fully certified.
The answer usually isn't your OS version at all, it's OS security hardening policy. Here is why this happens and how to fix it in under two minutes.
The Secret Culprit: noexec on /tmp
During the initialization phase, the Oracle Universal Installer (OUI) extracts temporary architecture and OS-validation binaries into the system's /tmp directory and attempts to execute them.
On many production-hardened Linux servers, corporate security policies dictate that the /tmp partition must be mounted with the noexec flag. When the installer's background detection scripts get blocked from running, the OUI hits a generic failure and defaults to its catch-all warning: “OS not supported.”
How to Verify the Issue
Run the following command on both servers to check the mount permissions of your temporary directory:
$ mount | grep /tmp
If the failing server outputs noexec inside the configuration brackets, you have officially found the culprit.
The Solution: Redirect Oracle's Temp Directory or mount the /tmp with "exec"
You don’t need to ask your security team to compromise server hardening rules by remounting /tmp. Instead, you can simply instruct the Oracle installer to use a directory where the oracle user naturally has execution permission, such as their own home directory.
Log into your failing server as the oracle installation user, and run these commands in the terminal before launching the installer:
# 1. Create a dedicated temp directory in the oracle home folder
$ mkdir -p /home/oracle/oratmp
# 2. Redirect the installer's environment variables
$export TMP=/home/oracle/oratmp
$export TMPDIR=/home/oracle/oratmp
# 3. Launch the installer from this same terminal session
$./runInstaller
By changing these variables, the installer bypasses /tmp entirely, successfully reads your RHEL 9 configuration from /home/oracle/oratmp, and allows the setup to proceed seamlessly.
Thanks & Regards
https://oracleracexpet.com
