Error Code 1302 received after upgrading to DLP 14.x or 15.x
search cancel

Error Code 1302 received after upgrading to DLP 14.x or 15.x


Article ID: 163773


Updated On:


Data Loss Prevention


After upgrading to DLP version 14.5, deleting the upgrade resources directory (i.e. /opt/SymantecDLP/Protect/upgrades/<folder_name>) causes symlinks to break for libraries that DLP is dependent on.  This will prevent File Reader from starting until the deleted directory structure is recreated.
You may see Error Code 1302 after upgrading to DLP 14.5 or later.

Code: 1302
Summary: File Reader failed to start
Detail: Error starting File Reader. /opt/SymantecDLP/Protect/lib/native/ cannot open shared object file: No such file or directory No incidents will be detected.

NOTE: This can be different than 14.5.0 for later versions.


Oct 3, 2016 10:25:18 PM com.vontu.messaging.FileReaderSetup initialize
SEVERE: (DETECTION.3) Failed to initialize Detection
java.lang.UnsatisfiedLinkError: /opt/SymantecDLP/Protect/lib/native/ cannot open shared object file: No such file or directory
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(
    at java.lang.ClassLoader.loadLibrary(
    at java.lang.Runtime.load0(
    at java.lang.System.load(
    at com.vontu.cracker.jni.JniLoader.loadLibrary(
    at com.vontu.cracker.jni.NativeObject.<clinit>(
    at com.vontu.cracker.jni.EngineContext.<init>(
    at com.vontu.cracker.NativeExtractionEngine.<init>(
    at com.vontu.cracker.NativeExtractionEngine.<init>(
    at com.vontu.detection.ExtractionEngineFactoryLoader.loadExtractorFactory(
    at com.vontu.messaging.FileReader.initializeContentExtractionServices(
    at com.vontu.messaging.FileReader.initializeContentExtractionServices(
    at com.vontu.messaging.FileReader.start(
    at com.vontu.messaging.FileReaderSetup.initialize(
    at com.vontu.messaging.FileReader.main(
Oct 3, 2016 10:25:18 PM com.vontu.logging.LocalLogWriter write
SEVERE: File Reader failed to start. Error starting File Reader. /appvg/dlp/Protect/lib/native/ cannot open shared object file: No such file or directory No incidents will be detected.



This phenomenon only impacts Linux systems that have been upgraded to DLP version 14.x or 15.x.  This can impact Enforce servers and Detection servers.


Per the Symantec DLP 14.5 Upgrade Guide for Linux, steps on page 32 and page 34 indicate that the root upgrade scripts should be run after upgrade has completed on Enforce and Detection servers.  These root upgrade scripts create symlinks for depency libraries that DLP 14.5 needs to function in a Linux environment.

In DLP version 14.5, these root upgrade scripts replace a file called "symantec-dlp-x86_64.conf" as seen in example snippet:

# This is to update the file we create.  It can only be updated by root so cannot be in any other part of the upgrader.
rm -rf /etc/
echo -e "/opt/SymantecDLP/Protect/updates/update-id-52/../../../Protect/lib/native/\n/opt/SymantecDLP/Protect/updates/update-id-52/../../../Protect/plugins/contentextraction/ImageExtractorPlugin/x86_64\n/opt/SymantecDLP/Protect/updates/update-id-52/../../../Protect/plugins/contentextraction/Verity/x86_64\n/opt/SymantecDLP/Protect/updates/update-id-52/../../../jre/lib/amd64/server/" > /etc/

As you can see in this example, the root upgrade script is creating a new "symantec-dlp-x86_64.conf" file which includes references to a relative path for the /opt/SymantecDLP/Protect/updates/update-id-52 directory.

It is not uncommon for system administrators to delete the upgrade resource folder (i.e. the "update-id-52" directory in this example) to save disk space after an upgrade.  Removing or modifying this directory structure will break the symbolic links being referenced in the symantec-dlp-x86_64.conf file.


If this directory structure is modified or deleted, then the workaround here is to simply recreate the folder name that was used at time of the upgrade.  The following steps can be used to determine the folder name and recreate it as needed:

  1. Log on to the Linux server in question and launch Terminal
  2. Run the following command to view contents of the existing symantec-dlp-x86_64.conf file:

    [root@rhel-enforce ~]# cat /etc/
  3. The output will show the relative paths being used by the symbolic links, for example:

    [root@rhel-enforce ~]# cat /etc/


    NOTE: The update-id-52 will be different for different versions, so see what is in the "symantec-dlp-x86_64.conf" file folder for the update folder and make sure to use the same naming structure.
  4. Run the following command to recreate the directory structure as shown in the above output:

    [root@rhel-enforce ~]# mkdir /opt/SymantecDLP/Protect/updates/update-id-52
  5. (Optional) Set the appropriate permissions for the "protect" user for DLP on this folder, run command:

    [root@rhel-enforce ~]# chown protect:protect /opt/SymantecDLP/Protect/updates/update-id-52
  6. Rerun Postupgrade script
  7. Be sure to restart DLP services for this change to take effect