Cloudera Docs

Cloudera Manager 7.13.1.300 Cumulative hotfix 3

Know more about the Cloudera Manager 7.13.1.300 cumulative hotfixes 3.

This cumulative hotfix was released on June 2, 2025.

Following are the list of known issues and their corresponding workarounds that are shipped for Cloudera Manager 7.13.1.300 CHF 3 (version: 7.13.1.300-66873372):
OPSAPS-73546: Service Monitor fails to perform Canary tests on HMS / HBASE / ZooKeeper due to missing dependencies

Due to a missing dependency caused by an incomplete build and packaging in certain OS releases, the HMS (Hive Metastore) Canary health test fails, logging a ClassNotFoundException in the Service Monitor log. This problem relates to all deliveries using runtime cluster version 7.1.x or 7.2.x, while the Cloudera Manager version is 7.13.1.x and the OS is NOT RHEL8.

In case your OS is either RHEL 9 or SLES 15 or Ubuntu 2004 or Ubuntu 2204 and if you install the Cloudera Manager 7.13.1.x version, then create a symbolic link using root user privileges on the node that host the Service Monitor service (cloudera-scm-firehose) at /opt/cloudera/cm/lib/cdh71/cdh71-hive-client-7.13.1-shaded.jar, pointing to /opt/cloudera/cm/lib/cdh7/cdh7-hive-client-7.13.1-shaded.jar.

Restart the Service Monitor service post the change. This will allow the Service Monitor to perform Canary testing correctly on the HMS (Hive Metastore) service.

OPSAPS-73211: Cloudera Manager 7.13.1 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.13.1 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-73011: Wrong parameter in the /etc/default/cloudera-scm-server file
In case the Cloudera Manager needs to be installed in High Availability (2 nodes or more as explained here), the parameter CMF_SERVER_ARGS in the /etc/default/cloudera-scm-server file is missing the word "export" before it (on the file there is only CMF_SERVER_ARGS= and not export CMF_SERVER_ARGS=), so the parameter cannot be utilized correctly.
Edit the /etc/default/cloudera-scm-server file with root credentials and add the word "export" before the parameter CMF_SERVER_ARGS=.
OPSAPS-60346: Upgrading Cloudera Manager Agent triggers cert rotation in Auto-TLS use case 1

Upgrading Cloudera Manager Agent nodes from the Cloudera Manager UI wizard as part of a Cloudera Manager upgrade causes the host to get new certificates, which becomes disruptive.

The issue happens with use case 1 and Cloudera Manager DB is because Cloudera Manager always regenerates the host cert as part of the host install or host upgrade step. However, with use case 3, Cloudera Manager does not regenerate the cert as it comes from the user.

Currently, there are three following possible workarounds:
  • Rotate all CMCA certs again using the generateCmca API command, and using the "location" argument to specify a directory on disk. This will revert to the old behavior of storing the certs on disk instead of the DB.
  • Switch to Auto-TLS Use Case 3 (Customer CA-signed Certificates).
  • Manual upgrade of Cloudera Manager Agents, instead of upgrading from Cloudera Manager GUI.
OPSAPS-72756:The runOzoneCommand API endpoint fails during the Ozone replication policy run
The /clusters/{clusterName}/runOzoneCommand Cloudera Manager API endpoint fails when the API is called with the getOzoneBucketInfo command. In this scenario, the Ozone replication policy runs also fail if the following conditions are true:
  • The source Cloudera Manager version is 7.11.3 CHF11 or 7.11.3 CHF12.
  • The target Cloudera Manager is version 7.11.3 through 7.11.3 CHF10 or 7.13.0.0 or later where the feature flag API_OZONE_REPLICATION_USING_PROXY_USER is disabled.
Choose one of the following methods as a workaround:
  • Upgrade the target Cloudera Manager before you upgrade the source Cloudera Manager for 7.11.3 CHF12 version only.
  • Pause all replication policies, upgrade source Cloudera Manager, upgrade destination Cloudera Manager, and unpause the replication policies.
  • Upgrade source Cloudera Manager, upgrade target Cloudera Manager, and rerun the failed Ozone replication policies between the source and target clusters.
OPSAPS-65377: Cloudera Manager - Host Inspector not finding Psycopg2 on Ubuntu 20 or Redhat 8.x when Psycopg2 version 2.9.3 is installed.

Host Inspector fails with Psycopg2 version error while upgrading to Cloudera Manager 7.13.1.x versions. When you run the Host Inspector, you get an error Not finding Psycopg2, even though it is installed on all hosts.

None
OPSAPS-72447, CDPD-76705: Ozone incremental replication fails to copy renamed directory
Ozone incremental replication using Ozone replication policies succeed but might fail to sync nested renames for FSO buckets.
When a directory and its contents are renamed between the replication runs, the outer level rename synced but did not sync the contents with the previous name.
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 Ozone replication policy does not show performance reports
During an Ozone replication policy run, the A server error has occurred. See Cloudera Manager server log for details error message appears when you click:
  • Performance Reports > OZONE Performance Summary or Performance Reports > OZONE Performance Full on the Replication Policies page.
  • Download CSV on the Replication History page to download any report.
