SMB Printing to Windows Print Server failing to connect to server suddenly

[VintageMacGuy]

Just this week, we are noticing that many Macs, but not all of them, are not able to print via our Windows print server. Nothing has changed on our Mac side.
We are printing via PaperCut, so using SMB on a printer installed via JAMF and no changes to the setup.
Macs not joined to the domain and not using the AD Username as the machine or profile name in many cases, but likely in many others.
I can add PaperCut LPD to the print server and print via LPD - but no authentication, so the job gets stuck with no way to get it to print from Papercut, unless the users profile on the Mac is named the same as their AD username.

The issue looks very similar to this one:
https://community.jamf.com/t5/jamf-pro/mac-printing-issue-after-microsoft-windows-print-server-updat...
However, we don't have the server updates referenced in the thread or PaperCut advisory.

Affected systems are running Monterey, Big Sur, and Catalina.
One Mac that was able to print, stopped printing immediately after upgrading from 12.1 to 12.2.
One Mac on 11.6.0 was printing yesterday, but stopped printing today. JAMF shows "ProfileList" updated just before it stopped working.
This is happening on both our Prod and Dev instances of JAMF.

Workarounds

I am able to set any Mac up to print straight to the printer using LPD protocol and the printer IP address with the correct driver.

If the user profile on the Mac is named after the AD profile, then I can use LPD to print to Papercut on the print server (after loading the PaperCut LPD service). Address: (IP or FQDN of print server), Queue: (PaperCut Printer Name).

My coworkers think it is JAMF "JAMF-ing up the Macs". But I can't see anything on the JAMF side that has done anything to the Macs, and no changes to printing have happened lately.

[VintageMacGuy]

After digging into the logs a bit more and seeing that SMB was not able to see the server, I want back and took another look at my notes and it looks like we did not use the fully qualified domain name to set these up originally. I did a quick test on two Macs that were not working and manually set them up with SMB://printserver.domain.com/PapaerCutPrinter and they seem to work now.

[Qwheel]

Tested my own machine and that's done the trick for me too ;)

[nstrauss · Accepted solution]

This is directly related to RPC changes in 12.2, 11.6.3, and Catalina security update 2022-001 (build 19H1713) in response to PrintNightmare. Nothing to do with Jamf or MDM in general. 😀 All of these have the patch Apple describes as...

"Resolves an issue that prevented authenticating to a Windows print server with increased RPC authentication level."

https://support.apple.com/en-us/HT212586

I'm curious to hear if you found it was resolved by switching to FQDN as the print queue URI. What were you using previously? smb://printserver/queuename? The only solution (which I hate) I've found is to turn off encryption with a URI parameter. For example, use smb://printserver.mydomain.com/queuename?encryption=no. Obviously not secure and not a long term solution. There's some anecdotal evidence the problem is with aliased URIs, but I don't have enough first hand knowledge to know if that's true. What version of Windows server are you running? Fully patched?

Apple is fully aware of the issue and collecting impact data from customers. If you have a support contract with them I'd ask you open a case. Feel free my reference my own open case 101616149128. The more customer impact data the better.

[mainelysteve]

I had to switch back to lpd for the time being as SMB printing has broken twice this year and anytime a school teacher or secretary can't print it's the end of days! Running Server 2016 on my print server and have always used the fqdn. I had to roll back several patches about 2 1/2 weeks ago. We've had toner deliveries delayed for a lot of our MFP's so there's that thrown into the mix as well.

[VintageMacGuy]

Update - after doing about 12 test prints across 4 Macs that were not working and now seemed to be working after using the FQDN, I hopped to my Mac to set up the printers and add them to JAMF. But now MY Mac is not printing - even with the fully qualified domain name being used. I also tried the "?encryption=no" switch in the URI and it still attempts to print, then pauses the queue. I am running patches on it now to get it up to 11.6.3 and see if that helps. I had one test machine that was not updated and had no problems printing with just the server name (not FQDN). Then I ran the update to 12.2 (from 12.1) and after the update, it stopped printing and showed the same signs as other fully patched Macs. But that went away when I added the domain name into the printer server path and they started working - however it takes a good 30 seconds to a minute to connect to the server. Anybody know a way to speed that up? Printing straight to the printer IP with LPD only takes about 2 seconds.

