Re: REFRESH TABLE METADATA - Access Denied

https://issues.apache.org/jira/browse/DRILL-4143 On Mon, Feb 15, 2016 at 1:30 PM, Neeraja Rentachintala < nrentachint...@maprtech.com> wrote: > John > What is the JIRA# where you are adding more info. > > -thanks > > On Mon, Feb 15, 2016 at 11:10 AM, John Omernik wrote: > > >

Re: REFRESH TABLE METADATA - Access Denied

John What is the JIRA# where you are adding more info. -thanks On Mon, Feb 15, 2016 at 11:10 AM, John Omernik wrote: > Arg, this problem is crazy. (I'll put this in the JIRA too) So after > waiting a while, and loading more data. I tried to refresh table metadata > on the

Re: REFRESH TABLE METADATA - Access Denied

Arg, this problem is crazy. (I'll put this in the JIRA too) So after waiting a while, and loading more data. I tried to refresh table metadata on the table, using the dataadm user (basically the user who owns the data). Note all directories and files are owned by dataadm:dataadm and the

Re: REFRESH TABLE METADATA - Access Denied

So I am not sure what's happened here. The JIRA isn't filled out, but I can't seem to reproduce the problem. Was this stealth fixed? Based on some testing, even when the data directory is owned by a different user than the drillbit, the .parquet_metadata files are created as mapr:mapr with 755

Re: REFRESH TABLE METADATA - Access Denied

I'd like to revive this thread. Specifically, what should the expect behavior of the refresh metadata be when running with impersonation? Drill Bit User: mapr Data User (owner): jdoe Authenticated User: jdoe So if a base folder, mytable, has subdirectories of dates, 2015-01-01, 2015-01-02 etc.

Re: REFRESH TABLE METADATA - Access Denied

> > The output from Drill and the Markup interpreter on Jira apparently had a > family argument at Thanksgiving, and don't agree on all things... Made my morning :)

Re: REFRESH TABLE METADATA - Access Denied

I've created https://issues.apache.org/jira/browse/DRILL-4143 The output from Drill and the Markup interpreter on Jira apparently had a family argument at Thanksgiving, and don't agree on all things... Looking at the JIRA, while it's not pretty, it still conveys what I am going for. Please

Re: REFRESH TABLE METADATA - Access Denied

Hi John, I tried this and didn't find any issues. Let me know if I didn't follow your reproduction faithfully. $ sqlline -u jdbc:drill: -n ec2-user -p mapr apache drill 1.2.0 "drill baby drill" 0: jdbc:drill:> refresh table metadata dfs.`/tmp/flows`;

Re: REFRESH TABLE METADATA - Access Denied

All files are owned by mapr:mapr? I have a setup where mapr is the user running the drillbit, but then I have a directory that is owned by a another user. mapradm:mapradm on all files. (Permissions on directories and files appears to be rwxr-x-r-x) When I run the REFRESH TABLE metatdata the

Re: REFRESH TABLE METADATA - Access Denied

My files were owned by mapr:mapr. I changed the ownership of everything to ec2-user, and now get permission denied on the refresh table metadata command, even though impersonation is on and I authenticated as ec2-user. If impersonation is working correctly, then I'd expect this should work. Is

Re: REFRESH TABLE METADATA - Access Denied

I turned on MapR Auditing (This is a handy feature) and found that when I run a query (that is giving me access denied.. my query is select * from table limit 1) Per MapR the user I am logged in as (mapradm) is trying to do a create operation on the .drill.parquet_metadata operation and I guessing

Re: REFRESH TABLE METADATA - Access Denied

I take it back. I went to run a query, in the same session that had worked, and now I am getting permission denied. I do have a query running created new directories every 5 minutes, however, these aren't the directories that are giving me permission denied. Did you try running an aggregate

Re: REFRESH TABLE METADATA - Access Denied

This is exactly what I am seeing ok, good, that makes me feel a bit better (I am not crazy!) Before we file a JIRA, can anyone comment on what may be happening here? Is this a bug or a feature? Since this is so new, I am not really sure the expected result... On Wed, Nov 11, 2015 at 3:25 PM,

Re: REFRESH TABLE METADATA - Access Denied

MapR audit records print the errno value to indicate success/failure. Thus status 17 means errno 17 which means EEXIST. Looks like Drill is trying to create a file that already exists. I’ll defer to others as to why Drill might do that. Keys ___ Keys Botzum Senior

Re: REFRESH TABLE METADATA - Access Denied

John, Vince I am little confused by this email thread. >From the original description by John, I thought that the issue refresh metadata command is running successfully (and the cache is created with the Drillbit user as owner) , but at query time it fails for any user (even though the user has

Re: REFRESH TABLE METADATA - Access Denied

Ok, I'm seeing the behavior you describe except for the last bullet - the permissions on the file would allow for anyone to read the cache file. $ ls -la total 3499 drwxr-xr-x 2 ec2-user ec2-user 5 Nov 11 21:18 . drwxrwxrwx 4 ec2-user ec2-user 2 Nov 11 21:18 .. -rwxr-xr-x 1 ec2-user

Re: REFRESH TABLE METADATA - Access Denied

For me it's very strange. If I delete all the .drill.parquet_metadata files, I can create and then run a query. I can wait 5 minutes, and come back and run the same query, and then I get the permission denied, if I try to run the REFRESH METADATA again, then it too fails with permission denied

Re: REFRESH TABLE METADATA - Access Denied

Has anyone been able to try/test this? I am curious if it's me only issue or something more of bug so I can open a JIRA if needed. John On Fri, Nov 6, 2015 at 11:06 AM, John Omernik wrote: > If someone has authorization/authentication setup, to reproduce: > > Have a Parquet

Re: REFRESH TABLE METADATA - Access Denied

Hey John, I have a secure cluster and some parquet files, I'll try this out and report back. On Monday, November 9, 2015, John Omernik wrote: > Has anyone been able to try/test this? I am curious if it's me only issue > or something more of bug so I can open a JIRA if needed.

REFRESH TABLE METADATA - Access Denied

I ran REFRESH TABLE METADATA on a table, it completed successfully. When I tried a subsequent query, I get a IOException: Permission Denied on .drill.parquet_metadata. I am running drill with authentication. I ran the REFRESH TABLE METADATA as user X, it appears the .drill.parquet_metadata was

Re: REFRESH TABLE METADATA - Access Denied

This doesn't make sense and seems like a bug. I think the right behavior is for the Drillbit to access the cache as Drillbit user at the query time (there is no user level metadata cache in Drill at this point). On Fri, Nov 6, 2015 at 6:57 AM, John Omernik wrote: > I ran

Re: REFRESH TABLE METADATA - Access Denied

If someone has authorization/authentication setup, to reproduce: Have a Parquet table with directories underneath the main (I have directories per day) Then issue REFRESH TABLE METADATA on the root of the table running an authenticated user other than the drill bit user. (I am using mapr, I used