question Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part of HDFS superg in Support Questions

Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part of HDFS superg

sandy05 — Fri, 16 Sep 2022 12:13:10 GMT

Hi,

I am new to Hue. I have installed Hue on the remote server than that of the namenode.

When I login to Hue and try to access the HDFS file locations, I am getting following error.

Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part of HDFS supergroup, "supergroup".

I created the user admin and hdfs in Hue and they are the superusers. I have also created directories in hdfs and added to supergroup.

drwxr-xr-x - hduser supergroup 0 2017-09-09 14:47 /user

drwxr-xr-x - admin supergroup 0 2017-09-09 14:16 /user/admin

drwxr-xr-x - hdfs supergroup 0 2017-09-09 14:13 /user/hdfs

drwxr-xr-x - hduser supergroup 0 2017-09-04 17:27 /user/hduse

Please let me know where am I making the mistake and request to guide.

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

sandy05 — Wed, 13 Sep 2017 09:13:57 GMT

Any body can help.

my hdfs-site.xml has the following in HA NN and DN

<property>
  <name>dfs.webhdfs.enabled</name>
  <value>true</value>
</property>
</configuration>

My hue.ini has

 [[hdfs_clusters]]
    # HA support by using HttpFs

    [[[default]]]
      # Enter the filesystem uri
      fs_defaultfs=hdfs://ha-cluster

      # NameNode logical name.
      ## logical_name=

      # Use WebHdfs/HttpFs as the communication mechanism.
      # Domain should be the NameNode or HttpFs host.
      # Default port is 14000 for HttpFs.
      ## webhdfs_url=http://localhost:50070/webhdfs/v1
       webhdfs_url=http://<gateway_host_name>:14000/webhdfs/v1

My httpFs-site.xml has

  <!-- HUE proxy user setting -->
  <property>
    <name>httpfs.proxyuser.hue.hosts</name>
    <value>*</value>
  </property>
  <property>
    <name>httpfs.proxyuser.hue.groups</name>
    <value>*</value>
  </property>

  <property>
    <name>httpfs.hadoop.config.dir</name>
    <value>/etc/hadoop/conf</value>
  </property>
</configuration>

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

suraj9 — Tue, 22 May 2018 22:13:53 GMT

Hello Sandy, I'm currently facing the same issue now. Did you figured out how can you solve this error ! If yes, please share those details as it would be very helpful for us.

Thanks

Suraj

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

sandy05 — Wed, 23 May 2018 03:44:59 GMT

Hi Siraj,

I did not find the solution for this.

This was the issue with the manual setup. When I used cloudera package
installation all worked fine.

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

suraj9 — Wed, 23 May 2018 16:29:06 GMT

Oh Ok, Thank you Sandy. I'm actually running the Hue instance in EMR cluster, so I think I can't apply any changes here with cloudera packages.

Cloudera support team, if you have a possible solution for this please leave your comments. I could see this issue was raised by several developers but there were no apt solutions on this.

Cannot access: /user/. The HDFS REST service is not available.

HTTPConnectionPool(host='ip-XX-XX-XX-XX.ec2.internal', port=50070): Max retries exceeded with url:

Thanks

Suraj

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

LarryP — Wed, 02 Jan 2019 21:01:53 GMT

I have the same problem. Did anyone ever get this solved ?

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

bgooley — Thu, 03 Jan 2019 01:21:27 GMT

Hi @LarryP,

We need to know exactly what action you are taking and what happens when you take it. While your issue may be the same or similar to what was described earlier in this thread, we can't tell till we see your info.

Please also review your Hue log (/var/log/hue/runcpserver.log by default) at the time the problem occurs and share any log messages/exceptions you see at that time. This should provide some background to start looking at the issue.

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

LarryP — Thu, 03 Jan 2019 16:03:49 GMT

I get this error on initial signon within HUE web UI.

Cannot access: /. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part of HDFS supergroup, "supergroup".

It should be taking me to my home directory "/user/lar00181" but instead is taking me to "/" root. The error is correct in that I do not have rights to access /. What I cannot figure out is why it is taking me to root in the first place.

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