Interesting note about aliased URIs since we are using PaperCut to manage prints. It may be using an alias to redirect to our printer. One of our sites has two printers, but you print to the "building" and then swipe your badge at any printer and the job will be printed at wherever you swipe your badge. That may be using some type of alias or a similar mechanism that may show the same problems.

[mainelysteve]

We use Papercut here as well. Still have clients with smb queues and at present they're fine, but I migrate them to lpd if they have job pausing issues. We use the kerberos SSO plugin to ensure print jobs match the user in PaperCut, but the local user matches too.

We use find-me queues as well and most of what occurs happens on the application server not the print server side of things. You print to the "virtual queue" then the job gets redirected on the application server when they're released to the actual physical queue.  

On a client check the operation policy of a queue in CUPS and maybe change it to kerberos or authenticated if it's currently set to default.

[matje84]

We're also experiencing these printing problems and we use NoMad for kerberos tickets. However, my local test Mac kept printing fine despite upgrading from macOS 11 to 12. I've been testing the Apple SSO plugin on that machine and the profile was still on there, not authenticated though. As soon as I remove the profile it stopped working. I reinstall it and everything works fine. Mind you, all this time NoMad was installed and authenticated.

[VintageMacGuy]

Update 2 - Still unable to get my Mac to print despite an OS update, Printer driver reinstall, OS reinstall, Removal of a VPN client I was testing, and reinstalling from Self Service. I also tried with and without a FQDN and even tried a generic PS printer driver to try to rule the driver out. Creating a new printer takes about 3 full minutes to finish and the printer pauses after about a minute of trying to print a test page.

Baffled. I was able to get this working on 4 other computers by adding the FQDN for the print server.

[chrisB]

Check my posting on the Apple Discussions Board:

https://discussions.apple.com/thread/253614543?answerId=256803525022#256803525022

Affected OS Versions:

• macOS 12.2 (Monterey)
• macOS 11.6.3 (Big Sur)
• macOS 10.15.7 (Catalina) with Security Update 2022-001

[abnaau]

Can you elaborate on what ?encryption=no does? 

I can't seem to find documentation. 

[chrisB]

My security officers checked the packages (with Wireshark) when sending print jobs with “?encryption=no” at the end of the printer URI:
One thing seems not critical, passwords are sent as hashes (not clear text), usernames apparently in clear text. (Macs aren’t AD bound here.)

But our security officers couldn’t figure out yet what “?encryption=no” is really changing …

I assume that only the print job will not be (fully) encrypted - maybe this was the default behavior of macOS before Security Update 2022-001 for 10.15.7 (Catalina), macOS 11.6.3 (Big Sur) and macOS 12.2 (Monterey):

"Resolves an issue that prevented authenticating to a Windows print server with increased RPC authentication level."

see: What's new for enterprise in macOS Monterey (v12.2)

I guess this applies only to the SMB part (the document to print) because it’s (only) an URI thing.

[chrisB]

I got more details from our Wireshark traces.

• The connection establishment of the SMB session is identical.
• The NTLM protocol flow within SMB is identical.
• The protocol flow for the SMB session is identical.
• All SMB Capabilities are identical (MultiChannel, Integrity, Encryption, Ciphers, Nego, etc.).
• The share flags, share capabilities and access mask are identical.

The standard macOS 12.2 client sends a "Tree Disconnect Request" ( with default printer URI), instead of a "Tree Connect Request" (with "encryption=no" addendum) - this is the only difference at the network level that causes the printing process to be aborted:

  

The comparison of the traces with the Finder access to the print server and the access via print management, however, shows some differences (on macOS 12.2 with default settings):

