I'd like a way to let Trivy ignore "FATAL ... no such file or directory" errors.

[jerrac]

Description

I'd like a way to let Trivy ignore "FATAL ... no such file or directory" errors.

I've run into that error ending Trivy's scan multiple times. Both when using 'fs' and 'rootfs'. (Ubuntu 22.04 with Trivy installed from your apt repos.)

Since the files causing the error are always in directories I expect to have changing data, I'm guessing that Trivy is getting a list of files, then scanning each file in turn. And when one of the files has gone away, it throws a fatal error.

I see similar issues here:

• Trivy 0.51.0 rootfs scan throwing FATAL during vuln scan on root directory #6624
• Scanning '/' fails occasionally with "no such file or directory" #3811

Since neither seem to have any conclusions, I'm not sure if this is a bug, or behavior that is intentional.

So, if this is a bug, I'd love to see it fixed.

If it is intentional, then can we have a way to override it?

Or, maybe just an explanation of why Trivy behaves this way?

Thanks!

Target

None

Scanner

None

[DmitriyLewen]

Hello @jerrac

I think it is better to avoid scanning directory with changing files:

• you can get error (but in this case you will know that this directory contains removed file and will be able to take some action for this directory)
• but more dangerous case - when file has been added after start of scanning. In this case user may think that this directory doesn't have vulnerabilities, although new file contains vulnerability.

Some users ignoring logs, so we have only one way to draw attention on this dir - to return error.

But users periodically write about this error.
Maybe we should move this error to logs and not stop scanning.

@knqyf263 wdyt?

[knqyf263]

First of all, we should exit on unexpected errors. Otherwise, the result can differ on each run, confusing users with inconsistent results. We should figure out why it happens and fix it.
However, if this is an expected and unavoidable error for a particular user, it is reasonable to add options such as --ignore-walk-error or --ignore-fs-error.

Anyway, we should start by reproducing this error.

[jerrac]

For reproducing the error, would writing enough random files to a directory that it takes Trivy enough time to scan it that we could start the scan, then go remove files until Trivy throws an error?

I do see why you would want to bring attention to a file going missing. And I think leaving that as the default behavior is probably correct.

But if the folder is expected to have files change, but you still want to check for vulnerabilities in it, there needs to be a way to keep scanning it. Skipping it entirely would mean you don't ever detect problems in it.

Maybe a couple options? --warn-on-missing= and --always-warn-on-missing, where --warn-on-missing is a list of directories like --skip-dirs that causes Trivy to only emit a warning message when a subdir/file in those directories is missing, and --always-warn-on-missing does the same for all directories?

That way, the first time a user runs into the issue, they see the fatal error and then can decide if it is ok to override that or not. And with the two options, we have the option of a quick and dirty fix, or taking the time to only override specific directories. And the warning message can be logged for later investigation.

BTW, thanks to every one who has replied! :)

[knqyf263]

@afdesk Please let us know if you find a way to replicate the error easily.

[afdesk]

@afdesk Please let us know if you find a way to replicate the error easily.

sure.
but now I can reproduce it only for k8s, because yaml files are created and removed inside the run.

[afdesk]

Hi guys!
It seems I was wrong that there is a some common problem,
#7684 and aquasecurity/trivy-action#404 have different reasons with the same output.
sorry for misunderstanding

[matjohnston-r7]

Hi, Seen this discussion and wanted to +1 @jerrac's request. I am seeing this error for a lot of different directories and there is too many to list using --skipp-dirs and --skip-files.

As mentioned an option to log the error and continue the scan would be a great addition 👍