None
CDPD-53185: Clear REPL_TXN_MAP table on target cluster when deleting a Hive ACID replication policy
The entry in REPL_TXN_MAP table on the target cluster is retained when the following conditions are true:
  1. A Hive ACID replication policy is replicating a transaction that requires multiple replication cycles to complete.
  2. The replication policy and databases used in it get deleted on the source and target cluster even before the transaction is completely replicated.

In this scenario, if you create a database using the same name as the deleted database on the source cluster, and then use the same name for the new Hive ACID replication policy to replicate the database, the replicated database on the target cluster is tagged as ‘database incompatible’. This happens after the housekeeper thread process (that runs every 11 days for an entry) deletes the retained entry.

Create another Hive ACID replication policy with a different name for the new database
OPSAPS-71897: Finalize Upgrade command fails after upgrading the cluster with CustomKerberos setup causing INTERNAL_ERROR with EC writes.
After the UI FinalizeCommand fails, you must manually run the finalize commands through the Ozone Admin CLI:
  1. kinit with the scm custom kerberos principal
  2. ozone admin scm finalizeupgrade
  3. ozone admin scm finalizationstatus
OPSAPS-72204: HMS compaction configuration not updated through Cloudera Manager UI
The hive.compactor.initiator.on checkbox in Cloudera Manager UI for Hive Metastore (HMS) does not reflect the actual configuration value in cloud deployments. The default value is false, causing the compactor to not run.
To update the hive.compactor.initiator.on value:
  1. In the Cloudera Manager, go to Hive > Configuration
  2. Add the value for hive.compactor.initiator.on to true in the "Hive Service Advanced Configuration Snippet (Safety Valve) for hive-site.xml"
  3. Save the changes and Restart.
Once applied, the compaction process will run as expected.
OPSAPS-70702: Ranger replication policies fail because of the truststore file location
Ranger replication policies fail during the Exporting services, policies and roles from Ranger remote step.
  • Log in to the Ranger Admin host(s) on the source cluster.
  • Identify the Cloudera Manager agent PEM file using the # cat /etc/cloudera-scm-agent/config.ini | grep -i client_cert_file command. For example, the file might reside in client_cert_file=/myTLSpath/cm_server-cert.pem location.
  • Create the path for the new PEM file using the # mkdir -p /var/lib/cloudera-scm-agent/agent-cert/ command.
  • Copy the client_cert_file from config.ini as cm-auto-global_cacerts.pem file using the # cp /myTLSpath/cm_server-cert.pem /var/lib/cloudera-scm-agent/agent-cert/cm-auto-global_cacerts.pem command.
  • Change the ownership to 644 using the # chmod 644 /var/lib/cloudera-scm-agent/agent-cert/cm-auto-global_cacerts.pem command.

  • Resume the Ranger replication policy in Replication Manager.

OPSAPS-71403: Ozone replication policy creation wizard shows "Listing Type" field in source Cloudera Private Cloud Base versions lower than 7.1.9
When the source Cloudera Private Cloud Base cluster version is lower than 7.1.9 and the Cloudera Manager version is 7.11.3, the Ozone replication policy creation wizard shows Listing Type and its options. These options are not available in Cloudera Private Cloud Base 7.1.8x versions.
OPSAPS-71414: Permission denied for Ozone replication policy jobs if the source and target bucket names are identical
The OBS-to-OBS Ozone replication policy job fails with the com.amazonaws.services.s3.model.AmazonS3Exception: Forbidden or Permission denied error when the bucket names on the source and target clusters are identical and the job uses S3 delegation tokens. Note that the Ozone replication jobs use the delegation tokens when the S3 connector service is enabled in the cluster.
You can use one of the following workarounds to mitigate the issue:
  • Use different bucket names on the source and target clusters.
  • Set the fs.s3a.delegation.token.binding property to an empty value in ozone_replication_core_site_safety_valve to disable the delegation tokens for Ozone replication policy jobs.
OPSAPS-71067: Wrong interval sent from the Replication Manager UI after Ozone replication policy submit or edit process.
When you edit the existing Ozone replication policies, the schedule frequency changes unexpectedly.
OPSAPS-71005: RemoteCmdWork uses a singlethreaded executor
Replication Manager runs the remote commands for a replication policy through a single-thread executor.
OPSAPS-59553: SMM's bootstrap server config should be updated based on Kafka's listeners
SMM does not show any metrics for Kafka or Kafka Connect when multiple listeners are set in Kafka.
Workaround: SMM cannot identify multiple listeners and still points to bootstrap server using the default broker port (9093 for SASL_SSL). You need to override the bootstrap server URL by performing the following steps:
  1. In Cloudera Manager, go to SMM > Configuration > Streams Messaging Manager Rest Admin Server Advanced Configuration Snippet (Safety Valve)
  2. Override bootstrap server URL (hostname:port as set in the listeners for broker) for streams-messaging-manager.yaml.
  3. Save your changes.
  4. Restart SMM.
