“Help! When printing from macOS computers, sometimes we see the job stuck in the print queue with the message “Hold for Authentication.” What does this mean?”
What does “Hold for Authentication” mean?
Sometimes, when printing from a Mac, the job appears to pause in the print queue window with the message “Hold for Authentication.” This condition means that the user may not be authorized to send a job to this print queue, possibly because they have entered the wrong credentials. Below, we explain how this can happen in different scenarios and how to troubleshoot.
If you see this message when printing with Mobility Print
This message can appear when printing from MacOS to print queues published with PaperCut Mobility Print if the user enters the wrong username or password. Pressing the refresh button gives the user a chance to reenter their credentials and, if the problem was due to an incorrect username or password, the job should go through with the correct credentials.
The message can also appear if the Mobility print queue has Per-Job Authentication enabled and the user has previously saved their credentials for printing in the Keychain. With credentials stored in the Keychain, the prompt for authentication won’t pop up, but if opened, the print queue window shows “Hold for authentication.” While annoying, this does prevent the more significant problem of a user accidentally saving their PaperCut credentials on a shared device.
Disabling Per-Job authentication in Mobility Print prevents the above scenario, but won’t be practical if your users share devices and you want to prompt for credentials with each Mobility Print job. Alternatively, you open Keychain to delete the credentials in question, then cancel the job and retry.
A rogue Mobility server
The pickle in this case is that if a user has connected to a print queue from the Primary server and also somehow installed PaperCut and Mobility on their computer, then anyone in the office that sends jobs to this queue receives “Hold for Authentication” on their macOS device or incorrect name or password on their iOS device.
For example, ABC Co. has a Mobility print server that publishes printers to Alice, Bob, and Chuck. At one point, for whatever reason, Chuck installed PaperCut and Mobility on his computer and promptly forgot about it. Remember that by default Chuck’s rogue Mobility server publishes print queues with mDNS. In any case, the real ABC Co. Mobility server is finally publishing queues, and Chuck adds one of its printers, ABC-Printer. Alice and Bob connect to ABC-Printer, but they get hold for authentication because of the colliding mDNS advertisements from multiple Mobility servers. However, Alice and Bob can print to the queue as long as Chuck takes his laptop to work from home. Also, the ABC Co Mobility server publishes another queue, ABC-Printer-BW, but luckily, Chuck never prints in black and white so he didn’t connect this printer to his rogue Mobility server which means everyone can print to it successfully.
An apostrophe in the username
The apostrophe shortcoming is inherent to macOS whether the user authenticates with their apostrophe-enabled username on a print queue advertised from Mobility or a print queue published directly from an AirPrint-enabled printer. At the time of this writing, we have yet to determine whether this lapse is due to CUPS, macOS, both, or something else entirely.
At any rate, a short-term workaround is to hit the print job’s refresh icon to input one’s credentials a second time, as, for some reason, the second authentication attempt sends the job through. Keep in mind every print job would require this workaround.
However, a longer-term workaround is to leverage PaperCut’s username aliasing feature. Turn on username aliasing under Options > Advanced > Username Aliasing. Next, go to your apostrophe-enabled user and populate their username alias with a name that doesn’t include an apostrophe. As you can imagine, leveraging username aliasing comes with the condition that users with apostrophe-enabled usernames require training to authenticate with the new alias when sending jobs to Mobility print queues.
If you see this message without Mobility Print
This message is often wholly unrelated to PaperCut but may show up when customers start implementing shared print queues on servers.
Usually, if you see this error, it is about the print queue’s OS-level authentication instead of PaperCut. For this reason, we find it’s easiest to remove PaperCut from the equation when testing. Ignore the printer in PaperCut using the steps in this article. Confirm printer ignoring works by sending a job to the queue from the server itself to make sure it doesn’t show up in PaperCut under Logs → Job Log.
Keep in mind that one has to send the job to the server’s shared print queue as printing directly from a workstation to the printer bypasses the server print queue entirely (and also PaperCut) so is not a real test of potential issues with the server queue.
Confirm correct setup of the print queue connection
- For organizations with small numbers of macOS clients, an easy to manage connection protocol for Windows hosted print queues is SMB. If users have authentication issues with an SMB-connected print queue, make sure that they are using their current username and password. Sometimes, users are unaware that their password expired or are unaware that their SMB username changed after changing their surname with HR, payroll, or AD, for example. However, rather than training users on adding a print queue using the SMB protocol, keep in mind that they can also add Windows hosted queues with the ‘Windows’ tab as per Apple’s documentation. With SMB-connected queues, it may also be worth using the printer’s fully qualified domain name as detailed in Apple’s Support Article.
- As a troubleshooting step with Mac-hosted print queues, check to see whether authentication behaves any differently using the IPP protocol instead of Bonjour.
- Make sure that there aren’t any spaces or special characters in the printer name. That is to say; our recommendation is only to use alpha-numeric (numbers and letters) characters when naming your server print queues.
Try removing the saved authentication from the Keychain
- First try hitting the ‘Refresh’ icon in the screenshot above (where the mouse pointer is), to check whether forcing the re-request of credentials inherent to this method helps.
- Open your Keychain Access.app and delete the entry for the print queue in question. Then cancel the job and retry. More info on that over on the Apple forums.
Try a different driver
- Some customers have found that using a different driver resolves the issue in some cases. It’s worth checking the manufacturer’s website to see if there’s an updated (or alternative) driver.
Check if you’re printing across subnets
- Are the macOS workstations on the same subnet as the macOS print server? If not, on the print server launch the CUPS admin interface by browsing to
http://localhost:631 then “Administration” at the top, then on the right-hand side under the Server settings, make sure to check “Allow printing from the Internet.” Keep in mind that it’s typical for CUPS to restart after making changes on the Administration page.
Categories: Apple macOS,Troubleshooting
Keywords: hold for authentication, waiting for authentication, authenticate, mac, os x, print queue