Mismatched entity and/or field definitions for File 'type' field after updating to Drupal 8.4

probably is. in 8.4.x the core developers decided to rename a contrib module called media entity (not 100% sure what it was called?) and take over the media namespace with a module other than the original media module that originally spawned off file_entity. This new media namespace is in 8.4.x core probably causing a lot of conflicts between the original media module and the file_entity modules.

You might have to convert your file_entity data so that you can use it with 8.4.x.

@joseph.olstad - What do you mean by "convert your file_entity data so that you can use it with 8.4.x"?? I'm assuming you mean to convert the File fields to Media Entity fields. Any resources on how to do that? That's something we haven't done before.

Same issue here as gmaxwelled has explained. No idea how to fix it.

Updating the title for clarity.

One thing people should try is running drush entup to try to manually run the updates. Some people have reported that that resolves all but this error for them, but worth a shot.

To my knowledge, the core Media namespace and its conflict with Media Entity should have no impact on File Entity itself. However, sites using contrib Media Entity 8.x-1.x should not enable the core Media module (and in fact will be prevented from doing so). An upgrade path that will convert media to the core API is being worked on in the 8.x-2.x branch of Media Entity.

See the Media Entity project page and the FAQ on the contrib-to-core upgrade

In my case Media in core _is_ disabled and media_entity 1.x is enabled, the error persists.

So this isn't a case (as far as I can tell) of conflict between core media and media entity but a problem between file_entity and Drupal 8.4

We run several test installs on our testing servers here in the last days to tackle down this issue any further. All suggested work arounds in the net do not match here on the File 'type' field specific one (Drush entup etc). After some different scenarios and the try to check what happens if file_entity gets uninstalled later afterwards, we have interesting error output on Drush terminal:

$ drush pmu file_entity -y
The following extensions will be uninstalled: file_entity
Do you really want to continue? (y/n): y
exception 'Drupal\Core\Field\FieldException' with message 'Attempt to create a field field_image_alt_text that does not exist on entity type file.' in /var/www/html/drupal/core/modules/field/src/Entity/FieldConfig.php:293                                    [error]
Stack trace:
#0 /var/www/html/drupal/core/modules/field/src/Entity/FieldConfig.php(205): Drupal\field\Entity\FieldConfig->getFieldStorageDefinition()
#1 /var/www/html/drupal/core/lib/Drupal/Core/Entity/EntityStorageBase.php(357): Drupal\field\Entity\FieldConfig::preDelete(Object(Drupal\field\FieldConfigStorage), Array)
#2 /var/www/html/drupal/core/lib/Drupal/Core/Entity/Entity.php(385): Drupal\Core\Entity\EntityStorageBase->delete(Array)
#3 /var/www/html/drupal/core/lib/Drupal/Core/Config/ConfigManager.php(203): Drupal\Core\Entity\Entity->delete()
#4 /var/www/html/drupal/core/lib/Drupal/Core/Extension/ModuleInstaller.php(395): Drupal\Core\Config\ConfigManager->uninstall('module', 'file_entity')
#5 /var/www/html/drupal/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(91): Drupal\Core\Extension\ModuleInstaller->uninstall(Array, true)
#6 phar:///usr/local/bin/drush/commands/core/drupal/environment.inc(227): Drupal\Core\ProxyClass\Extension\ModuleInstaller->uninstall(Array)
#7 phar:///usr/local/bin/drush/commands/core/drupal/pm_8.inc(79): drush_module_uninstall(Array)
#8 phar:///usr/local/bin/drush/commands/pm/pm.drush.inc(1250): _drush_pm_uninstall(Array)
#9 [internal function]: drush_pm_uninstall('file_entity')
#10 phar:///usr/local/bin/drush/includes/command.inc(422): call_user_func_array('drush_pm_uninst...', Array)
#11 phar:///usr/local/bin/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#12 [internal function]: drush_command('file_entity')
#13 phar:///usr/local/bin/drush/includes/command.inc(199): call_user_func_array('drush_command', Array)
#14 phar:///usr/local/bin/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#15 phar:///usr/local/bin/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#16 phar:///usr/local/bin/drush/includes/startup.inc(458): drush_main()
#17 phar:///usr/local/bin/drush/includes/startup.inc(365): drush_run_main(false, '/', 'Phar detected. ...')
#18 phar:///usr/local/bin/drush/drush(114): drush_startup(Array)
#19 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#20 {main}