pascal — Tue, 08 Jan 2019 08:35:27 GMT

In the Cloudera Manager, make sure that you have started HDFS and all the necessary services. I ran into this problem as well, but starting the command cluster solved the issue.

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

weixia — Tue, 08 Jan 2019 22:09:22 GMT

Hi Sandy,

Hue superusers are different from hdfs superusers. With this error message, it complains that the admin and hdfs users you created through hue are not part to hdfs superuser. You should be able to fix the issue by fixing the permission of the directories to the user/group on the cluster.

Hope this helps!

Weixia

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

BiggieSmalls — Thu, 27 Jun 2019 17:10:14 GMT

Hello, I am having the same issue when I click HDFS on Hue Web UI

when you say change permissions on /user/group- can you elaborate on that where, how and what?

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

bgooley — Tue, 09 Jul 2019 19:18:52 GMT

@BiggieSmalls,

The "you are a Hue admin..." error is pertty generic and means that something went wrong when trying to access HDFS. I suggest checking your /var/log/runcpserver.log file for error messages and stack traces that occur when the UI error message occurs. That will help us start investigating the cause. We don't know what will solve your problem until we know what is causing it.

Cheers,

Ben

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

mmmunafo — Thu, 18 Jul 2019 11:53:48 GMT

After migrating to CM 6.2.0, we are having a similar problem for the access of users in Hue.

We pinned it down to the /var/run/hue/hue_krb5_ccache disappearing, so that we have the error

GSSError: (('Unspecified GSS failure.  Minor code may provide more information', 851968), ('No Kerberos credentials available (default cache: /var/run/hue/hue_krb5_ccache)', -1765328243))

in /var/log/hue/error.log on the HUE servers (we have a one balancer, 4 backends configuration)

We have been forced to regenerate the keytabs for the ticket renewers and restart Hue, just to make the system work for a few hours, until the Kerberos cache disappears again.

We are currently trying to monitor what is actually accessing or removing the ccache.

Thanks,

Maurizio

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

mmmunafo — Thu, 18 Jul 2019 13:15:14 GMT

As a quick update, it seems the ccache file is cancelled from a Hue backend server after a user logs in/out from the system.

Maurizio

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

bgooley — Thu, 18 Jul 2019 15:13:09 GMT

@mmmunafo,

What "system" are you users logging out of? If it is your OS, it sounds like a kdestroy is being done and your users' cache should not be tied to Hue's cache which is intended only for the Hue process on that host. Hue does not execute a "kdestroy" command so it is very unlikely that Hue is removing the credentials cache.

Happy to help, but I think we need some more details of what you are observing to understand the problem.

Cheers,

Ben

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

mmmunafo — Thu, 18 Jul 2019 17:40:18 GMT

I meant people logging in or out the Hue WebUI, being authenticated using the desktop.auth.backend.PamBackend

(and pam login using an LDAP backend)

The system used to work regularly with no issue until we migrated from CM6.1 to CM6.2 a few weeks ago.

We activated "auditd" to trace the access to the ccache file, and the audit log shows access to the ccache when users "log out" from the Hue WebUI

time->Thu Jul 18 15:31:05 2019
type=PROCTITLE msg=audit(1563456665.989:2959): proctitle=707974686F6E322E37002F6F70742F636C6F75646572612F70617263656C732F4344482D362E322E302D312E636468362E322E302E70302E3936373337332F6C69622F6875652F6275696C642F656E762F62696E2F6875650072756E6368657272797079736572766572
type=PATH msg=audit(1563456665.989:2959): item=1 name="/var/run/hue/hue_krb5_ccache" inode=1169 dev=00:17 mode=0100600 ouid=982 ogid=981 rdev=00:00 nametype=DELETE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1563456665.989:2959): item=0 name="/var/run/hue/" inode=1150 dev=00:17 mode=040755 ouid=982 ogid=981 rdev=00:00 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1563456665.989:2959): cwd="/run/cloudera-scm-agent/process/11096-hue-HUE_SERVER"
type=SYSCALL msg=audit(1563456665.989:2959): arch=c000003e syscall=87 success=yes exit=0 a0=7f9a9c33f820 a1=2 a2=1 a3=0 items=2 ppid=19438 pid=19449 auid=4294967295 uid=982 gid=981 euid=982 suid=982 fsuid=982 egid=981 sgid=981 fsgid=981 tty=(none) ses=4294967295 comm="python2.7" exe="/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/build/env/bin/python2.7" key="hue_krb5_ccache

