File Extension / Mime Type errors "File type not permitted or Mime type does not match the file content" - "File type does not match the content for file"DescriptionWhen uploading a file with an extension already added to the 'glide.attachment.extensions' system property, the file does not upload and instead just seems to be uploading until manually cancelling. The system returns one of the possible error messages:"File type not permitted or Mime type does not match the file content""File type does not match the content for file" There will also be similar messages in the application node logs after attempting to upload the file: Security restricted: Detected File test.xps. Expected file type: application/vnd.ms-xpsdocument, actual file type: application/zip WARNING *** WARNING *** Security restricted: MIME type mismatch for file: entauthx02-SecureAuth-.csr. Expected type:application/octet-stream, Actual type: text/plain The issue is being caused by a mismatch of what the system expects to have detected based on the library we use for mime type validation and what the system is actually seeing in the file. If the system property 'glide.security.file.mime_type.validation' is set to true, allowed file extensions may fail attaching with no message in the UI, only in the localhost log. Steps to Reproduce 1. Add the system property glide.security.file.mime_type.validation of type true/false, value set to true. 2. Add the file extension .offx to glide.attachment.extensions. 3. Try to attach an offx file to an article. Observe the mentioned errors in the instance log.WorkaroundAfter carefully considering the severity and frequency of the issue, and the cost and risk of attempting a fix, it has been decided to not address this issue in any current or near future releases. We do not make these decisions lightly, and we apologize for any inconvenience. You can workaround most cases of this issue by (1) mapping the file extension to its expected mime type by updating or creating the system property: 'glide.security.mime_type.extension_mapping', and if that is not sufficient proceeding to (2) forcing the system to accept different file types for that extension by updating or creating the system property: 'glide.security.mime_type.aliasset' Map Extension to Mime Type Determine the mime type you expect for files with the extension. If you aren't sure, there are various ways to figure it out: // This works in MacOs command line; the result here indicates that mime type is text/plain $file -I mynotes.text mynotes.txt: text/plain; charset=us-ascii // This works in Linux and MacOs $file --mime-type -b mynotes.text text/plain // Windows has no standard way to detect mime type, but addons exist Be cautious if it is determined that the mime type is 'application/octet-stream'. That is the lowest common denominator of mime types, so it is not usually good practice to map an allowed extension to application/octet-stream Now navigate to sys_properties.list and create or edit property wih name glide.security.mime_type.extension_mapping and append to the value <file extension>=<expected mime type> This will often be sufficient, especially for unusual extensions. So try to upload the file again. If you succeed, you're done. Otherwise, you will need to go to the second part of the workaround. Map Two Mime Types as Equivalent (Only if Necessary) Summary of Steps Find the message in the logs so you know which mime type it is expecting and which one it is detecting.Navigate to sys_properties.list and create or edit property wih name glide.security.mime_type.aliasset and append to the value <expected mime type>=<actual mime type> Find out what the interpreted Actual and Expected values for the file are and update the glide.security.mime_type.aliasset system property by following the steps below: Reproduce the issue, by trying to attach the file and see the errorGo to 'System Logs/Node Log File Download' in the Application Navigator on the instanceDownload the node log by searching for the current date's node log file (i.e. localhost_log.2018-06-07.txt)Open the log file and try to truncate it within the timeframe when the issue was reproduced so that it is easier to search through the log fileSearch for the term 'sys_attachment.do' then look for the message 'Security restricted: MIME type mismatch for file' or something similarYou should see Expected Type and Actual Type values next to this message. Example: in the logs, find that the expected mime type is application/x-apple-diskimage, but the actual mime type is application/x-bzip2The glide.security.mime_type.aliasset system property will need to be updated with these values as <expected mime type>=<actual mime type> replacing the expected and actual mime types with the values from the log file determined in the previous steps hereSo, continuing with the example above, the value of the property would need to be set to: application/x-apple-diskimage=application/x-bzip2Note that this property value can hold multiple Expected/Actual file type alias specifications all separated by a comma. (i.e. application/x-apple-diskimage=application/x-bzip2,application/vnd.ms-xpsdocument=application/zip,application/vnd.ms-xpsdocument=text/plain,text/csv=application/octet-stream). Related articles:Error message "File type not permitted or mime type does not match the file content" when uploading fileGlide Mime type detection properties for file attachmentsRelated Problem: PRB655487