After repeating the command a second time ...

$ drush pmu file_entity -y
The following extensions will be uninstalled: file_entity
Do you really want to continue? (y/n): y
file_entity was successfully uninstalled.

... the uninstall runs flawlessly now, without any errors, but the status error message "Mismatched entity" remained. After running Drush entup now, the status error message finally disappeared.

@diqidoq
Thanks for the infos. But as bdeclerc said in #8, uninstall file_entity is not a option for us. It's on a productive website. So i guess uninstall file_entity will end with lost data.

@handkerchief:
As stated already in the beginning of my comment: It was not a recommendation nor a suggested work-around. It was a report from testing scenarios of what happens afterwards and about the error messages which are following, since it can help to tackle down the issue. Just an investigational info, since this issue is no support request but a bug report and all contribution is regarding fixing the bug.

Fixing metadata. I closed #2914893: 'Mismatched entity and/or field definitions' for File 'type' field won't resolve after update from 8.3.7 to 8.4.0 as a duplicate of this issue.

Thanks for helping so far. But what now? :)

Is this major or is this critical?

From https://www.drupal.org/core/release-cycle-overview:
November 15, 2017 First security window for 8.4.x (disclosure of 8.3.x security issues without backport)

Is this actually a real issue? Or is just a false positive? Something that is triggering Drupal into thinking it needs an update, but it actually doesn't?

Because I've installed fresh D8.4's and getting this message (entity-updates does not fix it) but everything still works fine.
Also did an update from 8.3. to 8.4 and everything still works (but the message persists)

I would also like to know whether it is safe to use the module or not?

Just updated from 8.3.7 to 8.4 and am experiencing this same issue.
Drush (~9.0) entity-update had no effect.

Hoping for a definitive answer soon.

Updated from 8.3.7 to 8.4. I got an error like,

Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.

Paragraph

The Published field needs to be updated.
The Behavior settings field needs to be updated.

There were many errors that come in between the development for several fields like this. When I edit those fields and update the settings, errors will fix.

But this case, published and Behaviour settings fields can't be edited.

As per the attached screenshots, the issue with field_flag has been resolved, when I just updated the storge settings for that field. Let me know how to fix the issue with published and Behaviour settings fields?

Thanks,
Deepak R.

@deepak_zyxware, your problem seems to be about the paragaph module. You should file an issue in the paragraph module issue queue.

@gaele, It's not the issue with the paragraph module. It may be an issue with https://www.drupal.org/project/inline_entity_form module. I don't find any reason to assume that, the issue is with paragraph module.

As the discussions were happening here, just updating my findings. Those who uses Inline entity form just run the following Drush command.

drush entity-updates

Thanks,
Deepak R.

Please refrain from deviating the thread from the OP.

For those who may have been confused, 'drush entity-updates' does not appear to correct the mismatched entity field error others have experienced with this module.

I'm experiencing this same issue, unfortunately there is no way I can uninstall File Entity module, there is a lot of files from client already.

I'm seeing the same issue here ... after updating from 8.3.7 to 8.4.2 and updating and uninstalling the Media Entity Module so my site runs on the new core Media Module ... I get the following error

file entity type :
  Das Feld Dateitypen muss aktualisiert werden.
paragraph entity type :
  Das Feld Published muss aktualisiert werden.
  Das Feld Behavior settings muss aktualisiert werden.

running "drush entup" fixes the paragraph issue but the file entity issue remains.

