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.
Summary: File Reader failed to start
Detail: Error starting File Reader. /opt/SymantecDLP/Protect/lib/native/libcontentextractionjni-14.5.0.so: libboost_thread-gcc49-mt-1_54.so.1.54.0: 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.
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:
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: