Issue
The following error occurs after BLT imports configuration changes (typically after a blt setup or blt sync:refresh command)
Configuration in the database does not match configuration on disk
Resolution
The best immediate fix for this problem is to simply re-export configuration immediately after receiving this error: drush @foo.local config-export
This should capture the configuration changes that caused the test to fail, and allow subsequent site installs / config imports to succeed. Later versions of BLT (9.1.x and above) will automatically attempt to do this. However, you should still take steps to understand what caused this problem in the first place. While re-exporting overridden configuration will fix the immediate error, it may mask deeper problems (such as a missed database update).
In an emergency, you can also temporarily disable this test by setting cm.allow-overrides to true in blt/project.yml. However, this should not be considered a permanent fix. In order to ensure site stability, you should fully understand how this error occurred and resolve the configuration conflict.
Cause
Whenever BLT imports configuration changes (typically as the final step of a setup or sync:refresh command), it also verifies that the configuration was imported cleanly and completely. It does this by immediately re-exporting configuration and checking for any changes. Ideally, following a configuration import, the active configuration in the database and stored configuration on disk will be sync, and a subsequent re-export will produce no changes.
If active configuration and stored configuration is not in sync, this generally indicates a corrupt configuration export. BLT attempts to warn you about this potentially destructive situation by failing the configuration import and displaying an error message.
Most often, this error occurs due to one of two reasons.
First, this will happen if you have recently added a field to a content type, especially after you reinstall the site and try to import configuration related to the new field. This is due to a Drupal core bug, and will typically manifest itself as overrides to entity view mode files
core.entity_view_display.node.foo.teaser
A patch for that issue is now available, which you can apply to your own project until it is merged into core and/or applied by BLT/Lightning.
Second, this can be caused by updates to core or contributed modules that caused configuration changes that were not captured via a subsequent configuration export. Note that this is a problem with your particular application's update process, and not a problem with BLT. This problem, and a process for preventing it, is documented here: https://docs.acquia.com/blt/developer/configuration-management/#updating-core-and-contributed-modules