Daily scan scans no files on some computers

[Aaron Nelson]

On some computers, the daily scan will scan everything including mounted network drives.  On other computers, absolutely nothing gets scanned by the daily scan.  This is according to the logs on the SEPM.  I have tried reinstalling SEP on these computers, but it doesn't help.  What could cause such an issue?

[ℬrίαη]

Ideally, you'll want to enable additional logging to see what's being scanned:

http://www.symantec.com/docs/TECH103126

[Aaron Nelson]

Well, none of those instructions work on Linux clients.

However, I already had the vpdebug log enabled.  In fact, I have scripts running that parse and filter data from it.  The daily scan is not scanning anything on some computers.

[Rafeeq]

Hi Aaron,

Is it the full scan or quick scan when new defs arrive? Whats the SEP version here

Can you uinstall / reinstall on one machine to see if that works , this is an old thread where uninstall /reinstalled fixed the issue.

https://www.symantec.com/connect/forums/anyone-seeing-there-virus-definition-quick-scans-0-files-scanned

 

[Aaron Nelson]

As stated, the version is 12.x, but specifically, it is 12.1.6.

Also as stated in the original post, I have already tried reinstalling it.

The scan that fails is the daily scheduled scan (as stated), configured to run by default at 00:30 by the SEPM.  Whether or not it deserves to be considered a "full" scan is the issue.  My current project is testing to see how SEPFL handles mounted network drives with its daily scan.  The results so far appear wildly inconsistent and I have no explanation or pattern to describe what I am finding.  However, my initial concern is why some clients appear to not be scanning anything at all (network or local) when the daily scan runs.

[Rafeeq]

Hi Aaron,

Thanks for the info,  under scan settings File types, have you set it to Scan all files or Scan only selected extensions ?

The extensions are case-sensitive 

 

[Aaron Nelson]

• Scan all folders
• Scan all files
• Scan files inside compressed files
  • 3 levels of expansion
• Scan for security risks
• Scan daily at 00:30
• Retry within 24 hours if missed

 

[Matt Mc]

Hi Aaron,

If you've already collected vpdebug data during a scan where this issue occurred, I'd suggest collecting sadiag data from that same machine and then opening a case with Support.

http://www.symantec.com/docs/HOWTO111042

While offhand I'm unaware of any specific defect related to this, are you able to test with a newer build?  For the 12.1 series you'd ideally want to test with 12.1 RU6MP10 (12.1.7445.7000).  Thanks. 

[Aaron Nelson]

Haha, no.  I'm in a corporate environment, so I can't mess with the version of the software.

Admittedly, I'm a bit reluctant to open a case because the last time I did, the phone calls went around for hours (spread over several days) ending with Symantec not being allowed to give me the information I needed, and I can't allow people in India to remote in to a system that holds ITAR data.

[Matt Mc]

Aaron, if you would open another case and please post or PM me the case number, I can help to ensure it gets where it needs to.  Apologies for any past experiences with Support that weren't favorable. 

[Aaron Nelson]

I found a curious thing on most of the machines in question.  The users interact with programs run by a script which, among other things, starts an Xvnc server.  If they exit improperly, the Xvnc server stays running.  This causes their home directory to stay mounted (even after logging out).  Now, the home directories have root-squash from their machines; their machines are incapable of scanning their home directories since SEP runs as root.  There seems to be a correlation between home directories staying mounted and SEP not scanning things.  After closing out all of the unused Xvnc servers, all of the machines now report a non-zero number of files scanned by the daily scan to the SEPM (one machine in particular had been reporting zero files scanned for over a month!).  However, there are still mounted directories (without root-squash) that are going completely unscanned.  It is currently unclear to me why SEP would miss them.

[Aaron Nelson]

I just found the following article saying that Symantec has issues with root squash.

https://support.symantec.com/en_US/article.TECH150141.html

The issues I'm having occur only when a root-squashed directory is mounted.  However, sometimes a root-squashed directory seems to be causing the daily scan to finish prematurely.  This does not always happen, though.  Sometimes the scan runs fine and simply skips the root-squashed directories, but this seems to be the exception rather than the rule.

I am continuing to look into this behavior.

[Aaron Nelson]

I am concluding that the order in which SEP scans files varies from machine to machine.  I do not know why this is.  However, when this order causes the scan to attempt to read a file that it cannot view (this will be because it runs as root and is trying to view something not world-readable in a root-squashed directory), it will cause the entire scan to fail.

Root squash is a security feature which is built in to the Linux operating system.  It is the default security setting for mounting NFS partitions.  The fact that the default setting of a built-in feature causes issues with SEPFL, a program which is meant to improve security, is rather embarrassing.

 

Update:

In addition to root squash, directories mounted using Samba can also have issues that will cause root to be unable to read files or subdirectories.  This will likewise cause the scan to crash.

[Aaron Nelson]

The order in which Symantec scans files appears to be in directory order.  This order is basically whatever order the kernel feels like; it is not inherently defined.  See the following link.

https://utcc.utoronto.ca/~cks/space/blog/unix/ReaddirOrder

You may use ls -f or ls -U to show the order in which files will be scanned.