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
unt
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 ec
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 per
Hi,
Can someone please verify that this is in fact a bug so I can rule out our
own mistakes?
We have recently moved all our logging to Avro to compensate for schema
differences in JSON that were causing various problems and our latest
release is now impeded with this.
Alternatively can someone pl
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 P
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, Vinc
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
this
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
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 que
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 .drill
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`;
+---+--
You have a few options
from the OS shell you can use the sqlline syntax as mentioned by Rajkumar
./sqlline -u -n -p --run= >
or you can use -f instead of --run=
In the sqlline shell
sqlline> !record
sqlline> !run
sqlline> !record
Last record stop spooling output to a file
For comments
12 matches
Mail list logo
