@kvinod  Good then close the thread. It's always a good idea to have an external database to host not only the CM/Ambari database but also Oozie, hive, ranger etc in a multitenant architecture and maybe backup the database host periodically to avoid having your backend databases all over the cluster. 20 cents advice ! ... View more

@monicbw,   Hadoop uses the following to derive group membership when using ShellBasedUnixGroupsMapping:   id -gn monica.baniwijaya;id -Gn monica.baniwijaya You can run the above to see what hdfs sees when it tries to figure out to what groups you belong. Also, you can run the following to find out what groups hdfs thinks you belong to: hdfs groups monica.baniwijaya This will return what is in hdfs's user/group mapping cache. Knowing what each of the above returns will go a long way toward understanding the problem better.   That said, I am concerned about 2 things you mentioned:  (1)   You referred to "LDAP".  OS users and LDAP users are completely different unless you have some way for your OS to pull information from LDAP and return it for user/group requests (SSSD, IPA, Centrify, are a few examples).  How is LDAP involved in this situation?   (2) in your "useradd" example, you are setting the primary group for your user which is not common as far as I know.  I think you meant to use -G instead which will add a secondary group to a user: -g, --gid GROUP name or ID of the primary group of the new account -G, --groups GROUPS list of supplementary groups of the new account Lastly, you mentioned that in HDFS your user belongs to a different group than on the OS and that you would expect the group to be created in HDFS too.  HDFS relies on the user/groups mapping returned from the OS... it will cache that information, but it is not created in HDFS.  Minor difference.  What test did you do to determine that the OS and HDFS groups appear different for your user?  I'd use the "id" and "hdfs groups" commands I pointed out earlier to get a better sense of what HDFS sees.   ... View more

I had the same issue on one of the node and it was related with /etc/resolv.conf entry. Changed the nameserver details to that of other nodes and that fixed it. ... View more

@bgooley Yes this fixed it for me. It was a permissions issue. ... View more

As a temporary fix you can use linux command swapoff -a && swapon -a to move swap. Just make sure you have enough free memory to move swap to (top command) ... View more

thanks ... View more

@sparkd,   While we can't be sure, it is likely that some permissions were changed on the /tmp directory so that the Service Monitor (that executes the HDFS canary health check) could not access the directory.  Service Monitor utilizes the "hue" user and principal to access other resources so it is reasonable to assume that /tmp in HDFS did not allow the hue user or group to write to /tmp.   Are you having similar trouble?  If so, check your service monitor log file for stack traces and errors related to the hdfs canary. ... View more

@Dominic_kim,   It might be more work, but it would be better to have a cluster where trust can be established.  Clients expect that the server they connected to (whether FQDN, short name, or IP) will be included in the Subject Alternative Name extension or in the CN subject.   Note that recent releases of CM and CDH do support wildcard certificates so I'm not sure what the problem is in your case... we would need some more specific info.   That said, you can turn off validation in some places like Hue, but it is not so easily done in others.  Depends on the client. For Hue, I think you can turn off all validation by setting: [desktop] ssl_validate=False   If you don't have ssl_cert_ca_verify or other configuration in other sections, then they will look to the global "desktop" section setting.  Restart Hue after making the change. ... View more

Hello @bgooley , Thank you very much for your answers ... View more