Return-Path: 
 <user-return-17718-apmail-hive-user-archive=hive.apache.org@hive.apache.org>
X-Original-To: apmail-hive-user-archive@www.apache.org
Delivered-To: apmail-hive-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id C6A0817CFD
	for <apmail-hive-user-archive@www.apache.org>;
 Mon, 29 Sep 2014 18:49:45 +0000 (UTC)
Received: (qmail 91190 invoked by uid 500); 29 Sep 2014 18:49:44 -0000
Delivered-To: apmail-hive-user-archive@hive.apache.org
Received: (qmail 91120 invoked by uid 500); 29 Sep 2014 18:49:44 -0000
Mailing-List: contact user-help@hive.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@hive.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@hive.apache.org>
List-Post: <mailto:user@hive.apache.org>
List-Id: <user.hive.apache.org>
Reply-To: user@hive.apache.org
Delivered-To: mailing list user@hive.apache.org
Received: (qmail 91108 invoked by uid 99); 29 Sep 2014 18:49:44 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2014 18:49:44 +0000
X-ASF-Spam-Status: No, hits=1.7 required=5.0
	tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of shushantarora09@gmail.com
 designates 209.85.216.45 as permitted sender)
Received: from [209.85.216.45] (HELO mail-qa0-f45.google.com) (209.85.216.45)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2014 18:49:38 +0000
Received: by mail-qa0-f45.google.com with SMTP id w8so1638154qac.4
        for <user@hive.apache.org>; Mon, 29 Sep 2014 11:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:date:message-id:subject:from:to:content-type;
        bh=5622b2q7iiy74ICNdvLPHaALaNJD642JvsAgzdysH4Y=;
        b=p2YOMED7xXh+hofRYsEDnxU6iP5C8+9geDDniUcA3zl5kV/o62WBytMG8T5YJI3eij
         SQUBgoyGgHkZ0coX8i2lsa0BQ493jcUNyv74y4sUQbvKa+GsGSsqsPWmde/BDM901XBP
         faIGo1w8Z2whXLVbtveuaxl4+Fh+dYipSOma1M/qhJ6l/WM+gCSatMhPaiAAt1KY5D1G
         oDOGorNku/qPJOvG1EqpeZzQlqJf7XGkNxI1vYvu4VvD8PqKDI8gXU0rGok070w5lnFE
         dRwOB11+lxPMXBGdxtImLYy0nQwEPsuV/TU+3nPxf7vnTIR5xf9MAqp2NaONxKVHbJQg
         zFzg==
MIME-Version: 1.0
X-Received: by 10.140.85.227 with SMTP id n90mr6283216qgd.89.1412016558339;
 Mon, 29 Sep 2014 11:49:18 -0700 (PDT)
Received: by 10.140.16.42 with HTTP; Mon, 29 Sep 2014 11:49:18 -0700 (PDT)
Date: Tue, 30 Sep 2014 00:19:18 +0530
Message-ID: 
 <CAFCxkQD5k=Zc8qGMET7LTC=nVZdJHURt=WUzT4aicG8tqbcfoA@mail.gmail.com>
Subject: problems while writing in partitioned table using oozie
From: Shushant Arora <shushantarora09@gmail.com>
To: user@hive.apache.org
Content-Type: multipart/alternative; boundary=001a11c13ee260801d050438b962
X-Virus-Checked: Checked by ClamAV on apache.org

--001a11c13ee260801d050438b962
Content-Type: text/plain; charset=UTF-8

Hi

While writing in a partitioned hive table using oozie , at end of job I am
getting copy file exception.
Oozie is creating job with mapred user not by user who submitted the job,
and table is created using another user.

Does providing 777 access on table directory solves the problem? Or is
there any way to tell oozie to fire job with submitted user and not by
mapred in unkerberosed installation setup.

Will there be any side effect like queries show partitions and all if I
give 777 on table directory, I have seen sometimes sub directory(for
partitions) got created by mapred user but no files get copied in table
directory and show partitions gives no result.

Thanks
Shushant

--001a11c13ee260801d050438b962
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi<div><br></div><div>While writing in a partitioned hive =
table using oozie , at end of job I am getting copy file exception.</div><d=
iv>Oozie is creating job with mapred user not by user who submitted the job=
, and table is created using another user.</div><div><br></div><div>Does pr=
oviding 777 access on table directory solves the problem? Or is there any w=
ay to tell oozie to fire job with submitted user and not by mapred in unker=
berosed installation setup.</div><div><br></div><div>Will there be any side=
 effect like queries show partitions and all if I give 777 on table directo=
ry, I have seen sometimes sub directory(for partitions) got created by mapr=
ed user but no files get copied in table directory and show partitions give=
s no result.</div><div><br></div><div>Thanks</div><div>Shushant</div></div>

--001a11c13ee260801d050438b962--