Common Mac Printing Issues
Last modified on 14 August 2020 04:47 PM
How do I set up printing on my Mac and make it work with PaperCut?
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:
I get the message “Unable to get printer status (client-error-forbidden)!” when printing from the workstation.
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:
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.
The names of users synchronized from OpenDirectory are different to the user names on print jobs (e.g.
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!
Options selected in the
This is caused by the same problem described under RIPs, Fiery, Plotters and Advanced Drivers below. Please see that answer for a workaround.
I am running PaperCut with a Fiery RIP or using an OCE Plotter. When I configured the workstations to print directly to the device, everything works as normal. However when I configure the workstations to print via server based print queues, the selected print options I select are being ignored. How can I fix this?
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]
[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.
Note: Also see PaperCut and Host-only drivers
I have a printer such as the Epson Stylus Pro 4800, a small HP LJ, some Canon printers, etc., that only provides host based drivers that does not work with Mac OS X Server based queues. Can PaperCut support this printer?
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:
4. In the
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
6. Run the
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!
One alternative is to use a generic PostScript or PCL print drivers. Apple however have made available drivers specifically to address this issue:
Many thanks to Chris Gorlaski - Westside Christian College, for this information.
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).
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
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.
1. How can I give my client computers access to my printers on OS X 10.7 and above?
A 1.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:
When adding the print queue to a MS Windows client the URL format is http://<hostname>:631/printers/<queue name>
Q 2. I can’t connect to my Windows print server using SMB or LPD queues.
A 2. Oh no! You should check out the KB article Printing from macOS to shared Windows Server queues with LPD and SMB.