Description of problem:

As described in the KCS 6844091 and already discussed in slack:
https://coreos.slack.com/archives/CK1AE4ZCK/p1647878338011239
https://coreos.slack.com/archives/CK1AE4ZCK/p1655367192152449

Some customer are facing a mysterious deletion of the file /var/lib/containers/storage/overlay/backingFsBlockDev, blocking all new POD from starting.

The issue has been identified in several cases (the list is available at the bottom of the KCS) and is impacting multiple versions (cf table below)

The KCS 6844091 was updated to provide an easy fix: 

sudo podman info

 and the process to add an audit rule on the node is also described in the KCS.

Version-Release number of selected component (if applicable):

How reproducible:

It's easy to replicate the issue by removing the file */var/lib/containers/storage/overlay/backingFsBlockDev*, but this does not provide the root cause of the removal of the file in the customer clusters :) 

Steps to Reproduce:

1.
2.
3.

Actual results:

Pods scheduled on the impacted node(s) are stuck in 

Expected results:

The file */var/lib/containers/storage/overlay/backingFsBlockDev* should not disappear.
Would it be a permanent solution to include in the code the creation of the file when flagged as missing after warning about the absence of the file?

Additional info:

Related Bugzilla 2091214