针对你遇到的用root启动Secure DataNode（通过jsvc绑定特权端口）但Kerberos认证失败、无法连接NameNode的问题，我整理了几个关键排查和解决方向：

• 检查Keytab文件的权限与归属
  Secure DataNode由root启动后会切换到hduser运行核心服务，所以hdfs.keytab必须确保hduser有读取权限。执行以下命令查看权限：

  ls -l /opt/hadoop/etc/hadoop/hdfs.keytab
  

  正确的权限应该是hduser:hadoop（或你的Hadoop用户组），权限值设为600（仅所有者可读）。如果当前是root权限，用以下命令修改：

  sudo chown hduser:hadoop /opt/hadoop/etc/hadoop/hdfs.keytab
  sudo chmod 600 /opt/hadoop/etc/hadoop/hdfs.keytab
  

• 验证Kerberos主体与配置的匹配性
  你的DataNode配置中dfs.datanode.kerberos.principal是hduser/_HOST@FDATA.COM，而keytab里的主体是hduser/stwhddn01@FDATA.COM，这里_HOST会自动替换为节点的全限定域名，需要确保：

  1. 执行hostname -f输出的全限定域名是stwhddn01（和keytab中的一致）；
  2. Kerberos的krb5.conf文件在所有节点上配置一致，且域名大小写完全匹配（比如FDATA.COM是大写，主体中的域名也要保持一致，Kerberos对大小写敏感）。

• 确认Secure DataNode的用户切换是否生效
  你已经设置了HADOOP_SECURE_DN_USER=hduser，启动后可以用以下命令检查DataNode的实际运行用户：

  ps aux | grep datanode
  

  如果进程用户还是root，说明jsvc没有成功切换到hduser，可能是JSVC_HOME路径配置错误，或者jsvc二进制文件的权限不足（需要确保root能执行jsvc）。

• 手动测试Kerberos认证有效性
  切换到hduser用户，尝试用keytab获取票据，验证认证是否正常：

  su - hduser
  kinit -kt /opt/hadoop/etc/hadoop/hdfs.keytab hduser/stwhddn01@FDATA.COM
  klist
  

  如果klist能显示有效的票据，说明keytab和主体是正常的；此时可以尝试直接用hduser启动DataNode（临时跳过jsvc，虽然无法绑定特权端口，但能验证Kerberos连接NameNode的逻辑是否正常）。

• 开启Kerberos调试日志定位细节
  当前DataNode日志只有重试连接的信息，开启Kerberos调试日志可以看到认证失败的具体原因。在hadoop-env.sh中添加以下配置：

  export HADOOP_OPTS="-Dsun.security.krb5.debug=true"
  

  重启DataNode后，查看日志中的Kerberos相关输出，比如是否有Credential not found（找不到凭证）、Pre-authentication failed（预认证失败）等错误，这些信息能快速定位问题根源。

• 检查NameNode的Kerberos配置
  确认NameNode的hdfs-site.xml中已正确配置Kerberos相关参数：

  • dfs.namenode.kerberos.principal和dfs.namenode.keytab.file配置正确且生效；
  • 集群的core-site.xml中hadoop.security.authentication已设置为kerberos；
  • NameNode的keytab文件权限和主体也无问题。

内容的提问来源于stack exchange，提问作者Tran Thien An