@manjj,   If you lost your database and then reinstalled CM, the agents will not complete the heartbeat to the new CM since the cm_guid does not match the value in CM.   To correct this, on all hosts with agents running:   - # rm /var/lib/cloudera-scm-agent/cm_guid - # service cloudera-scm-agent restart   I think the reason you are seeing those errors in the parcels page is because the agents are in bad health... due to the cm_guid.   the cm_guid is generated by CM and the agent stores it to make sure the agent does not communicate with a CM / database that is unexpeted.  The process of removing it will allow the agent to see that it should now accept communication with the new CM server/db that you have.     ... View more

@VeljkoC,   The following shows the cause of the problem:   2018-10-18 10:53:32,694 ERROR hive.log: [pool-5-thread-3]: Got exception: org.apache.hadoop.security.AccessControlException Permission denied: user=hue, access=EXECUTE, inode="/user":cloudera-scm:supergroup:drwxrwx---   The bold text above shows that an attempt was made by the Metastore to access HDFS but the required permission for the user was not available.  In this case, hue user (used by Service Monitor) needs EXECUTE privilege on /user   We can see that this does not exist:   cloudera-scm:supergroup:drwxrwx---   The default permission on /user is drwxr-xr-x I believe so in your cluster it may have been changed for some reason.  In order to allow for listing of files in /user you will need to add EXUCUTE for other.   For example the result should look like this: drwxr-xr-x   - hdfs  supergroup          0 2018-08-27 10:19 /user     That should help. ... View more

@JoaoBarreto,   Currently there is no way to automate this in Cloudera Manager, but it is possible via manual configuration for each service, the agents, and Cloudera Manager (as well as the shell if you are using hadoop commands at the command line).    I would like to do some extensive testing at some point, but, for now, you can use the following:   Background:   Java will use the following configuration if set for that JVM: -Djava.security.krb5.conf=/custom/path/to/krb5.conf   If java.security.krb5.conf is not set, then java will look in the following locations:   - /path_to_jdk/jre/lib/security/krb5.conf - /etc/krb5.conf   MIT Kerberos-based servers can be configured with the following environment variable:   KRB5_CONFIG=/custom/path/to/krb5.conf   With the above rules in mind, these general steps can be followed:   (1)   Place your custom krb5.conf in the "jre/lib/security" subdirectory of your JDK's directory. Make sure it is read for all in terms of file permissions (so that all service users can read from it)   Any client or server that uses that JDK will then automatically read from your customer krb5.conf rather than /etc.krb5.conf   * this includes Cloudera Manager   NOTE:  The draw-back of doing it this way is that if you upgrade Java, you will need to remember to put your krb5.conf in place.  NOTE2: If you choose to use -Djava.security.krb5.conf instead, that will require configuring it for all servers and clients in safety valves, files, etc.  The plus of this config, though, is that you do not have to remember to put your krb5.conf in place during upgrades of JDK.   (2)   For all agents in your cluster, add this to /etc/default/cloudera-scm-agent:   export KRB5_CONFIG=/custom/path/to/krb5.conf   (3)   Add the following to Hue Service Environment Advanced Configuration Snippet (Safety Valve) KRB5_CONFIG=/custom/path/to/krb5.conf   (4)   Add the following to Impala Service Environment Advanced Configuration Snippet (Safety Valve) KRB5_CONFIG=/custom/path/to/krb5.conf   You may also need to add to Impala Daemon Environment Advanced Configuration Snippet (Safety Valve): JAVA_TOOL_OPTIONS="-Djava.security.krb5.conf=/opt/krb5.conf   (5)   Restart EVERYTHING (cluster, management service, agents, Cloudera Manager)   That should give you a good start.   ... View more

@chriswalton007,   The following pages shows supported upgrades:     https://www.cloudera.com/documentation/enterprise/upgrade/topics/ug_upgrade_paths.html   As you have identified, it is not supported to upgrade from 5.15x to 6.0.x  This is due to the way we had to maintain fixes and features in branches of 5 and 6. Don't worry, though, as you only need to wait a while longer for 6.1 at which point you can upgrade to 6.1.  Only 5.15.x to 6.0.x is blocked.   We are targeting 6.1 to be released by the end of the year, but that is a rough estimate.   For now, you can keep up with the latest 5.x release and start reading the C6 upgrade documentation.  There are some major changes all over CDH and for Solr the upgrade path is complex, so it is a good idea to start planning if you are using most of the CDH products.     ... View more

@wert_1311,   (1)   Activity Monitor is only useful if you are using MapReduce1.  I doubt you are, so you can just delete Activity Monitor if that is true.  If you are using YARN for jobs, then you can remove Activity Monitor.   (2)   In the instructions, you need to copy the driver to /user/share/java.  Please list the contents so we can see if the cloudera-scm user has read access:   # ls -la /usr/share/java   You might compare permissions with the old, working hostl to see that the same directory and containing files have the same permissions.  The assumption here is that it is likely that Java just cannot access the mysql driver. ... View more