Our Community is getting an upgrade! To get everything ready for the relaunch, we’ll be placing the site in read-only mode starting September 21st.
We really appreciate your understanding while we get things set up behind the scenes. Catch up on all the exciting details about the move here.
Need help or have questions? Drop us a line at [email protected]
Created 12-22-2015 07:35 AM
I have a shell action defined in my workflow which moves data from one hdfs location to another, my action is failing because of below error
Permission denied: user=xyz, access=EXECUTE, inode="/user/yarn/.staging":yarn:supergroup:drwx------
Below are some useful configurations (got these from application log)
yarn.app.mapreduce.am.staging-dir=/user user.name=yarn mapreduce.job.user.name=xyz
I also have added below variable in my workflow.xml file under shell action
<env-var>HADOOP_USER_NAME=${wf:user()}</env-var>I'm not sure why user "xyz" is trying to read/write at /user/yarn/.staging location.
Oozie experts, any idea whats going on here ?
Created 12-22-2015 06:06 PM
EDIT: oops - just read the end bit of your post... still try to do it in the shell action itself and see?
---
I believe this is a known limitation in non-secure clusters, whereby the containers are running as YARN user and not running as user xyz.
Try to pass in the HADOOP_USER_NAME variable as illustrated below:
$ `export HADOOP_USER_NAME=xyz ; hive -hiveconf hive.execution.engine=mr -e 'show databases' `
Created 12-22-2015 06:06 PM
EDIT: oops - just read the end bit of your post... still try to do it in the shell action itself and see?
---
I believe this is a known limitation in non-secure clusters, whereby the containers are running as YARN user and not running as user xyz.
Try to pass in the HADOOP_USER_NAME variable as illustrated below:
$ `export HADOOP_USER_NAME=xyz ; hive -hiveconf hive.execution.engine=mr -e 'show databases' `
Created 12-24-2015 03:38 AM
Thanks @Ana Gillan
Created 12-23-2015 02:21 PM
here's an example of a shell action executed as another user https://github.com/dbist/oozie/tree/master/apps/sqoopshell, it is not the best approach but it works. User xyz executes the oozie workflow, the shell action executes as yarn user, thus you get xyz cannot access yarn.
Created 12-24-2015 03:38 AM
Thanks @Artem Ervits - will try this
Created 02-02-2016 02:32 PM
@Kuldeep Kulkarni has this been resolved? Can you post your solution or accept best answer?