<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>question webHDFS 403 error in Support Questions</title>
    <link>https://community.cloudera.com/t5/Support-Questions/webHDFS-403-error/m-p/242314#M204117</link>
    <description>&lt;P&gt;&lt;A rel="user" href="https://community.cloudera.com/users/1271/sheltong.html" nodeid="1271"&gt;&lt;/A&gt;
&lt;/P&gt;&lt;P&gt;Hello all,&lt;/P&gt;&lt;P&gt;after fresh kerberization of Ambari 2.7.3 / HDP 3 cluster, the HDFS namenode isn't able to start because the hdfs user can't talk to the webhdfs. The following error is returned:&lt;/P&gt;&lt;PRE&gt;GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)&lt;/PRE&gt;&lt;P&gt;&lt;A rel="user" href="https://community.cloudera.com/users/1271/sheltong.html" nodeid="1271"&gt;&lt;/A&gt;It is not only from ambari: I can recreate this error from a simple curl call from hdfs user:&lt;/P&gt;&lt;PRE&gt;su - hdfs
curl --negotiate -u : &lt;A href="http://datanode:50070/webhdfs/v1/tmp?op=GETFILESTATUS" target="_blank"&gt;http://datanode:50070/webhdfs/v1/tmp?op=GETFILESTATUS&lt;/A&gt;&lt;/PRE&gt;
&lt;A rel="user" href="https://community.cloudera.com/users/1271/sheltong.html" nodeid="1271"&gt;&lt;/A&gt;
&lt;P&gt;Which returns&lt;/P&gt;&lt;PRE&gt;&amp;lt;/head&amp;gt;
&amp;lt;body&amp;gt;&amp;lt;h2&amp;gt;HTTP ERROR 403&amp;lt;/h2&amp;gt;
&amp;lt;p&amp;gt;Problem accessing /webhdfs/v1/tmp. Reason:
&amp;lt;pre&amp;gt;    GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)&amp;lt;/pre&amp;gt;&amp;lt;/p&amp;gt;
&amp;lt;/body&amp;gt;
&amp;lt;/html&amp;gt;
&lt;/PRE&gt;
&lt;A rel="user" href="https://community.cloudera.com/users/1271/sheltong.html" nodeid="1271"&gt;&lt;/A&gt;
&lt;P&gt;Overall permission for this user should be in tact, since I'm able to run hdfs operations from shell and kinit without problems. What could be the problem?&lt;/P&gt;&lt;P&gt;I've tried recreating keytabs several times, and fiddling with ACL settings on the config, but nothing works. What principal is WEBHDFS expecting? The same results are when I'm trying accessing it with HTTP/host@EXAMPLE.COM principal. &lt;A rel="user" href="https://community.cloudera.com/users/1271/sheltong.html" nodeid="1271"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;NB: I'll add that there's nothing fancy in the HDFS settings, mainly stock/default config.&lt;/P&gt;&lt;P&gt;NB2: I will add, that I've added all possible encryption types to krb5.conf as I could find, but none if these helped:&lt;/P&gt;&lt;PRE&gt;    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
&lt;/PRE&gt;&lt;P&gt;&lt;A rel="user" href="https://community.cloudera.com/users/1271/sheltong.html" nodeid="1271"&gt;@Geoffrey Shelton Okot&lt;/A&gt;&lt;/P&gt;</description>
    <pubDate>Wed, 16 Jan 2019 23:40:20 GMT</pubDate>
    <dc:creator>mRabramS</dc:creator>
    <dc:date>2019-01-16T23:40:20Z</dc:date>
  </channel>
</rss>