[  green = Finder access on print server  //  red = macOS printing  ]

• Multichannel behavior:

 

• Encryption capabilities:

• Share Flags:

 

 

[VintageMacGuy]

So - the weird thing is, I checked our print servers and they don't have the Windows updates that did this. And these updates came out a few months ago, but the problems just started last week.

And I still have one Mac that, no matter what I try, won't print to SMB. Four others are OK after converting to the FQDM.

Maybe these are red herrings, but I can't call it solved yet for these reasons. Going to check with our security and server teams to see if they have any more info.

[chrisB]

This time the Apple Updates were the cause (see above):

Affected OS Versions:

• macOS 12.2 (Monterey)
• macOS 11.6.3 (Big Sur)
• macOS 10.15.7 (Catalina) with Security Update 2022-001

[homepup]

Experiencing the same here this week and narrowed it down the the same affected systems and the ?encryption=no does seem to resolve it. Looking into seeing if there might be a setting server side that will allow it to function again without having to change this for thousands of users (most of which aren't in Jamf).

[mainelysteve]

There is. You can dive into regedit on the server with your queues and turn the RPC auth level down/off. I'd run it by your security team or give it a second thought before doing so. 

[trayner]

Did you have any luck finding a server side resolve at all? Like you I don't fancy changing this for all managed devices. 

[homepup]

Not yet and honestly are thinking about mostly just waiting and crossing our fingers on Apple dropping an update to fix this mess since it's fairly widespread.

We can either make some changes on the Windows server that fixes it for some OS versions, or a change that lets it work for others, or we can make a change that breaks everything. No solution for all OS versions. And if you do the ?encryption=no change to the printer path, it seems it should only be applied to the latest OS versions (12.2, 11.6.3, etc.) or else it breaks printing on older OS versions, but that could just be our setup. 

At least we already had AirPrint setup on the major printing queues so we have a usable work around for now, but definitely don't want to use that long term.

[chrisB]

The ?encryption=no change does not break printing on older versions of macOS 10.15 (Catalina), macOS 11 (Bit Sur) or macOS 12 (Monterey) as far as we could see (and other versions of macOS aren't supported anymore by Apple and various others incl. Microsoft).

[VintageMacGuy]

I have recreated the printer on my Mac, added it to JAMF and replaced the self service policy printer with the new one I just created that has the FQDN and ?encryption=no. But now I see a new problem.

The Mac I created the new printer on, then uploaded to JAMF (freshly imaged) will print a document in about 4 seconds. But the Macs I added the printer to via Self Service take about 50 seconds to print the same test page.

[chrisB]

Check the SMB Multichannel settings - and try disabling multichannel for macOS 11.3 (Big Sur) and newer with the following command:

echo "[default]\nmc_on=no" | sudo tee -a /etc/nsmb.conf

Source: https://support.apple.com/en-us/HT212277

[chrisB]

I’m pretty sure the macOS Update 12.2.1 (Monterey) deleted my /etc/nsmb.conf file … :-(

*** Update: Sorry, checked on a 2nd Mac and the file is still there.  ***

[chrisB]

Once again: (presumably) after macOS updates the /etc/nsmb.conf file has been deleted - now seen on several (but not all) Macs here.

[chrisB]

I'll try to workaround the removal by expanding my script (as follows):

#!/bin/zsh


# Variable Setting (File Path)

nsmb_conf=/private/etc/nsmb.conf


# Removing (possible) Immutable Flags

sudo chflags nouchg,noschg $nsmb_conf


# Removing /etc/nsmb.conf File (for Debug Purposes)

# sudo rm -f $nsmb_conf


# Disable SMB Multichannel Support

if [[ -f $nsmb_conf ]]; then
echo "mc_on=no" | sudo tee -a $nsmb_conf
echo "nsmb.conf already existed & SMB Multichannel Support successfully disabled."
else
echo "[default]\nmc_on=no" | sudo tee -a $nsmb_conf
echo "nsmb.conf (newly) created & SMB Multichannel Support successfully disabled."
fi


# Apply Read-Only Permissions (even for root)

sudo chmod 555 $nsmb_conf


# Apply System Immutable Flag

sudo chflags schg $nsmb_conf


exit 0

I tried first to use the users' home folders  [~/Library/Preferences/nsmb.conf] to avoid the file removal (presumably after macOS updates) as it was possible earlier, but this didn't work - at least in macOS 12.3.1 (Monterey).

So I made the nsmb.conf file read-only and set the system immutable flag.

(The system immutable flag has to be removed first in order to remove or edit the file itself.)

For now, I'll wait and see what happens after the next (Monterey) update ... :-)

[VintageMacGuy]

Disabling multichannel SMB seems to have sped up print times quite a bit. Thank you.

[scottb]

@VintageMacGuy - seeing the exact same thing for the Ricoh SMB printers here!

Our first print job goes right through, and all subsequent print jobs take ~45-60 seconds.  Makes no sense. 

Made two different printers - one normal, one I turned off encryption.  I'm at a loss as how to fix this...

Printers in Self Service seem to have this behavior.  If I make them programmatically and then wrap in a .pkg, they work fine ¯\_(ツ)_/¯ 

[teodle]

According to Apple, "When SMB Multichannel is enabled, and more than one network is available, macOS prefers the network that advertises itself to be the fastest." 

So in our environment, most if not all users are connected to Enterprise Wifi only--most if not all user machines don't even have ethernet ports nor do the offices and lab spaces have active ethernet ports in the walls. So why would multichannel SMB be relevant in such an environment? Just trying to figure out why it would make a difference, seeing as it only seems to apply to cases where there's more than one network readily available to the end user. 

[VintageMacGuy]

We are in the same situation - only wifi at the desktops. Yet this speeds up printing quite a bit. From about a minute of trying to connect to the server, to about three seconds before the job is gone from the local queue on the Mac.

[teodle]

are you also using the "?encryption=no" appended to the end of device uri?

[VintageMacGuy]

Yes - we are using ?encryption=no and this seems to have resolved most of the issues, but we have a subnet that is still not working properly and creating a pause.

[MrRoboto]

We print to Windows 2016 print queues over SMB, they already have "RpcAuthnLevelPrivacyEnabled" set to 0 from last year's print nightmare. Clients updated to macOS 12.2 can't print, Paused - "rpc_binding_set_auth_info" error. Adding “?encryption=no” to URI resolves the issue, alternatively upgrading to macOS 12.3 beta 5 works. 

[davidhiggs]

For those seeing issues with slow print jobs before or after macOS changes for smb printing, recommend turning off SMB Multichannel on Windows Server: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn...

This is a better solution for macOS clients, especially if that server is only hosting smb print queues and it's not being used for smb file shares.

[chrisB]

---

@davidhiggs wrote:

For those seeing issues with slow print jobs before or after macOS changes for smb printing, recommend turning off SMB Multichannel on Windows Server: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn...

This is a better solution for macOS clients, especially if that server is only hosting smb print queues and it's not being used for smb file shares.

---

Last month we turned off SMB Multichannel on our Windows print servers, so print jobs not only on managed Macs are processed quickly (again). Thanks for the hint!

[echeveste]

We also started seeing this problem in the past few days. It appears that upgrading to Monterey 12.3 has fixed the issue for us.

[abnaau]

We're seemingly still seing the issue with 12.3. Error message changed from "rpc_binding_set_auth_info" to "Unable to connect to printer" though. 

Any troubleshooting hints appreciated :) 

[MrRoboto]

"Unable to connect to printer" means printer offline or defunct printer queue in my environment. Also appears if the security permissions on the printer queue do not allow the user to print.

[chrisB]

Tested macOS 10.15.7 (Catalina) with Security Update 2022-003, macOS 11.6.5 (Big Sur) and macOS 12.3 (Monterey) - all macOS Updates from yesterday resolved this printing issue (you don't need to add "?encryption=no" anymore).

[matje84]

It's not resolved on our side, we still need to add the "?encryption=no". I see your machines are not AD bound. How do you authenticate? Username and password or kerberos? If kerberos, how do you get the ticket? Thanks.

[chrisB]

Our Macs are not AD bound, and we're authenticating with username/password (NTLMv2).