Yes, not suprised by the outcome of your test since the issue is about "read" permission on the temporary table and not the target table.   If you try the following, it should work for your test : Give "SELECT" permission on the database and retry. This time it should work and confirm the "problem".   And since you wonder, the problem isn't on the HDFS permission part. It's sentry side permissions issue. The user that is accessing and writing the data on HDFS is "hive" anyway (since the impersonification should be disabled). ... View more

From the error message I understand the issue is more about the temporary table created for selecting the data (and not about read permissions on the folder of the target table).   Not sure "how" sentry is supposed to handle this case. Guess I'll run some test since I'm curious about this.     ... View more

Well, the lock is stored in zookeeper. So you can search in zookeeper if the lock exists and delete it if yes. But I would advise you not to do so. Locks exist for data integrity. If you remove them while you should not it could lead to some "odd results".   Maybe you could add some error management in the workflow in order to "retry X times" before failing the whole workflow ? You could also better "communicate" with the users in order to reduce the likely hood of having your scheduled queries running concurrently with "users" queries.     ... View more

I am getting error as [cloudera@quickstart ~]$ hdfs dfs -mkdir /user/dmishra mkdir: Cannot create directory /user/dmishra. Name node is in safe mode. When your namenode is in "safe mode" it means it is in "read only". You need to exit the safe mode before writing to HDFS. If the namenode enter safe mode without you telling him, it also means you have an issue (disk space ?, configuratoin issue ? ...)   some time I get mkdir: Permission denied: user=cloudera, access=WRITE, inode="/user":hdfs:supergroup:drwxr-xr-x That error is pretty straight forward. It mean the user "cloudera" do not have "write" permission on the HDFS folder "/user". This works exactly like a linux box.   Also, it tells you that the folder "/user" is owned by the user "hdfs" and the group associated is "supergroup" with the following permission ( read write cross for the owner. read and cross for the group. read and cross for "others").   If you want to create a folder inside "/user" you need to be the owner with the current sets of permissions. ... View more

What is the exception / error message shown in the logs when you try to start a new job ?   ... View more

Give us your indexer_def.xml and morphline conf.   There should be an "id" field somewhere. And I guess you will find it in the indexer_def.xml file. For example : <indexer table="<hbase_table_name>" mapper="com.ngdata.hbaseindexer.morphline.MorphlineResultToSolrMapper" unique-key-field="id">     ... View more

The property you have set is the default replication factor for new blocks. This do not alter existing blocks. So if you have under-replicated blocks asking for 3 replica then you need to alter these blocks directly. Check the command line "hdfs dfs -setrep" ... View more

Hi,   If you are using the KRB5CCNAME variable it should not target the keytab file. That is the reason you cannot kinit twice with the same keytab.   That variable should target the Kerberos ticket cache generated using the keytab or login/password.   Also, you need to get a valid Kerberos ticket using the same Kerberos REALM as your Hadoop cluster is using.   ... View more