Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

When running update-mime-database - usually automatically launched by apt-get - why do I reliably get complaints like:

Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
Unknown media type in type 'uri/mms'
Unknown media type in type 'uri/mmst'
Unknown media type in type 'uri/mmsu'
Unknown media type in type 'uri/pnm'
Unknown media type in type 'uri/rtspt'
Unknown media type in type 'uri/rtspu'
Unknown media type in type 'fonts/package'
Unknown media type in type 'interface/x-winamp-skin'

It doesn't seem to be hurting anything, but chronic errors during updates risk obscuring an error that I do care about.

share|improve this question

3 Answers 3

Actually you can fix it simply by doing

sudo rm /usr/share/mime/packages/kde.xml 
sudo update-mime-database /usr/share/mime

Here is a quote from Ana Guerrero in 2008 so you'd think it would be fixed by now.

Those fake mimetypes are installed by kdelibs with the file /usr/share/mime/packages/kde.xml since long time ago. They are kept in kde4libs.

In a recent version, update-mime-database became verbose about this unknown types, and that is why you get this error when you update stuff and then update-mime-database is run. It is unlikely to be changed.

share|improve this answer
up vote 3 down vote accepted

It appears that there are a pile of KDE libraries that bring in these otherwise Gnome unfriendly mime-type definitions. In my case, the libraries were added as dependencies to a KDE application package that I later uninstalled.

To remove the pile of KDE libraries and their associated /usr/share/mime entries, I used:

sudo apt-get purge kdelibs-bin kdelibs-data 
sudo apt-get autoremove --purge
sudo update-mime-database /usr/share/mime

Do be careful that the first command does not force removal of a package you need before you confirm the removal. Getting rid of kdelibs-bin will then make a large set of packages unneeded and ready for autoremove.

I found the basis for this fix in an old bug report for Intrepid Ibex.

share|improve this answer

That's a problem with update-mime-database and the MIME standard itself. Originally it was supposed to be extensible. But the IETF dumbed it down, and no new major mime types are registered (application/* is used as undifferentiated catch-all). The reasoning/surmise behind that being, that few tools are designed to work correctly with new MIME types.

Now update-mime-database at least doesn't fall over when it sees pseudo classifiers like uri/ and fonts/ or interface/. So I assume it only complains because other apps might actually trip over them. strings gave me following list of probably built-in list of "safe" MIME types:

  • text
  • application
  • image
  • audio
  • inode
  • video
  • message
  • model
  • multipart
  • x-content
  • x-epoc

Meaning it would nag over any other x- or x. and vnd. or prs. major mime types. Curiously inode/ is anything but an official media type.

share|improve this answer
Thanks for this valuable comment. It's very useful to know that custom-named mimetypes won't work. Tried creating a mimetype named 'comprovante/biblioteca' and that's why it wasn't working on recent Ubuntu / Linux Mint versions. –  Leonardo Montenegro Dec 4 '14 at 18:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.