The customer has performed a fresh installation of DLP v11 or v12 Monitor/Prevent server and the Filereader service is failing to start correctly.
The following errors may be observed in the CE logs / ContentExtractionHost_FileReader.log:
11.0 related error:
09/26/11 13:19:21 | ERROR | cehost | main  |  | Interprocess exception caught while creating server shared memory with error message - Access is denied., Exception thrown from : ServerShmChannelImpl.cpp(92) | .\CEHostProcess.cpp (120)
12.0.1 related error:
08/26/14 17:13:50 | INFO | cehost | main  |  | Linux 12.0.1.01064 x86_64-Release, Process ID = 5013 | CEHostProcess.cpp (81)
08/26/14 17:13:50 | ERROR | cehost | main  |  | Interprocess exception caught while creating server shared memory with error message - Permission denied, Exception thrown from : ServerShmChannelImpl.cpp(86) | CEHostProcess.cpp (116)
08/26/14 17:13:50 | INFO | cehost | main  |  | Content Extraction Host process exited | CEHostProcess.cpp (118)
You should check the following items :
- Confirmed SELinux has been disabled.
- Checked that mandatory directories and permissions are correct for the "protect" and "protect_update" user accounts.
- That the user profiles for the "protect" and "protect_update" account have been created.
- Try setting a password for the "protect" and "protect_update" accounts and verify that you can login as those account. Make sure you update the password for the Vontu Monitor service if you do this.
In some cases some level of OS hardening has been performed via group policies or similar, this can prevent the profile for the "protect" user from getting created correctly which in turn will cause filereader to fail. The solution is to make the "protect" user a member of the local administrators group for the first startup of the Vontu Monitor service. This will allow the profile to be created correctly, thereafter the "protect" user can be removed from the local administrators group.
On Linux based systems the following should be checked as a possible cause :
- Confirm that /dev/shm is mounted via tmpfs in /etc/fstab not ramfs