Hi Arvid,

We have had the same errors after upgrading to Mx9 from Mx8 and Mendix Support told us the following:

To answer your question, System.UnreferencedFile is internal bookkeeping for keeping track of external files which are not referenced from a FileDocument, but which cannot be deleted yet, because of open transactions and possible rollbacks. 

Regarding the error, it's known to us that is caused by an internal process that runs every ClusterManagerActionInterval (a runtime variable). By default, the interval is 5 minutes, which causes this error to be thrown every 5 minutes. The message indicates that a FileDocument was not deleted because of a safety guard Mendix put in place. However, this should not happen.  The way we identify files changed and a switch to a new File ID was made. The error is caused by using the ORM.cloneObject of a version of the Community Commons module to create a copy of a FileDocument which was not yet compatible with the change in the File ID. This was resolved with the release of Community Commons v8.5.0 but by using older versions there can already be 'wrong' data in your database that now causes this error to be thrown. The following steps can be taken to resolve this issue:

• Make sure that your project utilizes the Community Commons module version 8.5.0 or higher to prevent this issue in the future.
• Clear the "wrong" data/files. To do that, you can either do:
  • Remove the rows from system$filedocument where __uuid__ occurs in the system$unreferencedfile table with a Deleted or Obsolete state and when you don't want this file anymore or if its value doesn't exist anymore in the configured file storage. Maybe that's difficult to know... If you do so, at some moment, Mendix will remove the real file if it exists and it will remove the row from system$unreferencedfile.
  • Or, remove the rows in the  system$unreferencedfile table with a Deleted or Obsolete state, if you want to keep these files in system$filedocument and in the configured file storage.
• In fact, you need to know whether you want to keep the problematic files or not. Are these files still important and do the files really exist in the underlying configured storage? if you know what you want, you can choose one of the delete options.

TLDR: delete all rows in system$unreferencedfile if you don't want to get the error anymore. However, the underlying cause is a mismatch between the FileDocuments in your database and the actual files on your fileserver. So a proper solution would be to resolve it there before cleaning the unreferencedfiles.

I have noticed the same issue as well. Could this cause automatic restart?

Restart started recently and is caused by great amounts of logging.

If you delete a filedocument in a BCO, this can also happen.

Steps: You put a file in the filemanager widget, and then click some button that does something with the file, for example associate it with another object. The file isn't uploaded until the moment you press the button. So at that moment the BCO is triggered, and the file gets deleted. But you've already started the microflow, so the deletion is cancelled. 

This happened to us because we wanted to scan files for viruses before commit. If the scanner was turned off (or a virus was found), we would delete the file in the BCO. This worked when you made a button that did nothing with the file, but in any other situation the file would not be deleted.