'Hold for Authentication' Error in Mac Print Queue

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 error indicates that the credentials that the Mac is providing are being rejected by the server it’s contacting. Select the option below that best describes what you’re seeing.

I see this error when sending jobs to a standard queue shared via SMB or CUPS

I see this error when sending jobs to a Mobility-Print-published queue and my environment uses both PaperCut and Mobility Print

This message is often wholly unrelated to PaperCut. Usually, if you see this error, it is about the print queue’s OS-level authentication instead of PaperCut

Try the easy options first

  • Sometimes this issue is just a hiccup the Mac experiences when connecting to a shared queue. Click the refresh button and see if it prompts for credentials.
  • 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.
  • Test out the user’s credentials by logging into the user web interface via http://[server_name]:9191/user. If that fails, it would be worth checking to ensure that their account isn’t locked out and their password isn’t expired. If you discover this is happening to all users, check out our AD troubleshooting article here.

Confirm correct setup of the print queue connection

  • 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.
  • If you’ve successfully verified the information above, it might be worth recreating the printer on the client machine. For more detailed information check out the relevant resource below:
Looking for an automatic option? Admins may be interested in our Print Deploy Solution!

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.

Force the Mac to request authentication

  • If refreshing the job doesn’t bring up the credential prompt, you might be able to force the prompt to show with the following steps. However, if the lpadmin command doesn’t help, fear not- there’s a lot of KB article left. This option should only be used by administrators comfortable using the Terminal Application in macOS.
    1. Make sure you have a job showing “hold for authentication”
    2. Open terminal and type “lpstat -s” to list all printers on the system.
    3. Find the problem printer ([printer-name]) in the list of devices. The printer name will be located after the line “device for”
    Ex: device for MyPrinter_5600_Series: usb://00000000-0000-0000-AB12-00000000
    In this case, the printer name would be MyPrinter_5600_Series
    4. Type sudo lpadmin -p [printer-name] -o auth-info-required=username,password and hit return to run the command. Enter your Mac’s password to continue.
    5. Send another job to the problem printer and enter credentials when prompted.

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 Pages.

If you see this message when printing with Mobility Print

As is the case without Mobility Print, the most common cause of the “Hold for Authentication” error is entering the username and password incorrectly. you should first attempt to re-enter the credentials by clicking the refresh button. If the problem was due to an incorrect username or password, the job should go through with the correct credentials after reentry.

Per-Job Authentication with Saved credentials

The message can also appear if the Mobility Print queue has Per-Job Authentication enabled and the user has peviously saved their credentials for printing in the Keychain. With credentials stored in the Keychain, the prompt for 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.

A) Disable Per-Job Authentication - this will not be practical if your users share devices and you want to prompt for credentials with each Mobility Print job
B) Delete the credentials from KeyChain Access - Remove the credentials, cancel and retry the job to continue using Per-Job Authentication.

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.

A) Refresh and re-enter the same credentials - As a workaround, this allows the job to go through, but every print job sent will need this.
B) Turn on Username Aliasing - Enable username aliasing to add a username that excludes an apostrophe. Bear in mind, you will need to instruct your users to use this alternative username for Mobility Authentication.

A rogue Mobility server

In rare cases, an unintended Mobility Print server may make its way onto the network. This can happen when a user (we’ll call them Bob) is searching for the client-side applications, but stumbles upon the server installs for both PaperCut and Mobility Print. By accident, Bob has made their machine both a PaperCut Application Server, and a Mobility Print Server (this issue will not occur with Mobility Print without PaperCut installed to as it will not require authentication). Bob eventually adds the printer that’s been published on the true Mobility Print Server, and so it gets republished automatically by Bob’s rogue Mobility Print server.

The pickle in this case is that if another user has connected to the queues automatically published by Bob’s computer, any job sent to this rogue queue recieves “Hold for Authentication” on their macOS device or “Incorrect name or password on their iOS device.

Categories: Troubleshooting Articles, Print Queues

Keywords: hold for authentication, waiting for authentication, authenticate, mac, os x, print queue