Common Mac Printing Issues

This page covers some common macOS printing issues across all versions of macOS. If you’re looking for known issues with a specific version like Catalina or Big Sur, or even with the new Apple Silicon (M1 chips) then take a look at our Known Issues with macOS article.

Setting up printing on macOS

Mac printing is a complex topic and answers will vary depending on the operating system used on the server side. Chapter 21 in the PaperCut User Guide addresses many of the common questions. Refer to this as the first step:

https://www.papercut.com/help/manuals/ng-mf/common/install-mac-printing/

Error ‘Unable to get printer status’

A common cause of this problem is that the Mac workstation/clients are in a different subnet from the server. One of the idiosyncrasies of CUPS on Mac is that its default security configuration is only allow printer access from systems in the same subnet (i.e. tight default security - a little too tight!). The work around for this is to use LPR between the workstation and the server rather than IPP. In other words:

• Ensure that LPR is enabled on the print queues on the server. See the “LPR checkbox” on this screen-shot.

• Add the printer on the workstation as an LPR/LPD printer rather than IPP.

Technically it is possible to hack the CUPS configuration file to open up access, however future updates overwrite the file so using LPR as a work around is a simpler choice.

Open Directory names mismatched in sync.

This can be a side effect of using AppleShare to share print queues. We recommend disabling AppleShare at the print server and using IPP or LPR instead. See the user manual chapter Mac Printing in Detail for more… err… detail!

Print options are not being retained (e.g. copies/page size).

This is caused by the same problem described under RIPs, Fiery, Plotters and Advanced Drivers below. Please see that answer for a workaround.

RIPs, Fiery, Plotters and Advanced Drivers

This is a common issue with many Fiery RIP drivers and some plotters and other printers. This not a PaperCut issue but is due to broken/buggy PPD based driver supplied with these devices. Fortunately we have however managed to find a work-around.

The issue is that the PostScript filter on the server are incorrectly “re-rendering” the job when it passes through, and this action resets the settings. All rendering should be done on the clients and no modification should be done on the server. The problem is due to bad filter/mime configuration in the printer’s PPD file.

What should happen:

  [workstation (render to PostScript)] -→ [server (already PostScript so no changes required)] -→ [printer/RIP]

The problem:

  [workstation (render to PostScript)] -→ [server (re-rendered to PostScript)] -→ [printer/RIP]

We’ve managed to resolve this issue by replacing the drivers on the server with the standard Apple Generic PostScript Driver. The manufacturer supplied drivers are still used on the workstation, so you still have all the normal options, but the use of the Generic driver on the server prevents modification as the job passes through the server’s queues.

To install:

1. Set up the printer/plotter/RIP on the server using the Generic PostScript Driver. Set up as a socket, jet direct, or LPR printer pointing directly to the device’s IP.

2. Ensure the printer is shared via Server Admin.

3. Set up the printer/plotter on each workstation using the manufacture supplied driver. Set up as an IPP or LPR printer pointing to the Server (not to the device). See this Chapter for more detail.

Host-Only Printers

Note: Also see PaperCut and Host-only drivers

A host-only printer is a printer which does not support shared network based server queues. Unfortunately host-only printers still exist on the Mac. For example many Epson and Canon drivers are simply “ports” of the old Mac Classic drivers to OS X. Hence they are very limited, do not follow standard CUPS guidelines, and only work when the system is directly connected to the printer. (The Classic drivers where never designed for OS X Server queues) Some host-only printers can be shared when the Generic PostScript Driver is used on the workstation side as discussed above, however many drivers such as some Epson printers have issues with this method. For example, the native drivers may offer advanced color features that are not available in the Generic Drivers hindering the printer use. PaperCut is able to support these legacy host-only drivers with some additional configuration and setup.

Because host-only printers can’t be configured to use server based queues, the print monitor and analysis needs to be done directly on the workstation before it’s sent to the printer. In effect, the printer is a “directly attached” printer and can be supported using the procedure as discussed in Chapter 13:

Here is a summary of the required setup:

1. Nominate a number (one or more) systems that will be configured to use the host-only printers. In an education environment, you’d usually select Lab systems located close to the printer.

2. Set these nominated system(s) as per the manufacturer’s guideline. Verify that printing works as expected. Make sure this is the case before moving to the next step.

3. Install the PaperCut Secondary Server Installation option (in the DMG) on this system. Follow the secondary server install options as discussed in the manual here:

   https://www.papercut.com/products/ng/manual/ch-secondary-print.html

4. In the print-provider.conf file enter the IP of the primary server in the setting:

   ApplicationServer=<primary server’s IP address>

5. If you will have more than one system printing to the host-only printer, PaperCut will add a printer instance for each workstation. The multiple printer instance will make management hard (e.g cost changes will need to be applied to each instance). To have all printer instances list under the one, you could alias this system name so all workstations report usage under the one “virtual server” name. Add the following line to the print-provider.conf file:

   ServerName=HostOnly

6. Run the configure-cups-mac.command program in:

   /Applications/PaperCut NG/providers/print/mac

   and ensure that monitoring is only enabled on the host only printer.

7. Now printing will be monitored at the local system level and the usage details posted across to the primary server in real time. Perform some testing and verify that the system is working and track printing as expected.

8. By about now you’ll be very frustrated and will be simply wishing that the vendor could supply quality drivers on the Mac that support server based queues. Most do, why not this one!!! Take a deep breath and then contact the vendor to complain. They should be supplying quality drivers that are network aware and support servers. They would never try this stunt on Windows systems, so why Mac!

I have a Fuji-Xerox C2200 (or similar) driver that just doesn’t work under OS X 10.6.x

One alternative is to use a generic PostScript or PCL print drivers. Apple however have made available drivers specifically to address this issue:

http://support.apple.com/kb/dl904

Many thanks to Chris Gorlaski - Westside Christian College, for this information.

Wrong number of copies reported for Adobe Applications on Macs

On Print Providers monitoring CUPS queues, typically seen on Macs, it was found that in some cases users would see the number of copies squared: e.g. ask for 2 copies but get 4 copies; ask for 3 copies but get 9 copies etc. This was due to a misinterpretation of the CUPS interface and in turn factoring in the number of copies twice. This was typically reported when clients were using Adobe Photoshop on the Apple Mac monitored print queues. This issue was fixed in PaperCut 10.4 (Build 10808).

Unable to print across a large or complex network environment with CUPS-hosted queues

When working with larger networks, a situation may arise where some or all users are unable to print to certain printers, as CUPS by default will not allow printing from outside the subnet it resides in. To fix this, use the command

cupsctl —share-printers —remote-any

What print server system does Apple Mac use?

Under the hood, the Mac OS uses CUPS (Common Unix Print System) for print queue management. PaperCut interfaces with CUPS on Mac using the same methods it uses for CUPS on Unix.

I can’t connect to my Mac print server using LPD or SMB print queues

Since OS X 10.7 Macs no longer supports LPD or SMB printer serving. You will need to access your printers using IPP from your Mac workstations.

If you are using a Mac client then you add the printer queue on the client as follows:

1. Open Preferences
2. Select Print&Scan
3. Select +
4. Select IP
5. In address enter the IP address or name of your Mac printer server
6. in the Protocol field select IPP
7. In the Queue field enter /printers/<queue name> where <queue name> is the name of the printer on the Mac server
8. Check to make sure that the printer is being monitored by PaperCut

When adding the print queue to a MS Windows client the URL format is http://:631/printers/

I can’t connect to my Windows print server using SMB or LPD queues.

Oh no! You should check out the KB article Printing from macOS to shared Windows Server queues with LPD and SMB.