“Help! When sending a print job from MacOS we sometimes see that the job is stuck in the print queue with the message “Hold for Authentication”… What does this mean?”
What does ‘Hold for Authentication’ mean?
This error message can sometimes appear when printing from a Mac, where the job status appear to be paused in the print queue window, with the message ‘Hold for Authentication’. This means that the user may not be authorized to send a print job, 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 will appear when printing from MacOS to PaperCut Mobility Print if the user enters the wrong username or password. Pressing the refresh button will give the user a chance to reenter their PaperCut credentials and the job should go through.
It can also happen if Per-Job Authentication is enabled, and the user has tried to save their credentials for printing in the KeyChain. When this happens, the prompt for authentication won’t pop up and macOS printing system will ‘hold for authentication’. While annoying, this does prevent the bigger problem of a user accidentally saving their PaperCut credentials on a shared device.
Disabling Per-Job authentication in Mobility Print will prevent 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.
If you see this message without Mobility Print
This message is often completely unrelated to PaperCut, but may show up when customers start implementing shared Print queues on servers.
Usually if you see this error, it is actually the OS-level authentication that’s being referenced instead of PaperCut.
For this reason, we find it’s easiest to remove PaperCut from the equation when testing. Ignore the printer in PaperCut by ignoring the printer in PaperCut. Send a test job to the printer from the server itself to make sure that the job doesn’t show up in PaperCut under Logs → Job Log.
Note that if you’re testing to see if it’s happening at the OS level with PaperCut excluded, you’ll still need to print through the shared print queue on the server. Printing directly from the workstation to the Printer will bypass the server print queue entirely (and also PaperCut) so will not be a true test of the server queue.
How we wish there was one ‘fix all’ solution for this. Sadly our customers and the forums have proved that there may be different fixes depending on exactly what is causing the issue. A few suggestions to try are below…
Make sure the Server Print queue is installed correctly
- If printing to a Windows hosted print queue from a Mac workstation, make sure you’re using SMB. Some customers have also resolved the issue by uninstalling the print queue and then installing the printer using the ‘Windows’ tab as per Apple’s documentation.
- If printing to a Mac hosted print queue from a Mac workstation, make sure that the printers have been added to the workstation using IPP.
- Make sure that there aren’t any spaces or special characters in the printer name.
Try removing the saved authentication from the Keychain
- First try hitting the ‘Refresh’ icon in the screenshot above (where the mouse pointer is), to see if that forces the OS level authentication again.
- 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.
Try using a fully qualified domain name for the printer
- If you’re using an AD-authorized queue, then it may be worth changing the mapping to the fully qualified domain name as detailed in Apple’s Support Article.
Check if you’re printing across subnets
- Are the workstations on the same subnet as the print server? If not, on the print server if you go into the CUPS interface at
http://localhost:631 then go into ‘Administration’ at the top, then on the right hand side under the Server settings, make sure that ‘Allow printing from the Internet’ is checked. If that’s not checked, it will ask you to restart CUPS.
Categories: Apple macOS,Troubleshooting
Keywords: hold for authentication, waiting for authentication, authenticate, mac, os x, print queue