Cloudera Docs

Cloudera Manager 7.11.3 Cumulative hotfix 16

Know more about the Cloudera Manager 7.11.3 cumulative hotfixes 16.

This cumulative hotfix was released on July 15, 2025.

New features and changed behavior for Cloudera Manager 7.11.3 CHF16 (version: 7.11.3.36-67636814):
Cgroup v2 support on RHEL 9 for Cloudera Manager 7.11.3 CHF16

Cloudera Manager now supports Cgroup v2. Cgroup v2 offers a unified hierarchy for managing system resources, making it simpler and more efficient compared to Cgroup v1. For more information, see Linux Control Groups (cgroups).

You must migrate from Cgroup v1 to cgroup v2 for managing the cluster resources using Cgroup v2 resource allocation configuration parameters. For information about migrating to Cgroup v2, see Migrating from Cgroup v1 to Cgroup v2.

OPSAPS-73498: Backport Cloudera Manager side Ranger-Trino integration changes
Trino plugin support in Ranger has been added.
OPSAPS-70457: Migrate Navigator Encrypt keys to Ranger KMS from KTS configured with HSM
Exporting Navigator Encrypt keys from KTS to Ranger KMS is already available. But if HSM is configured with KTS, this does not work as key's content does not contain the actual key material; it needs to be fetched from HSM first.

Condition has been added to check for HSM setup and accordingly publish a warning log stating Navigator Encrypt keys with HSM cannot be migrated, along with the document link for the steps to migrate.