OPSAPS-69317: Kafka Connect Rolling Restart Check fails if SSL Client authentication is required
The rolling restart action does not work in Kafka Connect when the ssl.client.auth option is set to required. The health check fails with a timeout which blocks restarting the subsequent Kafka Connect instances.
You can set ssl.client.auth to requested instead of required and initiate a rolling restart again. Alternatively, you can perform the rolling restart manually by restarting the Kafka Connect instances one-by-one and checking periodically whether the service endpoint is available before starting the next one.
OPSAPS-70971: Schema Registry does not have permissions to use Atlas after an upgrade
Following an upgrade, Schema Registry might not have the required permissions in Ranger to access Atlas. As a result, Schema Registry's integration with Atlas might not function in secure clusters where Ranger authorization is enabled.
  1. Access the Ranger Console (Ranger Admin web UI).
  2. Click the cm_atlas resource-based service.
  3. Add the schemaregistry user to the all - * policies.
  4. Click Manage Service > Edit Service.
  5. Add the schemaregistry user to the default.policy.users property.
OPSAPS-59597: SMM UI logs are not supported by Cloudera Manager
Cloudera Manager does not display a Log Files menu for SMM UI role (and SMM UI logs cannot be displayed in the Cloudera Manager UI) because the logging type used by SMM UI is not supported by Cloudera Manager.
View the SMM UI logs on the host.
OPSAPS-72298: Impala metadata replication is mandatory and UDF functions parameters are not mapped to the destination
Impala metadata replication is enabled by default but the legacy Impala C/C++ UDF's (user-defined functions) are not replicated as expected during the Hive external table replication policy run.
Edit the location of the UDF functions after the replication run is complete. To accomplish this task, you can edit the “path of the UDF function” to map it to the new cluster address, or you can use a script.
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
OPSAPS-72470: Hive ACID replication policies fail when target cluster uses Dell EMC Isilon storage and supports JDK17
Hive ACID replication policies fail if the target cluster is deployed with Dell EMC Isilon storage and also supports JDK17.
None
Following are the list of fixed issues that were shipped for Cloudera Manager 7.13.1.300 CHF 3 (version: 7.13.1.300-66873372):
OPSAPS-73225: Cloudera Manager Agent reporting inactive/failed processes in Heartbeat request

As part of introducing Cloudera Manager 7.13.x, some changes were done to the Cloudera Manager logging, eventually causing Cloudera Manager Agent to report on inactive/stale processes during Heartbeat request.

As a result, the Cloudera Manager servers logs are getting filled rapidly with these notifications though they do not have impact on service.

In addition, with adding the support for the Observatory feature, some additional messages were added to the logging of the server. However, in case the customer did not purchase the Observatory feature, or the telemetry monitoring is not being used, these messages (which appears as "TELEMETRY_ALTUS_ACCOUNT is not configured for Otelcol" are filling the server logs and preventing proper follow-up on the server activities).

This issue is fixed now.

OPSAPS-72270: Start ECS command fails on uncordon nodes step

Ensure the kube-apiserver is up and running for at least 60 seconds before proceeding with the uncordon step, and use the correct target node name, not just the name of the node where the uncordon command is executed.

This issue is fixed now.

OPSAPS-72978: The getUsersFromRanger API parameter truncates the user list after 200 items
The Cloudera Manager API endpoint v58/clusters/[***CLUSTER***]/services/[***SERVICE***]/commands/getUsersFromRanger API endpoint no longer truncates the list of returned users at 200 items.
OPSAPS-71105: Expose or set YARN cgroup v2 settings in Cloudera Manager
Cgroup v2 support is now enabled by default, and YARN detects and uses the correct cgroup handling code.
Fixed Common Vulnerabilities and Exposures
For information about Common Vulnerabilities and Exposures (CVE) that are fixed in Cloudera Manager 7.13.1 cumulative hotfix 3, see Fixed Common Vulnerabilities and Exposures in Cloudera Manager 7.13.1 and Cloudera Manager 7.13.1 cumulative hotfixes.

Cloudera Manager 7.13.1.300 CHF 3 download information

The repositories for Cloudera Manager 7.13.1.300-CHF 3 are listed in the following table:

Repository Type Repository Location
RHEL 9 Compatible Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/redhat9/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/redhat9/yum/cloudera-manager.repo
RHEL 8 Compatible Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/redhat8/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/redhat8/yum/cloudera-manager.repo
SLES 15 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/sles15/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/sles15/yum/cloudera-manager.repo
Ubuntu 22 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/ubuntu2204/apt
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/ubuntu2204/apt/cloudera-manager.list
Ubuntu 20 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/ubuntu2004/apt
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.300/ubuntu2004/apt/cloudera-manager.list