Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Printing Issues With macOS High Sierra - Shared Windows Server Printers

Hello,

Just wondering if anyone else has seen the following behaviour on any macOS High Sierra clients?

We add the printers using a script within Casper, but we have seen the issue occur with adding the printer via System Preferences > Printers & Scanners GUI.

In short the client's printer queue's do not clear out the job, and the printer object is paused, despite the job printing correctly.

  1. Client sends a print job.
  2. Print job appears in the printer's queue on the client.
  3. Print job appears in the printer's queue on the server*
  4. Print job remains in the client queue with a status of "Ready to Print"
  5. Additional jobs back up in the queue due to the paused state.
  6. Deleting the jobs in the client queue and resuming the printer allows a user to print, however the issue simply re-occurs.

PrintServer is Windows Server 2016 Standard. Most client printer objects use their model-specific driver, with exception to a couple that use the "Generic PCL Laser Printer" driver. We have witnessed the issue occur with the Generic driver as well.

Code snippet (server path modified):

#!/bin/sh

# Generating Generic PCL Driver - this is generated dynamically as required so we have to create it and dump it in a location for later.
# Reference: https://discussions.apple.com/thread/7138876?start=0&tstart=0

/usr/libexec/cups/daemon/cups-driverd cat drv:///sample.drv/generpcl.ppd >> /Library/Printers/PPDs/Contents/Resources/genericpcl.ppd

lpstat -p | cut -d' ' -f2 | grep "Media-Black-White" | xargs -I{} lpadmin -x {}

/usr/sbin/lpadmin -p Media-Black-White -E -v "smb://[our-print-server]/Media-Black-White" -P "/Library/Printers/PPDs/Contents/Resources/genericpcl.ppd" -L "Location" -o auth-info-required=negotiate -u allow:all

lpstat -p | cut -d' ' -f2 | grep "Room39-Colour" | xargs -I{} lpadmin -x {}

/usr/sbin/lpadmin -p Room39-Colour -E -v "smb://[our-print-server]/Room39-Colour" -P "/Library/Printers/PPDs/Contents/Resources/HP Color LaserJet CP2020 Series.gz" -L "Location" -o auth-info-required=negotiate -u allow:all

Addition:

  • Ageing fleet of printers still in active use.
  • Problem although regular, can be inconsistent between tests.
  • Drivers have not been updated in this release (for HP anyway).
  • Issue is not present in macOS Sierra or older.
  • Same results on APFS and HFS+ High Sierra test units.
  • Users are part of the lpadmin group (required to clear out the queue).

Kind Regards

Like Comment
Order by:
SOLVED Posted: 10/30/17 at 2:14 AM by Jesper

I have seen the exact same behaviour, so you are not alone...
Dont have a solution, but hope someone can provide some insight.

Like
SOLVED Posted: 10/30/17 at 4:54 AM by eirikw

The problem is probably that you in MacOS High Sierra are not allowed to write to

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/Resources/

macOS High Sierra adds a lot of secure system locations that are blocked for access, even for root. Rewrite the script to create the PPD file in the computer domain (/Library), not in the secured system domain. A more suitable location would be

/Library/Printers/PPDs/Contents/Resources

Not saying that this is the main reason that the printing doesn't work, but it is just not possible for the script to write the PPD file in macOS High Sierra.

Like
SOLVED Posted: 10/30/17 at 7:41 PM by merc_support

@eirikw Good eye. The script is from a test system which has SIP disabled - sorry, didn't explain that fully - so the PPD gets written in this case. As you say, the PPD doesn't get written on a system with SIP enabled. The script will eventually save to either...

/Library/Printers/PPDs/Contents/Resources

Or

/tmp/

I'll amend the post to avoid confusion! Regardless, the issue still exists with either SIP enabled or disabled. :(

Like
SOLVED Posted: 10/30/17 at 10:39 PM by BOBW

Im seeing this as well but only for HP printers. Konica, Toshiba etc are all fine. Even paperCut with the HP drivers are having the issue.
I have applied the HP driver update to 5.1 but still the same issue.
When I remove the printer and reset the printing system I cannot even add it back.
When I add the printer by lpd it will add but will pause when you try to print.

Like
SOLVED Posted: 10/30/17 at 10:44 PM by BOBW

Just to add, I have attempted to add the printer by browsing advertised printers, installing through Self Service, scripted.
Advertised printers wont add anything
Installing through Self Service and LPD adds the printer but just will pause.
I tried adding printer using generic postscript and still the same
Attempted adding troubleshooting through CUPS but still nothing.

All AD printers
Only High Sierra
APFS and HFS
All users part of lpadmin group same as @merc_support

Like
SOLVED Posted: 10/30/17 at 11:00 PM by merc_support

@BOBW Yeah the 5.1 update was one of our first checks too - unfortunately our models' drivers weren't updated in that release. We've also seen it with our Fuji Xerox MFD printer object, which is part of a PaperCut solution (we share a virtual queue, with swipe card release on physical FX printers). The majority of our lab / department printers are HP.

Like
SOLVED Posted: 10/31/17 at 4:06 PM by BOBW

@merc_support HAve you ran any testing on the 10.13.1 beta?

I might give this a go today to see if it is resolved. If I get time...

Like
SOLVED Posted: 10/31/17 at 4:12 PM by janhy

I encountered this problem in prior Mac OS versions.

This is what I have in my notes to fix this issue. I don't remember if I had to do all of the steps or just the DefaultAuthType one.

Open Terminal and type the following, hitting return after each line:

sudo sh -c 'echo "Sandboxing Relaxed" >> /etc/cups/cups-files.conf'
sudo launchctl stop org.cups.cupsd
sudo cupsctl DefaultAuthType=Negotiate
Like
SOLVED Posted: 11/1/17 at 3:02 AM by merc_support

@BOBW Not yet - currently updating test Macs with macOS 10.13.1 release (released last night - macOS 10.13.2 beta now available).

@johno Unfortunately that's not it. We don't believe that command has an effect on the printers (the way we deploy them anyway) unless they're shared / added as a localhost printer.

Regardless we do include this in our printer scripts, which achieves the same.

-o auth-info-required=negotiate

From memory this is to prevent the paused "Hold for Authenitcation" queue for end users.

Will update our experience with macOS 10.13.1 tomorrow.

Like
SOLVED Posted: 11/1/17 at 10:04 PM by merc_support

Initial testing suggests the latest macOS High Sierra 10.13.1 Update has resolved this issue for us.

Also noted from the RN:

Enterprise content: - Improves the reliability of SMB printing.

Nicely worded :)

Like
SOLVED Posted: 3/5/18 at 7:39 AM by Koffie

I had related problems with a Xerox 7855 WorkCentre, continuous "Unable to handle AUTH_INFO_REQUIRED” messages in the CUPS print queue. On some Mac's with High Sierra the print queue even completely stalled. I found a possible fix (disable SMB3), as described by TXHaflaire here, https://www.jamf.com/jamf-nation/discussions/26464/macos-high-sierra-10-13-2-finder-issues-when-copying-files-in-mounted-shares

In short, I created a file /etc/nsmb.con with content (and restarted)
[default]
protocol_vers_map=2

Have not seen the messages anymore.

Like