The tale of two hostnames
In May 2024, I was assisting a school with setting up a new macOS deployment workflow.
They were previously an all-Windows school and were looking to pilot macOS devices.
Everything went smoothly except for one key issue:
The Mac couldn’t print.
More specifically, the Mac couldn’t print to their SMB printer queues shared/managed by Papercut.
Whilst the official recommendation from Papercut when experiencing SMB issues post PrintNightmare is to use LPD or Mobility Print (IPP/HTTP), sometimes you have to deal with the cards that are dealt 🙂
https://papercut.com/support/known-issues/?id=PO-522#ng
As described above, the symptom I saw was:
…when printing macOS > Windows over SMB… can result in printers going into a Waiting state indefinitely. You might initially see them go into a Hold for Authentication state - if you click refresh and supply valid credentials, you will end up in the Waiting state.One of the suggestions in the above thread was to add ?encryption=no to the print queue, which on its own didn’t make any difference.
The baffling part of the issue was that printing WORKED in my initial testing but stopped when I was minting the workflow ready to handover to them.
So what had changed?
I had added a computer naming step to the workflow.
The script used to name the device resembled this:
ScriptRepo/ComputerName-Set-Serial.sh at master · aarondavidpolley/ScriptRepo · GitHub
Changing the computer name in System Settings/Preferences didn’t fix the issue.
Resetting the device, not using the script to name the computer: WORKED!
So why did setting the computer name break it?
If you pay close attention to the script above, macOS has three names:
- ComputerName
- HostName
- LocalHostName
When you use the built-in directory binding plugin (via script or directory utility), the HostName is important to be set before binding as it forms part of the information used in the domain join.
The HostName can be different to the visible name of the computer in Terminal, System Settings, etc., which is why admins have been using scutil for a while to set all three in scripts.
The Jamf binary on a Jamf Pro managed Mac uses the same approach of setting all three names when you use it to set the computer name.
In a world that is ever increasingly free of AD-Bound Macs (to which we rejoice), setting all three computer names is less important and evidently troublesome when trying to print to SMB queues hosted on Windows Server.
Looking at logs, network traffic, and digging around the web, there is evidence that deep in macOS is code that looks for the HostName being set as evidence of an AD-Bound device.
As a result of this confused state of identity, it starts sending RPC signals that AD/Windows Server doesn’t know what to deal with, causing the communication to fail.
Computer: “Hey, I’m this AD-Bound device MAC123, can I print?”
Server: “MAC123 not found in my directory. Go away.”
End of print job attempt.
At the time of this discovery, naming the computer was not an important success criterion.
We skipped naming the device, configured the printer queue install (using a script similar to the one below), that included the ?encryption=no in the queue URI, tested successfully, and off we rode into the sunset.
ScriptRepo/Printers-CUPS-Add-Printer.sh at master · aarondavidpolley/ScriptRepo · GitHub
So why bring this up in September 2025?
I recently visited that same school and helped them revise their macOS deployment workflow. They wanted to expand the pilot to a new set of users and add in any latest tooling/config changes that were appropriate.
Printing came up again.
The papercut environment was largely unchanged, but the queues had stopped working.
After troubleshooting and dusting off old notes (and brain cells), I was able to conclude:
- macOS 15.6+ has the same issues as previous versions (including macOS 14, where I had encountered the year prior).
- Jamf Setup Manager, which I was now using to set the computer name and therefore using Jamf Pro’s Jamf Binary, was setting all three computer names, repeating the hostname/RPC issue.
- Using a script to run
scutil --set HostName “”and then rebooting the machine will fix the RPC authentication issue. - The
?encryption=nostring now causes the print job to fail and needs to be removed from the printer queue path. - Using a script to only set the
LocalHostNameandComputerNameviascutilworks fine (and is effectively the same as setting the computer name in System Settings).
So in summary:
Symptom: If you can’t print to an SMB printer queue hosted on a Windows Server and it gets stuck waiting or on hold for authentication (even though you’ve provided user auth credentials or have Kerberos tickets).
Check: run scutil --get HostName and see if you get a result.
Fix: if the HostName has been set, run scutil --set HostName “” and then reboot the Mac to fix the RPC authentication issue.
Hope you find this and it assists your obscure printing issue 😆
