Support Questions

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

Oozie shell action - Permission denied: user=xyz, access=EXECUTE, inode="/user/yarn/.staging":yarn:supergroup:drwx------

avatar
Master Guru

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 ?

1 ACCEPTED SOLUTION

avatar

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' `

View solution in original post

5 REPLIES 5

avatar

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' `

avatar
Master Guru

Thanks @Ana Gillan

avatar
Master Mentor

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.

avatar
Master Guru

Thanks @Artem Ervits - will try this

avatar
Master Mentor

@Kuldeep Kulkarni has this been resolved? Can you post your solution or accept best answer?