[Bug]: Terminal fails with NoSuchMethodError in the apache/amoro Docker image because Hudi brings in hadoop-auth 2.10.0

Start by tracing the Docker image's -Psupport-all-formats dependency packaging and the Terminal's local Spark session initialization at LocalSessionFactory.lazyInitContext. Check how the Hadoop 2.10.0 jars from Hudi coexist with Hadoop 3.4.3, then reproduce using the quickstart Terminal SQL in the issue. Done means the published image runs that script successfully without the setRuleMechanism NoSuchMethodError.

What happened?

Following the quickstart with the apache/amoro image, the first script in Terminal fails before any SQL runs. The terminal log shows java.lang.RuntimeException: Run with ugi request failed., and the AMS log has the cause:

Caused by: java.lang.NoSuchMethodError: 'void org.apache.hadoop.security.HadoopKerberosName.setRuleMechanism(java.lang.String)'
	at org.apache.hadoop.security.HadoopKerberosName.setConfiguration(HadoopKerberosName.java:84) ~[hadoop-client-api-3.4.3.jar:?]
	at org.apache.hadoop.security.UserGroupInformation.initialize(UserGroupInformation.java:313) ~[hadoop-client-api-3.4.3.jar:?]
	at org.apache.hadoop.security.UserGroupInformation.ensureInitialized(UserGroupInformation.java:298) ~[hadoop-client-api-3.4.3.jar:?]
	at org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:585) ~[hadoop-client-api-3.4.3.jar:?]
	at org.apache.spark.util.Utils$.getCurrentUserName(Utils.scala:2417) ~[spark-core_2.12-3.5.8.jar:3.5.8]
	at org.apache.spark.SparkContext.<init>(SparkContext.scala:329) ~[spark-core_2.12-3.5.8.jar:3.5.8]
	...
	at org.apache.amoro.server.terminal.local.LocalSessionFactory.lazyInitContext(LocalSessionFactory.java:155)

The image's lib directory holds hadoop-client-api-3.4.3.jar next to hadoop-auth-2.10.0.jar, hadoop-common-2.10.0.jar and the other Hadoop 2.10.0 jars. HadoopKerberosName from hadoop-client-api 3.4.3 calls KerberosName.setRuleMechanism, and the KerberosName that gets loaded comes from hadoop-auth 2.10.0, which does not have that method. The Hadoop 2 jars come from the Hudi format, which the image includes through -Psupport-all-formats:

org.apache.hudi:hudi-java-client:jar:0.14.1:compile
\- org.apache.hudi:hudi-client-common:jar:0.14.1:compile
   \- org.apache.hudi:hudi-common:jar:0.14.1:compile
      \- org.apache.hbase:hbase-client:jar:2.4.9:compile
         +- org.apache.hadoop:hadoop-auth:jar:2.10.0:compile
         \- org.apache.hadoop:hadoop-common:jar:2.10.0:compile

To check the cause, I started the same master-snapshot image with only lib/hadoop-auth-2.10.0.jar deleted inside the container. With that change the same script finishes, SELECT * FROM db.user returns the three rows, and the table details page loads.

I expected the quickstart Terminal to work in the published image.

Affects Versions

0.9.0-incubating (apache/amoro:latest, version 0.9.0-incubating(5a64126)) and master (apache/amoro:master-snapshot, version 0.9-SNAPSHOT(6af75bb)). I also built the distribution from master at 961f2de with the profiles the image workflow uses (-Psupport-all-formats -Pno-extended-disk-storage -Pno-plugin-bin). Its lib has the same Hadoop 2.10.0 jars, and the Terminal fails the same way with it.

What table formats are you seeing the problem on?

Iceberg

What engines are you seeing the problem on?

AMS

How to reproduce

1. docker run -p 1630:1630 -e JVM_XMS=1024 apache/amoro /entrypoint.sh ams, which is the AMS service of the quickstart docker-compose file.
2. Log in as admin/admin, create the optimizer group local, then an Internal catalog demo_catalog with the Iceberg format and Hadoop storage (warehouse /tmp/warehouse/demo).
3. In Terminal, run the quickstart script for the Iceberg format:

CREATE DATABASE IF NOT EXISTS db;
CREATE TABLE IF NOT EXISTS db.user (id INT, name string, ts TIMESTAMP) USING iceberg PARTITIONED BY (days(ts));
INSERT OVERWRITE db.user VALUES (1, "eric", timestamp("2022-07-01 12:32:00")),
(2, "frank", timestamp("2022-07-02 09:11:00")), (3, "lee", timestamp("2022-07-02 10:11:00"));
SELECT * FROM db.user;

I did steps 2 and 3 through the dashboard's REST endpoints (/api/ams/v1/... with X-Request-Source: Web), which is what the UI calls. The terminal log status is Failed and nothing is created.

Relevant log output

2026/11/10 04:08:05 new sql script submit, current thread pool state. [Active: 1, PoolSize: 1]
2026/11/10 04:08:05 terminal session dose not exists. create session first
2026/11/10 04:08:06 something error when execute script.
2026/11/10 04:08:06 java.lang.RuntimeException: Run with ugi request failed.
	at org.apache.amoro.table.TableMetaStore.call(TableMetaStore.java:282)

Anything else

#1695 had the same setRuleMechanism error after the Spark 3.3 upgrade in 2023. I only tried the Docker images, not the binary tarball. Creating a namespace and a table through the Iceberg REST endpoint of the same AMS worked, so the failure I saw is limited to the Terminal's local Spark session.

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct