ORA-48128: opening of a symbolic link is disallowed during Data Pump Export 

Recently, I encountered an issue while running a Data Pump export (expdp). The export failed with the following errors:

ORA-27307: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 7
ORA-31693: Table data object "HR"."EMPLOYEES" failed to load/unload and is being skipped due to error:
ORA-39155: error expanding dump file name "/nfs/exports/BLTDB/20260524/BLTDB_04.dmp"
ORA-48128: opening of a symbolic link is disallowed
ORA-19505: failed to identify file "/nfs/exports/BLTDB/20260524/BLTDB_04.dmp"
...

At first glance, the error seemed to point to a symbolic link problem, possibly caused by incorrect permissions or a broken or missing link.

In my case, the log directory was not even a symbolic link. It was a standard NFS mount. As part of the initial troubleshooting, I verified that the directory existed , it has no symbolic links and confirmed that its permissions were correct.

I then googled for similar cases. Most of the blog posts and forum discussions focused on symbolic links, with many recommending the use of the hidden parameter _kolfuseslf, which allows symbolic links to be used in DIRECTORY object path names.

This recommendation stems from a security enhancement introduced in Oracle Database 18c. Starting with Oracle 18c, Oracle blocks the use of symbolic links by default for UTL_FILE, BFILE and External Tables to improve security. As a result, the hidden parameter _kolfuseslf is sometimes suggested as a workaround to restore the pre-18c behavior.

So I used a simple select to check whether it really has s symbolic link or not for Oracle.

SQL> SELECT DBMS_UTILITY.DIRECTORY_HAS_SYMLINK('EXPORT_DIR') FROM dual;
0

To be honest, the error message was quite misleading. 

After reviewing the Data Pump configuration more closely, I noticed that the export was running with PARALLEL=4. This turned out to be the key clue.

In an Oracle RAC environment, Data Pump distributes worker processes across available instances by default. (acts like CLUSTER=Y parameter is set) Although the export was initiated on one RAC node, some of the worker processes were scheduled on the second node.

The actual root cause was that the DIRECTORY object pointed to an NFS-mounted filesystem that was only accessible from the node where the export was started. When a worker process running on the second RAC node attempted to create or access a dump file, it could not reach the NFS mount. Instead of reporting a straightforward “directory not accessible from the remote instance” error, Data Pump produced a series of misleading errors related to symbolic links and missing files.

Once I understood what was happening, the solution in my case was simple: adding CLUSTER=N to the Data Pump parameter file forced all worker processes to remain on the local RAC instance, where the NFS mount was accessible. After making this change, the export completed successfully without any further errors.

CLUSTER=N

Another valid solution would have been to mount the NFS filesystem on all RAC nodes so that every Data Pump worker, regardless of which instance it ran on, could access the dump file location. This approach allows you to continue using clustered Data Pump exports with parallel workers distributed across the RAC environment.

Hope it helps.