Same issue here from 8.3.7 to 8.4.2.
I also get these log messages:
Notice: Undefined index: revision_translation_affected in Drupal\Core\Entity\Sql\SqlContentEntityStorage->loadFromSharedTables() (line 596 of /core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php)

Edit: #54 works, thanks :)

Small piece of the puzzle.
If you run 'drush entity-updates', 'file entity type' will indicate

The following updates are pending:
file entity type : 
  The File type field needs to be updated.
Do you wish to run all pending updates? (y/n)

When you select Y it indicates that it has finished performing the update.
However in Drupal status report it still states

Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
File
The File type field needs to be updated.

But, If you go back and rerun Drush entity updates it still indicates that same update.
You can run it any number of times and it won't take. (even though it indicates completion)

Also I noticed many of the following messages in Drupal's recent log messages.
Don't know where it gets the invalid Location address.

Type 	views
Date 	Friday, November 10, 2017 - 08:47
User 	Anonymous (not verified)
Location 	http://default/
Referrer 	
Message 	A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): field name: comment_body, bundle: comment_node_rental_property_documents
Severity 	Error
Hostname 	127.0.0.1

All messages are the same except for the name of the bundle. (e.g. bundle: comment_node_SOME_FIELD_NAME)

By digging into the code that looks for changes/required updates (SqlContentEntityStorageSchema::requiresFieldStorageSchemaChanges), I was able to dump the two versions of the file type field schema that are being compared:

Array
(
    [file_managed] => Array
        (
            [fields] => Array
                (
                    [type] => Array
                        (
                            [description] => The ID of the target entity.
                            [type] => varchar_ascii
                            [length] => 32
                            [not null] => 1
                        )

                )

            [indexes] => Array
                (
                    [file_field__type__target_id] => Array
                        (
                            [0] => type
                        )

                )

        )

)

Array
(
    [file_managed] => Array
        (
            [fields] => Array
                (
                    [type] => Array
                        (
                            [description] => The ID of the target entity.
                            [type] => varchar_ascii
                            [length] => 32
                            [not null] => 
                        )

                )

            [indexes] => Array
                (
                    [file_field__type__target_id] => Array
                        (
                            [0] => type
                        )

                )

        )

)

It looks like the file type field schema has changed very slightly -- it's reporting that one version requires the field to be NOT NULL, and the other doesn't. This key is probably required for file_entity, since it's the bundle key.

I think that "current" refers to the current in-code field storage definition; in this case that would come from FileEntity::baseFieldDefinitions(). And then maybe "original" refers to the schema definition stored in Drupal's key_value store.

In my database, the type field is NOT NULL already:

mysql> show create table file_managed\G
*************************** 1. row ***************************
       Table: file_managed
