This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nfragentd.log gets filled with error messages during FS scan

Hi,

We are seeing A LOT of error messages like this one in the nfragentd.log files (one scan can generate 4 full log files!):

less /var/opt/novell/filereporter/agent/log/nfragentd.log

01 2014-11-06 00:59:57 -18000 3 0006 43591 7f0f49bce700 SRSScanAndCollectFileSystemDataService::GetScanDataEntryMetaDataAndSecurityInfo() - Called AddSecurityPrincipalToInventory(L"SERVER", 32848, false), Scan ID = "982", Result = 15. {Cr
eator}

Is it something to worry about, or is it something benign like the owner of the file has been deleted from eDir? If it is benign, how can this be suppressed?

Also this seems to delay the scan, so resolving this would improve scan performance.
  • 0
    On 11/6/2014 9:46 AM, ablovatskia wrote:
    >
    > Hi,
    >
    > We are seeing A LOT of error messages like this one in the
    > nfragentd.log files (one scan can generate 4 full log files!):
    >
    > less /var/opt/novell/filereporter/agent/log/nfragentd.log
    >
    > 01 2014-11-06 00:59:57 -18000 3 0006 43591 7f0f49bce700
    > SRSScanAndCollectFileSystemDataService::GetScanDataEntryMetaDataAndSecurityInfo()
    > - Called AddSecurityPrincipalToInventory(L"SERVER", 32848, false), Scan
    > ID = "982", Result = 15. {Cr
    > eator}
    >
    > Is it something to worry about, or is it something benign like the owner
    > of the file has been deleted from eDir? If it is benign, how can this be
    > suppressed?
    >
    > Also this seems to delay the scan, so resolving this would improve scan
    > performance.
    >
    >

    ablovatskia,

    What sort of volume are you scanning, in this case?

    -- NFMS Support Team
  • 0 in reply to 
    Sorry, it is NSS volume on OES 11.2
  • 0 in reply to 
    On 11/6/2014 10:16 AM, ablovatskia wrote:
    >
    > Sorry, it is NSS volume on OES 11.2
    >
    >

    The error '15' here is simply an error saying the DS object in question
    could not be found. It's looking for an object named 'SERVER', which (if
    you're doing a file system scan, rather than a permissions scan) is set
    as the owner of the file system object in question. If that object no
    longer exists, this is perfectly normal behavior.

    -- NFMS Support Team
  • 0 in reply to 
    Interesting. SERVER is the server name (well it is actually something else that I replaced with word SERVER in my post).

    Correct me if I am wrong, but I believe that if the user object that created the file no longer exists, the SERVER owns the files on the NSS volume. Now, there is no user object SERVER in eDir by design, but there is an NCP object SERVER for example.

    I think it is a situation that nfragent should handle in a better way, e.g. cache the DS response/not try to resolve at all in the case of SERVER owning the file, rather then trying million times, throwing an error and slowing down the FS scan by hours. It is a normal situation for Novell environments to have files dating back a couple of decades when the original owners are no longer in the DS.