Following are the list of known issues and their corresponding workarounds that are shipped for Cloudera Manager 7.11.3 CHF16 (version: 7.11.3.36-67636814):
ENGESC-30503, OPSAPS-74868: Cloudera Manager limited support for custom external repository requiring basic authentication
Current Cloudera Manager does not support custom external repository with basic authentication (the Cloudera Manager Wizard supports either HTTP (non-secured) repositories or usage of Cloudera https://archive.cloudera.com only). In case customers want to use a custom external repository with basic authentication, they might get errors.

The assumption is that you can access the external custom repository (such as Nexus or JFrog, or others) using LDAP credentials. In case an applicative user is used to fetch the external content (as done in Data Services with the docker imager repository), the customer should ensure that this applicative user is located under the user's base search path where the real users are being retrieved during LDAP authentication check (so the external repository will find it and will allow it to gain access for fetching the files).

Once done, you can use the current custom URL fields in the Cloudera Manager Wizard and enter the URL for the RPMs or parcels/other files in the format of "https://USERNAME:PASSWORD@server.example.com/XX".

While using the password, you are advised to use only the printable ASCII character range (excluding space), whereas in case of a special character (not letter/number) it can be replaced with HEX value (For example, you can replace Aa1234$ with Aa1234%24 as '%24' is translated into $ sign).

OPSAPS-74288: Alert publisher cannot send email alerts due to missing JAR
Alert publisher cannot send email alerts due to missing camel-attachments-3.14.9.jar in Cloudera Manager.

To resolve this issue temporarily, you must perform the following steps:

  1. SSH login into Cloudera Manager cluster.
  2. Manually add the camel-attachments-3.14.9.jar file into Cloudera Manager at /opt/cloudera/cm/lib/ directory.
  3. Restart the Cloudera Manager server by running the following command:
    sudo systemctl restart cloudera-scm-server
OPSAPS-60726: Newly saved parcel URLs are not showing up in the parcels page in the Cloudera Manager HA cluster.
To safely manage parcels in a Cloudera Manager HA environment, follow these steps:
  1. Shutdown the Passive Cloudera Manager Server.
  2. Add and manage the parcel as usual, as described in Install Parcels.
  3. Restart the Passive Cloudera Manager server after parcel operations are complete.
OPSAPS-73211: Cloudera Manager 7.11.3 does not clean up Python Path impacting Hue to start

When you upgrade from Cloudera Manager 7.7.1 or lower versions to Cloudera Manager 7.11.3 or higher versions with CDP Private Cloud Base 7.1.7.x Hue does not start because Cloudera Manager forces Hue to start with Python 3.8, and Hue needs Python 2.7.

The reason for this issue is because Cloudera Manager does not clean up the Python Path at any time, so when Hue tries to start the Python Path points to 3.8, which is not supported in CDP Private Cloud Base 7.1.7.x version by Hue.

To resolve this issue temporarily, you must perform the following steps:

  1. Locate the hue.sh in /opt/cloudera/cm-agent/service/hue/.
  2. Add the following line after export HADOOP_CONF_DIR=$CONF_DIR/hadoop-conf:
    export PYTHONPATH=/opt/cloudera/parcels/CDH/lib/hue/build/env/lib64/python2.7/site-packages
OPSAPS-72984: Alerts due to change in hostname fetching functionality in jdk 8 and jdk 11

Upgrading JAVA from JDK 8 to JDK 11 creates the following alert in CMS:

Bad : CMSERVER:pit666.slayer.mayank: Reaching Cloudera Manager Server failed

This happens due to a functionality change in JDK 11 on hostname fetching.
[root@pit666.slayer ~]# /us/lib/jvm/java-1.8.0/bin/java GetHostName
Hostname: pit666.slayer.mayank

[root@pit666.slayer ~]# /usr/lib/jvm/java-11/bin/java GetHostName
Hostname: pit666.slayer

You can notice that the "hostname" is set to a short name instead of FQDN.

The current workaround is to set the hostname as FQDN.

OPSAPS-72784: Upgrades from CDH6 to CDP Private Cloud Base 7.1.9 SP1 or higher versions fail with a health check timeout exception
If you are using Cloudera Manager 7.11.3 cumulative hotfix 14 or higher versions and upgrading from CDH 6 to CDP Private Cloud Base 7.1.9 SP1 or higher versions, the upgrade fails with a CMUpgradeHealthException timeout exception. This is because upgrades from CDH 6 to CDP Private Cloud Base 7.1.9 SP1 or to any of its cumulative hotfix versions are not supported.
None.
OPSAPS-68340: Zeppelin paragraph execution fails with the User not allowed to impersonate error.

Starting from Cloudera Manager 7.11.3, Cloudera Manager auto-configures the livy_admin_users configuration when Livy is run for the first time. If you add Zeppelin or Knox services later to the existing cluster and do not manually update the service user, the User not allowed to impersonate error is displayed.

If you add Zeppelin or Knox services later to the existing cluster, you must manually add the respective service user to the livy_admin_users configuration in the Livy configuration page.

OPSAPS-69847:Replication policies might fail if source and target use different Kerberos encryption types

Replication policies might fail if the source and target Cloudera Manager instances use different encryption types in Kerberos because of different Java versions. For example, the Java 11 and higher versions might use the aes256-cts encryption type, and the versions lower than Java 11 might use the rc4-hmac encryption type.

Ensure that both the instances use the same Java version. If it is not possible to have the same Java versions on both the instances, ensure that they use the same encryption type for Kerberos. To check the encryption type in Cloudera Manager, search for krb_enc_types on the Cloudera Manager > Administration > Settings page.

OPSAPS-69342: Access issues identified in MariaDB 10.6 were causing discrepancies in High Availability (HA) mode

MariaDB 10.6, by default, includes the property require_secure_transport=ON in the configuration file (/etc/my.cnf), which is absent in MariaDB 10.4. This setting prohibits non-TLS connections, leading to access issues. This problem is observed in High Availability (HA) mode, where certain operations may not be using the same connection.

To resolve the issue temporarily, you can either comment out or disable the line require_secure_transport in the configuration file located at /etc/my.cnf.

OPSAPS-70771: Running replication policy runs must not allow you to download the performance reports
During a replication policy run, the A server error has occurred. See Cloudera Manager server log for details error message appears on the UI and the Cloudera Manager log shows "java.lang.IllegalStateException: Command has no result data." when you click:
  • Performance Reports > Performance Summary or Performance Reports > Performance Full on the Replication Policies page.
  • Download CSV on the Replication History page to download any report.
This is because the Replication Manager UI shows the performance report links as enabled and clickable which is incorrect. You can download the reports only after the replication job run is complete.
None
OPSAPS-73038: False-positive port conflict error message displayed in Cloudera Manager
Cloudera Manager might display a false-positive error message Port conflict detected: 8443 (Gateway Health HTTP Port) is also used by: Knox Gateway during cluster installations. The warning does not cause actual installation failures.
None.
OPSAPS-70713: Error appears when running Atlas replication policy if source or target clusters use Dell EMC Isilon storage
You cannot create an Atlas replication policy between clusters if one or both the clusters use Dell EMC Isilon storage.
None
DMX-3973: Ozone replication policy with linked bucket as destination fails intermittently
When you create an Ozone replication policy using a linked/non-linked source cluster bucket and a linked target bucket, the replication policy fails during the "Trigger a OZONE replication job on one of the available OZONE roles" step.
None
OPSAPS-68143:Ozone replication policy fails for empty source OBS bucket
An Ozone incremental replication policy for an OBS bucket fails during the “Run File Listing on Peer cluster” step when the source bucket is empty.
None
OPSAPS-74398: Ozone and HDFS replication policies might fail when you use different destination proxy user and source proxy user
HDFS on-premises to on-premises replication fails when the following conditions are true:
  • You configure different Run As Username and Run on Peer as Username during the replication policy creation process.
  • The user configured in Run As Username does not have the permission to access the source path on the source HDFS.
Ozone replication fails when the following conditions are true:
  • FSO-to-FSO replication or an OBS-to-OBS replication with Incremental with fallback to full file listing or Incremental only replication type.
  • You configured different Run As Username and Run on Peer as Username during the replication policy creation process.
  • The user configured in Run As Username does not have the permission to access the source bucket on the source Ozone.
Provide the same permissions to the user configured in Run As Username as the permissions of Run on Peer as Username on the source cluster.
Following are the list of fixed issues that were shipped for Cloudera Manager 7.11.3 CHF16 (version: 7.11.3.36-67636814):
OPSAPS-73585, OPSAPS-73432: Enhance code to merge compressed Spark event log files
Fixes an issue with unreported metrics in Cloudera Observability when the spark.eventLog.compress property was set to true.
The spark.eventLog.compress property is set to false by default, but enabling it will no longer encoded event logs to fail when processed in Cloudera Observability.
OPSAPS-60642: Host header injection issue on /j_spring_security_check internal endpoint
/j_spring_security_check is internal endpoint which is vulnerable to Host header injection. This issue occurs if the user disabled PREVENT_HOST_HEADER_INJECTION feature flag.
Host header injection: In an incoming HTTP request, web servers often dispatch the request to the target virtual host based on the value supplied in the Host header. Without proper validation of the header value, the attacker can supply invalid input to cause the web server to:
  • Dispatch requests to the first virtual host on the list
  • Redirect to an attacker-controlled domain
  • Perform web cache poisoning
  • Manipulate password reset functionality
This issue is resolved now by adding Feature Flag PREVENT_HOST_HEADER_INJECTION to prevent host header injection vulnerability on /j_spring_security_check internal endpoint. This feature flag is by default enabled and it enables additional logic to block potential Host Header Injection attacks targeting the /j_spring_security_check endpoint in Cloudera Manager.
OPSAPS-73628: Impala query profile export to Telemetry Publisher failed due to a 5MB string length limit introduced in Jackson 2.15.0.
The Jackson string length limit was increased to allow exporting large Impala query profiles. Specifically, maxStringLength was set to Integer.MAX_VALUE using StreamReadConstraints, resolving the export failure.
OPSAPS-73922: The Proxy server settings are not working correctly for the Telemetry Publisher in Cloudera Manager versions 7.11.3 and higher.
The Proxy server issues are resolved by updating the cdp-sdk-java artifact's version. This issue is now resolved.
OPSAPS-73792: Telemetry Publisher exhibited incorrect behaviour during job uploads by accepting a Status Code 503 response and marking logs as successfully exported.
The issue is now resolved. Telemetry Publisher now treats only Status Code 200 as successful. For non-200 status codes, Telemetry Publisher will now log an error message.
OPSAPS-73655: Cloud replication no longer fails after the delegation token is issued
You can now configure com.cloudera.enterprise.distcp.skip-delegation-token-on-cloud-replication = false in the Cloudera Manager > Clusters > HDFS service > Configuration > HDFS Replication Advanced Configuration Snippet (Safety Valve) for core-site.xml property to ensure that the HDFS and Hive external table replication policies replicating from an on-premises cluster to cloud do not fail.
The replication policies were failing when you chose the Advanced Setting > Delete Policy > Delete permanently option during the replication policy creation process and an incremental replication run was in progress.
When the advanced configuration snippet is set to false, the MapReduce client process obtains the delegation tokens explicitly before it submits the MapReduce job for the replication policy. By default, the advanced configuration snippet is set to true.
OPSAPS-73142: The required configuration from replication safety valve is not accessed
An Ozone replication policy with Incremental with fallback to full file listing option failed with Pre-Filelisting Check Failed with Error: target bucket has layout OBS, but [fs.s3a.endpoint, fs.s3a.secret.key, fs.s3a.access.key] properties are missing from the target Ozone service core-site.xml config error because the required configuration was not available in the required folders.
To mitigate this issue, the required configuration parameters are now added automatically to the required folders during the Ozone replication policy run.
OPSAPS-73219, OPSAPS-73218: Dry run of Ozone incremental policies fail
When you run the Cloudera Manager API request to start an Ozone replication policy in Dry Run mode, the replication policy fails if the OzoneReplicationType is Incremental only or Incremental with fallback to full file listing. To prevent this issue, the Dry Run operation is no longer available.
OPSAPS-71459: Commands continue to run after Cloudera Manager restart
Some remote replication commands continue to run endlessly even after a Cloudera Manager restart operation. This issue is fixed.
Fixed Common Vulnerabilities and Exposures
For information about Common Vulnerabilities and Exposures (CVE) that are fixed in Cloudera Manager 7.11.3 cumulative hotfix 16, see Fixed Common Vulnerabilities and Exposures in Cloudera Manager 7.11.3 cumulative hotfixes.

The repositories for Cloudera Manager 7.11.3 CHF16 are listed in the following table:

Table 1. Cloudera Manager 7.11.3 CHF16
Repository Type Repository Location
RHEL 9 Compatible Repository:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/redhat9/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/redhat9/yum/cloudera-manager.repo
RHEL 8 Compatible Repository:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/redhat8/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/redhat8/yum/cloudera-manager.repo
RHEL 7 Compatible Repository:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/redhat7/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/redhat7/yum/cloudera-manager.repo
SLES 15 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/sles15/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/sles15/yum/cloudera-manager.repo
SLES 12 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/sles12/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/sles12/yum/cloudera-manager.repo
Ubuntu 22 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/ubuntu2204/apt
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/ubuntu2204/apt/cloudera-manager.list
Ubuntu 20 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/ubuntu2004/apt
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.11.3.36/ubuntu2004/apt/cloudera-manager.list