When installing a new printer using the CUPS web interface, instead of displaying the list of drivers only the message

Unable to get list of printer drivers:

is displayed. No printers can be added.

Question: What is the problem here? Searching the internet gives several reports of the problem but it is difficult to find a solution.

More information:

Also adding printers via other GUIs communicating with CUPS does not work.

Furthermore, running

lpinfo -m

prints after some time

lpinfo: success

instead of a driver list, and running

/usr/lib/cups/driver/foomatic list

takes very long time on CPU usage.

4 Answers 4


I had this problem when trying to set up a print server on my Raspberry Pi. The only thing that seemed to work was to run this:

sudo /usr/lib/cups/daemon/cups-driverd list 1 0 requested-attributes=’ppd-make’

which I found in the comments on this article after a lot of fruitless attempts. After running that, the CUPS web UI started working as expected. I don't think I was ever using foomatic, and I was using Gutenprint.


This bug triggers as an interaction between gutenprint, foomatic and cups.

Quick workaround:

  • Remove gutenprint,
  • or: Remove the package providing /usr/lib/cups/driver/foomatic (which is foomatic-db-engine on Arch Linux),
  • or: Manually remove the files /usr/share/foomatic/db/source/driver/gutenprint-ijs*.xml.

More in depth:

There is an informative discussion of this problem [already here], so I provide just a summary:

  • gutenprint installs two comparably big XML files, namely /usr/share/foomatic/db/source/driver/gutenprint-ijs-simplified.5.2.xml and /usr/share/foomatic/db/source/driver/gutenprint-ijs.5.2.xml (as in the current version as of this writing).
  • foomatic or one of it's sub-packages (foomatic-db-engine in Arch Linux) install the perl script /usr/lib/cups/driver/foomatic.
  • When CUPS tries to get a list of printer drivers, /usr/lib/cups/driver/foomatic list is called, which takes way too long time on the big XML files (this is a fault of /usr/lib/cups/driver/foomatic). Eventually, it might finish, but CUPS times out earlier without having got any information about printer drivers and produces this strange Success-error. Since it did not get information about printer drivers, it is not possible to add printers via any interface to CUPS other than manually editing configuration files.

So, as long as /usr/lib/cups/driver/foomatic is not fixed to be quicker on big files, probably the best workaround is, if one wants to have both gutenprint and a full foomatic-install, to manually remove the two big XML files provided by gutenprint. (Increasing the timeout in CUPS would not be good since one could wait for hours.)

For Arch Linux, if one builds the package locally (e.g. via the Arch Build System, or by installing with yaourt and having customizepkg set up), one can apply the following patch to the PKGBUILD of gutenprint in order to have the modification within the package:

--- PKGBUILD.old        2016-04-14 18:13:15.000000000 +0200
+++ PKGBUILD.new        2016-04-14 18:41:47.000000000 +0200
@@ -47,5 +47,8 @@
 package() {
   cd ${pkgname}-${pkgver}
   make DESTDIR=${pkgdir} install
+  # The following line was added by '"'customizepkg-scripting'"', script '"'$0'"', in order to work around the bug described at https://bugs.archlinux.org/task/47718
+  rm -fv "${pkgdir}"/usr/share/foomatic/db/source/driver/gutenprint-ijs*.xml
  • 1
    Sometimes running lpinfo -m before adding a printer also helps, because files can be in cache and processed quicker on a second run (happens to me sometimes, and @AntonSamsonov did also describe it in this answer). Commented Dec 17, 2018 at 15:28
  • 1
    This is on the right track, but gutenprint alone may not be causing the timeout condition. I've been using a Raspberrypi for the past couple of years as a print server with no issues - until this winter. A power outage borked my Raspbian installation, so I started a fresh one. Trying to get the printer working, I ran into this condition. Never had it before, so I must have done something different. I uninstalled gutenprint, but still had the problem. Used the debug routine as suggested by @Sjoerd. Only by reducing the number of scripts could I get a driver list to show. See my other comment.
    – Mark G B
    Commented Apr 6, 2019 at 22:11

I found a way to debug this problem. Cups runs lpinfo -m to get a list of printer drivers, and this runs scripts in /usr/lib/cups/driver, and one of these is causing problems. By removing all scripts and adding them one by one you can determine which script is causing the problems.

  1. Move all the scripts to a subdirectory, so that they are ignored.

    cd /usr/lib/cups/driver
    mkdir disabled
    mv * disabled
  2. Run /usr/sbin/lpinfo -m. If this runs correctly it will output a list of printer drivers. If this fails it will print "lpinfo: Success".

  3. Do this for each driver: move one driver back and check whether it was the cause by running lpinfo:

    mv disabled/dymo  .
    lpinfo -m
  4. As soon as this outputs lpinfo: Success, the last driver you moved caused the problems.

  • Yes, I did so, and doinng this turns out to be the /usr/share/foomatic/db/source/driver/gutenprint-ijs*.xml beeing the problem. Commented Jul 5, 2016 at 18:01
  • 1
    This is not necessarily a valid debug routine. It could be that it is the total size resulting from the scripts that is causing the timeout. I just tried this - and got all but 3 scripts to run. Adding another script caused the fail.
    – Mark G B
    Commented Apr 6, 2019 at 22:02
  • 1
    I had the same problem on Linux Mint. I moved just driverless and driverless-fax scripts to the disabled subfolder and cups is responding very quickly. Uninstalling gutenprint and foomatic not solved the problem.
    – lucky62
    Commented Jan 5 at 15:45
  • moved driverless and driverless-fax worked for me too on Fedora 39, still don't know why since I haven't touched anything related to printer before
    – Chicky
    Commented Mar 21 at 17:09

I also had “Unable to get list of printer drivers: Success” initially in the web interface (after some noticeable disk activity), however running lpinfo -m in command line afterwards resulted in a long list of drivers — just as it should. That was puzzling, based on the answers already given here.

But then I simply refreshed the page (that involved re-submitting the data), and the driver list was displayed successfully in WebUI, allowing me to proceed and finish adding the printer. So it may be worth to retry some time later, perhaps after checking lpinfo -m output just to be sure.

  • I currently have the same. I did not dig it down right now. Commented Jan 22, 2017 at 15:53
  • 1
    Maybe because the first run scans the filesystem on disk, and the second run fetches the data cached from memory which is faster and so does not run into timeout? Commented Oct 31, 2017 at 15:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .