Support Questions

Find answers, ask questions, and share your expertise
Celebrating as our community reaches 100,000 members! Thank you!

cannot start hbase in cluster mode


I have three system with hbase installed, one of them a master node, and the rest are slaves. Following are the details:

/etc/hosts file contains: (all files in master node)    localhost    saichanda-OptiPlex-9020       master       slave1       slave2

hbase-site.xml file contains:


/usr/local/hbase/conf/regionservers contains


After starting zookeeper in my system,

when I run in my system(master) hbase, I get the following:

 sudo ./bin/ starting master, logging to /usr/local/hbase/bin/../logs/hbase-root-master-saichanda-OptiPlex-9020.out
root@master's password: root@slave1's password: root@slave1's password:

I get all the password requests at once, it doesn't allow me to type password...

Another doubt is, it says, root@master, root@slave1, root@slave2, but actually I don't have my system names to be master, slave1, slave2.. rather my system names are saichanda,dmacs,dmacs with IP addresses,, respectively. Where should I modify my files to run hbase cluster successfully.


@saichand akella

Don't use "sudo" in the start command. Also make sure you are able to do a password less ssh from saichanda user to all other machines(including self "ssh localhost" should not prompt for password).

View solution in original post


Super Collaborator

With SSH each server has an authentication key. When you connect the first time, you are asked if you really trust the server to be the correct one. If you confirm, the key is stored in ~/..ssh/known_hosts. When you connect again, this key is compared to the key the server provides to authenticate himself. If they differ you get the error message you just see. Typically it means that the host has changed, which can be an attack.

I guess you have that issue, as the name/IP association has changed from you OP
OP: slave1 slave2

Now as per your error message: slave1 ?

Maybe you will have to correct the IP addresses for the names?

If you are sure your server/IP are correct and uncompromised, you can edit the fie /home/saichanda/.ssh/known_hosts with any editor and replace the key, or you simply do as the message proposes:

ssh-keygen -f "/home/saichanda/.ssh/known_hosts" -R slave1
ssh-keygen -f "/home/saichanda/.ssh/known_hosts" -R

Then you can again ssh the host slave1 and slave2 and accept the host key,


I have done everything possible.. looked into every site possible, Got down my error lines to as small as follows

saichanda@saichanda-OptiPlex-9020:~$ /usr/local/hbase/bin/ 
starting master, logging to /usr/local/hbase/logs/hbase-saichanda-master-saichanda-OptiPlex-9020.out
The authenticity of host 'slave2 (' can't be established.
ECDSA key fingerprint is SHA256:UBvk5FkG3KfSMREsDIKbob1l782fozXQHT6+3J6F2Y4.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'slave1 (' can't be established.
ECDSA key fingerprint is SHA256:D9udCvOaKAFGwNbuIpBa+pQErZSDTjLg4m4LJ+s8DzM.
Are you sure you want to continue connecting (yes/no)? master: starting regionserver, logging to /usr/local/hbase/bin/../logs/hbase-saichanda-regionserver-saichanda-OptiPlex-9020.out
slave2: Host key verification failed.
slave1: Host key verification failed.

Can you help me conclude this doubt here??plz...


I found few interesting facts in the process of learning how to start hbase:

Firstly, Be sure that on all the systems there are users by which you start the hbase, if not, then use `adduser` command in respective systems.

Secondly, Be sure that you (master) have the write permission to create the log file in the /usr/local/../logs directory in slave nodes. Otherwise, it throws permission denied error...

Finally, Be sure that you copied the ssh-copy-id to all the systems for a passwordless access into regionservers.


Glad you were able to start hbase.

>>> Firstly, Be sure that on all the systems there are users by which you start the hbase, if not, then use adduser command in respective systems.

This was pre-requisite to have same user in all machines. Then only you can do a passwordless ssh from

user1@source --> user1@destination.

The next two points are covered in either my comment or @Harald Berghoff comments below.


@Sandeep NemuriI wish to acknowledge all who have contributed to this post more than I did.. Can you summarize the solutions touching on all the errors that I have committed, may be a brief ANSWER that I can accept as best answer. Truly in a positive sense...


@saichand akella That should be ok 🙂 you can accept this answer.