It seems that the process cancelling the file is

\_ python2.7 /opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/build/env/bin/hue runcherrypyserver

We tried to better pin down the specific activity from the source code, but with no success.

Which other types of details do you think you need? We might include more renewer log errors, but those are just about the file not existing anymore. From the Cloudera Manager point of view, everything is green and working correctly, because the processes are all active.

Thanks

Maurizio

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

bgooley — Fri, 19 Jul 2019 00:38:49 GMT

@mmmunafo,

WOW! I see what you mean!

How did you track this down to happening when a user logs out of Hue?

I have to admit that PAM auth is used less than most other forms of authentication, so it is possible that no one has hit some sort of issue or bug.

If you have the runcpserver.log that shows time when a user is logging out, I'd be interested in seeing it in case it yields any clues.

In the meantime, I have a cluster I haven't upgraded to CDH 6.2 yet, so I'll set up PAM auth in 6.1.1 and then upgrade just to see. Might be a couple days, but I'll let you know if I think of anything in the meantime.

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

bgooley — Fri, 19 Jul 2019 01:28:52 GMT

@mmmunafo, I upgraded to 6.2 and PAM using the default "login" module doesn't cause the credentials cache to be deleted. Any other ideas of how these two things could be tied in? Perhaps the PAM module is doing something special, but it is the PID of the Hue process that is in the audit...

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

mmmunafo — Fri, 19 Jul 2019 19:31:02 GMT

Thank you for your answer.

We (me and my colleagues) were able to reproduce the issue, pinning it down to PAM.
First of all, we are using Ubuntu 18.04 and CM 6.2.0, and this might be related to the error,
that seems to be tied to the PAM usage from a library inside Hue, since we upgraded at once from Ubuntu 16.04 and CM 6.1.0 to the current configuration.

The error is triggered by the PAM login authentication.
Informally, as far as we understand, when Hue starts. it initializes its own kerberos credential cache in

/var/run/hue/krb5_hue_ccache, as defined by the configuration via the ccache_path Hue parameter, mirrored in the KRB5CCNAME environment variable. This is the ccache known also by the ticket renewer.

What it seems to be happening is that, after the Hue Server initialization, that KRB5CCNAME is left in the OS environment, and it is inheredited by the Python pam.authenticate function (as called at line 329 of backend.py).

When any user logs in from the WebUI, the PAM login rule will pass that that environment to its auth/krb5 component, that tries to reuse that /var/run/hue/krb5_hue_ccache file as the one belonging to the user.
Since that file has the hue tickets, this operation fails: PAM/krb5 invalidates it, cancelling it, and
then falls back to using the next possible file location (usually /tmp/krb5_pam_XXXXXX).

The /var/run/hue/krb5_hue_ccache has been now cancelled. and the Ticket Renewer will not find any ticket to be renewed anymore.
The user is logged in, but the hue server has lost its tickets to admin all the other services.

Probably, while KRB5CCNAME must be correctly set for Hue to correctly interact with the other components of the Cloudera system, it should removed from the os.environ while interacting with the PAM subsystem, that should instead rely on the local OS environment.

We are still trying to find a local workaround for the issue, but we hope this info can be useful to help fixing the bug.

Regards,

Maurizio

Re: Cannot access: //. Note: you are a Hue admin but not a HDFS superuser, "hdfs" or part

bgooley — Fri, 19 Jul 2019 20:16:17 GMT

@mmmunafo,

Thanks for the clear description. I did notice, when perusing Hue source, that KRB5CCNAME was set and was curious why. It was the only thing I could think of that would be influencing PAM behavior.

Very cool... let me see if I can figure out why we are adding KRB5CCNAME and if we can get rid of it