Create Table: CREATE TABLE `file_managed` (
  `fid` int(10) unsigned NOT NULL AUTO_INCREMENT,
  ...
  `type` varchar(32) CHARACTER SET ascii NOT NULL COMMENT 'The ID of the target entity.',
  ...

So I'm not exactly sure what needs to change to make this error go away, but it seems unlikely that files will get inserted without a 'type' while the file_entity module is installed, so this particular difference probably isn't going to be fatal.

The last part of this seems relevant. The link gives you the whole bit, but basically confirms #26.

Here's the part you probably care about (this is after installing file_entity, uninstalling, reinstalling, and attempting to uninstall again):

$ drush entity-updates
The following updates are pending:

file entity type :
  The File type field needs to be updated.
Do you wish to run all pending updates? (y/n): y
Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. SQLSTATE[42S22]: Column[error]
not found: 1054 Unknown column 'type' in 'where clause': SELECT 1 AS expression
FROM
{file_managed} t
WHERE type IS NOT NULL
LIMIT 1 OFFSET 0; Array
(
)
 in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1513 of
/apps/drupal/d8root/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Failed: Drupal\Core\Entity\EntityStorageException: !message in                                                       [error]
Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1513 of
/apps/drupal/d8root/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Cache rebuild complete.                                                                                              [ok]
Finished performing updates.

confirmed, I have the same

[error] Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. SQLSTATE[42S22]: Column not found: 1054 Unknown column 'type' in 'where clause': SELECT 1 AS expression
FROM
{file_managed} t
WHERE type IS NOT NULL
LIMIT 1 OFFSET 0; Array
(
)

I have the same problem : I use file_entity module and I migrate from 8.3.7 to 8.4.2. I got error File type entity must be updated. Running and running and running drush command again do nothing,

Regarding #26, I digged into code and found something :

in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema:requiresFieldStorageSchemaChanges()

$current_schema = $this->getSchemaFromStorageDefinition($storage_definition);
$this->loadFieldSchemaData($original);

For field "type" in table file_managed. $current_schema will return :
$current_schema['file_managed']['fields']['type']['not null'] = true;
Second line will return :
$current_schema['file_managed']['fields']['type']['not null'] = false;

The two line will look into database :
SELECT name, value FROM key_value WHERE name IN ( 'file.field_schema_data.type' ) AND collection = 'entity.storage_schema.sql';

which return as value :
a:1:{s:12:"file_managed";a:2:{s:6:"fields";a:1:{s:4:"type";a:4:{s:11:"description";s:28:"The ID of the target entity.";s:4:"type";s:13:"varchar_ascii";s:6:"length";i:32;s:8:"not null";b:0;}}s:7:"indexes";a:1:{s:27:"file_field__type__target_id";a:1:{i:0;s:4:"type";}}}}

to see : s:4:"type" .... "not null";b:0 meaning type field has not null = false.

So why the first line ($current_schema) is returning not null = true ?

line 1703 (Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema) :

// @todo Fix this in https://www.drupal.org/node/2841291.
    $not_null_keys = $this->entityType->getKeys();

getKeys() will return array containing 'type' as key. Meaning that column which are key are set to "not null = true".

I do not dig enough to try to understand why change are not done in database (alter table to set column not null).

#30 andypost : I do not think that the #2925550 issue has relation to this problem. Regarding #26 (which is the same as my debug), there is not 'initial' or 'initial_from_field' keys in the field schema which has the problem.

Anyway, I tried the patch in #2925550 without success. Field type in file_managed table still appears as changed (the problem is on the "not null")

I found that there is a difference when looking for change, and when applying change.

In short: when looking for change, not null are different. When applying change, not null are the same.

This line in SqlContentEntityStorageSchema (1707) do the change :

$not_null_keys = $this->entityType->getKeys();

Each time change are looked for, original_schema is loaded from database through loadFieldSchemaData(), and current_schema is loaded from database through getSharedTableFieldSchema() in which $not_null_keys are calculated.

But When looking for change, entityType->class is Drupal\file_entity\Entity\FileEntity
And when applying for change, entityType->class is Drupal\file\Entity\File

Because keys['bundle'] == 'type' when class is file_entity, then not_null is set to true.

Because keys['bundle'] is empty when class is file, then not_null is not changed : Then line 1465 $not_null and $original_not_null are identical. No changed are done.

Now, the question is : why are the class in entityType different ?

When looking for change, entityType->class is set from DefaultPluginManager->getDefinitions() (this code is looking for definitions in php class files).

When applying change, entityType->class is retrieve from database thought SQL command :

SELECT name, value FROM key_value WHERE name IN ( 'file.entity_type' ) AND collection = 'entity.definitions.installed';

It's clearly a bit difficult for me to understand all things. I will stop digging into code to try to understand why there is the problem.

My solution/workaround :

I changed values directly from database :

changed the table type column :
alter table file_managed modify `type` varchar(32) CHARACTER SET ascii NOT NULL COMMENT 'The ID of the target entity.';

set not_null = true in key_value table :
update key_value set value = replace (value, '"not null";b:0', '"not null";b:1') where name="file.field_schema_data.type";

Then drush entup return : no entity schema updates required.

So, what is the definitive fix for this nagging and annoying problem?

So ...

Running the SQL commands in #32 fixed this problem.

There seem to be many different problems reported here.

#2925550: Fields with a manually defined initial value in the schema have an Entity schema definition mismatch after updating to Drupal 8.4 is definitely related, file_entity is one of the modules where I noticed the initial mismatch (beside paragraphs) and it fixed it for me. But it will only help for people where drush entup *worked* because it's not a real change, just an incorrect report.

I haven't seen a not null related problem on any of my sites using file_entity, just tested another where that patch worked fine.

@Berdir I faced with "not null" issueonly once on d8 sites and manual update of table helped

The patch of the issue #2925550: Fields with a manually defined initial value in the schema have an Entity schema definition mismatch after updating to Drupal 8.4 doesn't work for me. I have no error but the entity update is always uneffective.

I applied the patch in: #2925550: Fields with a manually defined initial value in the schema have an Entity schema definition mismatch after updating to Drupal 8.4, but it did not resolve the issue. I have also run the SQL commands in #32, and that did not resolve the issue for me either. Running drush entup returned:

"Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
File: The File type field needs to be updated."

I uninstalled the File Entity module to resolve my issue.

I was able to reproduce this with some of the following steps:

1. Install 8.4.0 and file_entity.
2. Update to 8.4.x HEAD.
3. Run drush updb.

At this point, the type column switches from NOT NULL to NULL. So somehow the update manager incorrectly changes this. Updating the column as per #32 and then running entity-updates reliably triggers this.

Applying #2841291: Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field makes these issues go away, so at some point this will probably be a non-issue.

git checkout 8.4.0 && drush si testing -y && drush en file_entity -y
mysql> describe file_managed;
+----------+---------------------+------+-----+---------+----------------+
| Field    | Type                | Null | Key | Default | Extra          |
+----------+---------------------+------+-----+---------+----------------+
| type     | varchar(32)         | NO   | MUL | NULL    |                |
+----------+---------------------+------+-----+---------+----------------+
...

drush entity-updates
The following updates are pending:

file entity type :
The File type field needs to be updated.

 Do you wish to run all pending updates? (yes/no) [yes]:

mysql> describe file_managed;
+----------+---------------------+------+-----+---------+----------------+
| Field    | Type                | Null | Key | Default | Extra          |
+----------+---------------------+------+-----+---------+----------------+
...
| type     | varchar(32)         | YES  | MUL | NULL    |                |
+----------+---------------------+------+-----+---------+----------------+

Thanks Sam152, that is a lot of useful information.

Does it mean it only happens when installing with 8.4.0 and not with 8.3.7? Or is 8.4.x-dev the relevant, so updating from 8.3.7 to 8.4.x-dev also fails?

Good to know that the core issue solves this (we should make sure to reference this issue there and I'm wondering if it should be critical then?) but that issue just makes it possible to run such an update, it doesn't explain what exactly causes the difference in the first place. I'm not sure yet if that is a bug in this module or in core.

@Berdir
I upgraded a site from 8.2.3 to 8.4.3, where file_entity was already installed and I have this problem, so it's not just installing 8.4.0.

so .. I'm updating a multi site environment and after many attempts I'm not seeing the error any more so it could be the 8.4.3 update fixed the bug

Step 1: only update Drupal from 8.3.7 to 8.4.3
Step 2: update any non media_entity modules

note: I'm still having a lot of issues regarding the media entity updates so I advise anyone updating to do them one by one to pinpoint the exact issues

#32 works for me on Drupal 8.4.0. Thx to blink38 !

For me, the error did *not* go away in 8.4.3, and the db commands in #32 *did* remove the error (me too thanks @blink38).

Edit: Now discovering I did not get the error on prod, where I jumped from 8.3.7 -> 8.4.3.
I only got the error on local where I went through earlier versions of 8.4, not sure which 8.4.x I began with that resulted in the error.

I get following error when I run 'drush entity-updates`

'WATCHDOG: [ERROR] [update] Drupal\Core\Entity\Exception\FieldStorageDefinitionUpdateForbiddenException: The SQL storage cannot change the schema for an existing field (field_ua_aaa_pqa_comment in node entity) with data. in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->updateDedicatedTableSchema() (line 1343 of /web/app/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php). | user: anonymous | uri: http://default/ | referer:
Drupal\Core\Entity\Exception\FieldStorageDefinitionUpdateForbiddenException: The SQL storage cannot change the schema for an existing field (field_ua_aaa_pqa_comment in node entity) with data. in [error]
Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->updateDedicatedTableSchema() (line 1343 of /web/app/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php).
Failed: Drupal\Core\Entity\Exception\FieldStorageDefinitionUpdateForbiddenException: !message in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->updateDedicatedTableSchema() (line 1343 of [error]
/web/app/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php).'

In admin, under status report it keeps showing 'Mismatched entity and/or field definitions'. Pls see attached.

I tried all the solutions mentioned above but nothing resolved the issue.
#32 'alter table' gave error 'Error in query (1054): Unknown column 'type' in 'file_managed'
#30 patch did not work.
#40 patch did not work.

Any help on this would be highly appreciated.

Thanks

Applying the SQL queries in #32 worked for me. Thanks blink38

Duplicate post

#32 worked for me on Drupal 8.4.4.

Thanks @blink38

Confirming that #32 worked for me on Drupal 8.4.4 as well. The first command affected 0 lines, the second affected 1 line. drush entup no longer shows any issues, neither does the status report.

After tinkering with this issue I determined I could work around the problem by upgrading D8.3.7 to D8.4.4 by itself. After a successful update, update file_entity.

When updating simultaneously I run into the entity problem. When updated separately (D first), all seems well.

#32 worked for me. Cheers!

#32 worked for me on Drupal 8.4.4 as well. Until then, running "drush entup" had no effect, now I see no issues.

Thanks to #32, managed to get this resolved. I noticed that the "fix" was directly altering state, which should typically be handled by State API. Here's how we deployed the fix in an update hook:

/**
 * Fix File Entity warning message.
 */
function mymodule_update_8102() {
  // Fix File entity warning per https://www.drupal.org/project/file_entity/issues/2914935#comment-12355272
  $key_value = \Drupal::keyValue('entity.storage_schema.sql');
  $key_name = 'file.field_schema_data.type';
  $storage_schema = $key_value->get($key_name);
  $storage_schema['file_managed']['fields']['type']['not null'] = 1;
  $key_value->set($key_name, $storage_schema);
}

If #54 works, is it possible to get that added as an update hook for file_entity module and roll that into a new release?

Since this shows up as a bright red error on the status report page, it would be great to get this fixed for everyone without needing to manually run mysql queries.

#54 worked for me

Can now finally reproduce this reliably with 8.5.0 too. Here is a patch that fixes it for me. I plan to commit this soon, so we can do a new releiase that is compatible with 8.5.

I also tracked the problem down why it happend because we actually have a test fail now in 8.5 related to the installation.

This updates it to use new API's available in 8.4+ for the initial field, removing the custom storage schema class and updating the last installed entity type definition so that it has the key when installing the field.

I also updated some deprecated usages that require 8.5+, somehow those didn't go away locally. That means file_entity now requires 8.5+, added the info.yml dependency info for that.

Committed.

Will prepare a new release after some additional manual testing.

Using the dev release of file_entity (bad idea, i know) and after updating to this commit (0ee2bd0) from a quite recent one (744e5b8) we're getting this error when running drush updb for file_entity module update 8004 - Fix entity field mismatches on the file type field.

Argument 2 passed to                                                     [error]
Drupal\Core\Entity\Sql\SqlContentEntityStorage::requiresFieldStorageSchemaChanges()
must implement interface
Drupal\Core\Field\FieldStorageDefinitionInterface, null given, called
in /var/www/stage/web/modules/contrib/file_entity/file_entity.install
on line 149 and defined SqlContentEntityStorage.php:1410
Argument 2 passed to                                                     [error]
Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema::requiresFieldStorageSchemaChanges()
must implement interface
Drupal\Core\Field\FieldStorageDefinitionInterface, null given, called
in
/var/www/stage/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php
on line 1411 and defined SqlContentEntityStorageSchema.php:208
PHP Fatal error:  Call to a member function hasCustomStorage() on null in /var/www/stage/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php on line 212
Drush command terminated abnormally due to an unrecoverable error.       [error]
Error: Call to a member function hasCustomStorage() on null in
/var/www/stage/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php,
line 212

That's... super weird. If you run drush entup before running that update, does it report anything as missing? According to that, the type field was never properly installed, which should mean that your installation is completely borked..

For my part, I have this error:

file_entity module : 
  8004 -   Fix entity field mismatches on the file type field. 

Do you wish to run all pending updates? (y/n): y
SQLSTATE[01000]: Warning: 1265 Data truncated for column 'type' at row 1246: ALTER TABLE {file_managed} CHANGE `type` `type` VARCHAR(32) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL   [error]
COMMENT 'The ID of the target entity.'; Array
(
)

Performing file_entity_update_8004                                                                                                                                                               [ok]
Failed: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'type' at row 1246: ALTER TABLE {file_managed} CHANGE `type` `type` VARCHAR(32) CHARACTER SET ascii COLLATE ascii_general_ci NOT[error]
NULL COMMENT 'The ID of the target entity.'; Array
(
)

Cache rebuild complete.                                                                                                                                                                          [ok]
Created three snippet files based on configuration.                                                                                                                                              [status]
Finished performing updates.                                                                                                                                                                     [ok]

The command drush entity-updates still doesn't work. I'm investigating.

UPDATE: The first file entity registered in my database have no type assigned, so its value is NULL. After have corrected that with a update query, the hook_update works properly.

What does select distinct type from file_managed show you? On a database *before* the update. That sounds like you have values longer than 32 characters in there which should not be possible.

The problem was the first entity_file registered in the database (very long time ago). After corrected it, the hook_update works.

My issue seems similar. Any suggestions?

Ran:

drush entup

The following updates are pending:

file entity type :
  The File type field needs to be updated.

 Do you wish to run all pending updates? (yes/no) [yes]:
 > yes

 [success] Cache rebuild complete.
 [success] Finished performing updates.

Then:

drush updb


file_entity module :
  8004 -   Fix entity field mismatches on the file type field.


 Do you wish to run all pending updates? (yes/no) [yes]:
 > yes

 [notice] Executing file_entity_update_8004
 [error]  SQLSTATE[22004]: Null value not allowed: 1138 Invalid use of NULL value: ALTER TABLE {file_managed} CHANGE `type` `type` VARCHAR(32) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL COMMENT 'The ID of the target entity.'; Array
(
)

For my part, I looked which file entities have a type NULL. You could listed that with a simple SQL query
SELECT fid, filename, filemime, status, type from file_managed where type IS NULL;

For our part, the type is required (I don't know if the module allows to doesn't inform a type). To fix the problem, I add a hook_update in a custom module to update the type of the file:

function my_module_update_8007() {
  \Drupal::database()->update('file_managed')->fields(["type" => "image"])->isNull("type")->execute();
}

Here, the code is very simple, you can do something more complicated if you need. Additionnally, to be sure this hook_update is executed before the hook_update of file_entity, I add a hook_update_dependencies()

function my_module_update_dependencies() {

  // Corrected errors in the database before execute the update 8004 of file_entity.
  $dependencies['file_entity'][8004] = [
    'my_module' => 8007,
  ];

  return $dependencies;
}

I hope this will help you.

Thanks Calystod, your comment helped to find and fix the issue!

I had a file uploaded using module editor_file which had NULL under column type on file_managed.

I've recently updated a site from 8.0.1 to 8.5.5 and get this error, have the latest version 8.x-2.0-beta6 that looks to have this patch, unfortnatly the error still shows.

I'm also still seeing this on drupal 8.5.6 and with file-entity 8.x-2.0-beta6, and also with a more recent 8.x-2.x-dev (1st of april).

Running the MySQL command at the end of #32 appears to have fixed the problem.

Thanks Blink38, running the update query from #32 on a Drupal 8.6 install eliminated the error for me too:

update key_value set value = replace (value, '"not null";b:0', '"not null";b:1') where name="file.field_schema_data.type";

I recently updated core from 8.5 to 8.7, and got the now famous "The File type field needs to be updated.", even with latest dev.
Strangely, I got rid of it by doing the opposite change (setting not null to false) :

/**
 * Implements hook_update_N().
 */
function my_module_update_8001() {
  $key_value = \Drupal::keyValue('entity.storage_schema.sql');
  $key_name = 'file.field_schema_data.type';
  $storage_schema = $key_value->get($key_name);
  $storage_schema['file_managed']['fields']['type']['not null'] = FALSE;
  $key_value->set($key_name, $storage_schema);
}

I hope that won't break anything. I wonder if it might be related to #2841291: Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field and #3003586: [PP-4] Use setStorageRequired() instead of overriding the storage schema to mark fields as NOT NULL in the database.

GaëlG's update_8001 in #73 fixed my issues .. thanks

should probably fix this in the file_entity 8x branch.

Then the title should change.

I recently updated core from 8.6 to 8.7, and now also have the Status Report error "Mismatched entity and/or field definitions".

I'm more inclined to wait for an official patch or new release for File Entity with the bug fix in it than I am manually modifying the database, especially since there are conflicting methods (`not null` or `false`) as the solution.

I tried installing Berdir's patch (https://www.drupal.org/project/file_entity/issues/2914935#comment-12532699) but install failed...

- Applying patches for drupal/file_entity
  https://www.drupal.org/files/issues/2018-03-19/file-entity-type-mismatch-2914935-58.patch (Mismatched entity and/or field definitions for File 'type' field after updating to Drupal 8.7)
  Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2018-03-19/file-entity-type-mismatch-2914935-58.patch

The patch in #58 addressed an issue for pre-D8.4 sites updating to D8.4 or later. It's been committed to the module since then, so you can't apply it again.

As best I can understand, the issue with upgrading to D8.7 seems to be a new, separate issue (even though it causes the same error message and is clearly very closely related). It should probably be handled in a separate ticket so that people don't keep coming here, getting confused, and attempting to apply the old patch. As a matter of fact, someone has already opened a ticket specifically for encountering the issue when updating to D8.7: https://www.drupal.org/project/file_entity/issues/3056070

So, apologies if I'm overstepping my bounds, but I'm going to close this ticket again (since the original issue encountered with the D8.4 update was resolved) and suggest moving the discussion of the D8.7 update issue to that ticket.

stevieb,
Can you please explain the steps you took to make #73 work?
I added the update_hook to a custom module and tried running drush entup as well as the update.php.
It didn't work for me. Are there any other steps I need to follow?

good morning arunm130 after adding the code to your module run drush updb

Still waiting for a patch. As i mentioned this needs to be fixed in file_entity 8.x

Yes but it was already "fixed" for the D8.4 update, and people are now coming to this issue with the D8.7 update and getting confused and attempting to apply a patch that was already committed to the module some time ago. Hence why I was recommending closing this ticket in favour of the new one that had already been created for the D8.7 update issue: https://www.drupal.org/project/file_entity/issues/3056070

Setting this back to the original status, this isn't outdated, it was fixed.

When people, including myself, see bugs like this go for years without being properly addressed and properly fixed, we wonder whether we should laugh, cry, or be angry, that these sorts of circumstances occur with a software system such as Drupal.

This sort of circumstance, with this sort of problem, is all the more ironic for a software platform that is touted by its leaders as being by professionals for professionals.

The bug/problem still is NOT actually fixed!