@Rocky I create catalog as: CREATE EXTERNAL CATALOG jdbc_losrepdb PROPERTIES ( "type"="jdbc", "user"="abc", "password"="abc123", "jdbc_uri"="jdbcoraclethin:@//10.144.6.20:1521/losrepdb.shbfinance.com.vn", "driver_url"="file:///home/data-team/starrock/ojdbc10-19.18.0.0.jar", "driver_class"="oracle.jdbc.driver.OracleDriver" ); this run success, and can run: SHOW DATABASES FROM jdbc_losrepdb; but i can not select from table: select * from LOSREP.APPLICATION; SQL Error [1064] [42000]: Couldn't open file /home/data-team/starrock/ojdbc10-19.18.0.0.jar: BE:1567985 Couldn't open file /home/data-team/starrock/ojdbc10-19.18.0.0.jar: BE:1567985

Hi there! I'm Rocky. It looks like you're encountering a common issue when setting up a JDBC catalog with a local file path. The error

Couldn't open file ... BE:1567985

indicates that the StarRocks Backend (BE) node is unable to access the JDBC driver JAR file at the path you provided. In StarRocks, when you use a

file:///

URL for the `driver_url`: 1. FE Nodes: The Frontend (FE) downloads/accesses the JAR file when you run

CREATE EXTERNAL CATALOG

. This is why your catalog creation and

SHOW DATABASES

(which are metadata operations handled by the FE) work fine. 2. BE/CN Nodes: Every Backend (BE) or Compute Node (CN) must be able to access the JAR file at the exact same path during the first query execution (the

SELECT

statement). How to Fix This There are two ways to resolve this: Option 1: Copy the JAR to all BE/CN nodes (Recommended for local files) Make sure the file

ojdbc10-19.18.0.0.jar

exists on every single BE and CN node in your cluster at the exact same location:

/home/data-team/starrock/ojdbc10-19.18.0.0.jar

. Additionally, ensure that the OS user running the StarRocks BE process has: * Read permissions for the

.jar

file. * Execute (x) permissions for every parent directory in the path (e.g.,

/home/

,

/home/data-team/

, and

/home/data-team/starrock/

). If the BE process cannot traverse these folders, it will fail to open the file. Option 2: Use an HTTP URL (Easier for clusters) Instead of a local file path, you can host the JAR on a web server or use a public repository URL. This allows every node to download the driver independently without manual file copying. You can modify your catalog to use a public Maven URL:

sql
ALTER EXTERNAL CATALOG jdbc_losrepdb SET PROPERTIES (
    "driver_url" = "<https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc10/19.18.0.0/ojdbc10-19.18.0.0.jar>"
);

Additional Tip If you are using StarRocks 3.x, ensure that

JAVA_HOME

is correctly set in your

be/bin/start_be.sh

on every node and that it points to a JDK (not just a JRE), as the JDBC bridge requires it to load the driver dynamically. Give this a try, and let me know if you still see the error! References • data_source/catalog/jdbc_catalog.md • data_source/datalake_faq.md • sql-reference/sql-functions/table-functions/files.md • administration/management/FE_configuration.md

my FE and BE is on the same machine, why FE can read, but BE can not?

Even though your FE and BE are on the same machine, they act as two independent processes. The reason FE can read the file while BE cannot usually comes down to process permissions or environment isolation. Here are the most common reasons why this happens: 1. Different OS Users In many StarRocks deployments, the FE and BE processes are started by different users or have different permission levels. * FE (Frontend) might be running as a user that has access to

/home/data-team/

. * BE (Backend) is often the process that actually executes the data fetch. If the BE process is running as a different user (e.g.,

starrocks

), it may not have permission to enter the

/home/data-team/

directory. * Check: Run

ps -ef | grep starrocks

to see which user is running the

starrocks_be

and

StarRocksFE

processes. 2. Directory "Execute" Permissions For a process to access a file in Linux, it needs Read (r) permission on the file itself AND Execute (x) permission on every parent directory in the path. * The path

/home/data-team/starrock/

is inside a user's home directory. By default, Linux home directories are often restricted (e.g.,

drwx------

). * Even if the BE user can "see" the file, if it cannot "traverse"

/home/data-team/

, it will fail with "Couldn't open file." 3. StarRocks BE Working Directory The FE handles the metadata (the

SHOW DATABASES

command), but the BE handles the actual data connection (the

SELECT

command). When you run the query, the BE tries to load the JAR into its own JVM environment. How to Fix Method A: Move the JAR to a shared directory (Best Practice) Move the JAR file out of the

/home/

directory to the StarRocks installation directory or a standard system path where both processes have guaranteed access. 1. Move the file:

cp /home/data-team/starrock/ojdbc10-19.18.0.0.jar /opt/starrocks/lib/

2. Ensure permissions:

chmod 644 /opt/starrocks/lib/ojdbc10-19.18.0.0.jar

3. Update the catalog:

sql
    ALTER EXTERNAL CATALOG jdbc_losrepdb SET PROPERTIES (
        "driver_url" = "file:///opt/starrocks/lib/ojdbc10-19.18.0.0.jar"
    );

Method B: Grant Permissions If you must keep it in the current folder, give all users read/execute access to the path:

bash
chmod +x /home/data-team
chmod +x /home/data-team/starrock
chmod 644 /home/data-team/starrock/ojdbc10-19.18.0.0.jar

Method C: Check JAVA_HOME Ensure that in your

be/conf/be.conf

or

be/bin/start_be.sh

, the

JAVA_HOME

is explicitly set to a JDK path (not JRE). The BE needs the JDK to properly initialize the JDBC bridge. One final note: The error code

BE:1567985

refers to the internal ID of the Backend node that failed. Since you only have one BE, it confirms the local backend is the one hitting the permission wall. References • faq/Deploy_faq.md • data_source/catalog/jdbc_catalog.md • administration/Meta_recovery.md • data_source/External_table.md • data_source/datalake_faq.md • administration/management/BE_configuration.md

@Rocky I found that this issue is related starrock 4.0.8 my jdbc table like this:

company_email

*VARCHAR*(100),

loan_consumer_requested

*DECIMAL*(20,2),

loan_amount_requested

*DECIMAL*(20,2),

loan_term_requested

*VARCHAR*(50) ) ENGINE=jdbc properties ( "resource" = "losrepdb_3", "table" = "LOSREP.APPLICATION" ); i can run select: select * from

losrep_link

.

application

a where a.id ='5365184'; but sometime fault and sometime success SQL Error [5609] [22001]: Data truncation: Couldn't open file /drivers/ojdbc10-19.18.0.0.jar: BE:1567985 Data truncation: Couldn't open file /drivers/ojdbc10-19.18.0.0.jar: BE:1567985

The intermittent nature of this error in StarRocks 4.0.8 (and similar 3.x/4.x versions) usually points to one of three specific architectural reasons. Even if you believe your FE and BE are on the same machine, StarRocks queries are distributed, and the "environment" must be consistent for every process involved. Here is why it happens intermittently and how to fix it: 1. You likely have multiple BE or CN nodes If you have more than one Backend (BE) or Compute Node (CN), StarRocks will round-robin your query across them. If Node A has the driver at

/drivers/ojdbc10...

but Node B does not, the query will succeed when it hits A and fail when it hits B. * Action: Run

SHOW BACKENDS;

and

SHOW COMPUTE NODES;

in your SQL console. * Fix: Ensure the JAR file exists at the exact same path on every node listed in those results. 2. Permissions on the

/drivers

directory The path

/drivers/

is at the root of your filesystem. By default, processes running as a non-root user (like the

starrocks

user) may have inconsistent access to root-level folders depending on how the service was started or if there are disk-mount delays. * Action: Check which user is running StarRocks:

ps -ef | grep starrocks_be

. * Fix: Ensure that user has both read (r) and execute (x) permissions on the folder:

bash
    sudo chmod 755 /drivers
    sudo chmod 644 /drivers/ojdbc10-19.18.0.0.jar

3. The "Data truncation" prefix (A known reporting quirk) The error

SQL Error [5609] [22001]: Data truncation: ...

is actually a side effect of how StarRocks 4.x reports errors from the Java JDBC Bridge. The "Data truncation" part is often a generic SQL State (22001) that is misapplied to the actual underlying error: the BE cannot find the JAR file. * Ignore the "Data truncation" text; the real issue is the second half:

Couldn't open file /drivers/...

. 4. Shared Data / Containerized Environment If you are running StarRocks in Docker or Kubernetes: * Intermittent failures happen because different Pod replicas may not have the same volume mounts. * Fix: Instead of using

file:///

, use an HTTP URL for the

driver_url

. This is the most "production-stable" way because every BE/CN will automatically download the driver into its own local storage when needed, regardless of which node it is. Update your Catalog to use a stable URL:

sql
ALTER EXTERNAL CATALOG jdbc_losrepdb SET PROPERTIES (
    "driver_url" = "<https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc10/19.18.0.0/ojdbc10-19.18.0.0.jar>"
);

Note: After running the

ALTER

statement, the BEs will attempt to download the JAR from this URL on the next query execution. Summary Checklist: 1. Run

SHOW BACKENDS;

— is there more than one? 2. Is the file

/drivers/ojdbc10-19.18.0.0.jar

present on all BE machines? 3. Does the Linux user running the BE process have permission to access

/drivers

? 4. If using a cluster, we highly recommend switching

driver_url

to an HTTPS link to avoid manual file management. References • data_source/catalog/jdbc_catalog.md • administration/management/BE_configuration.md • faq/Deploy_faq.md • data_source/External_table.md • sql-reference/sql-statements/Catalog/ALTER_CATALOG.md References • unloading/Flink_connector.md • faq/operation_maintenance_faq.md • faq/Deploy_faq.md • administration/management/BE_configuration.md