FYI - 10.12.5 issues with SMB mounting

Kyuubi
Contributor

Just putting this out there: there is a known issue with the 10.12.5 update and SMB. After updating I can no longer connect to shares via SMB. Called in and spoke with Apple yesterday and they are aware. Engineers are working on it now. Our environment is AD so I was no longer getting the prompt for my credentials. It would never actually connect. One workaround was to put (smb://username:@server.domain.name/sharename)* in the connect to server window . This allowed me to connect but would not accept my password and eventually locked me out. Maybe it will work for you.

38 REPLIES 38

Ryan_
New Contributor II
New Contributor II

Thank you for the heads up, this is helpful information.

Taylor_Armstron
Valued Contributor

Any more details? Versions of SMB or back-end server info?

FWIW, having no problems here connecting to SMB or CIFS shares from 10.12.5, servers are restricted to SMB2 connections. We just pushed 10.12.5 out to our test group last week, so very curious before we push to production.

Kyuubi
Contributor

Updated the workaround does work. My account was being locked out for another reason.

Excerpt of an email from the Apple engineers:
I understand that after updating to 10.12.5 clients may hang indefinitely at connecting to an SMB server. If my understanding is incorrect, let me know.

We have received other reports of this behavior, however it is unusual that specifying a colon after the username is not successful workaround for your organization (smb://username:@server.domain.name/sharename). To assist in our investigation, please provide the following:

KSchroeder
Contributor

We've seen the same issue, but it is very sporadic. One machine which wasn't working consistently, began working the following day when we tried to test more and reproduce the issue. My case # for reference: 100195322890. Most of our users have moved on to OneDrive for file access, and most aren't on 10.12.5 yet as we disabled updating via AppStore after we heard about this issue. So it is tricky to track down. Trying to gather more info and the logs (sysdiagnose, tcpdump, etc) Apple wants. They also suggested these workarounds/tests:
a. Connecting without the share name, smb://servername
b. Connecting to smb://username:@servername/shareName
c. Connecting via command line ‘mount –t smbfs //user@servername/share /tmp/mountpoint’

PeterClarke
Contributor II

We appear to be able to use smb based connections with macOS 10.12.5 without any issues.

Although there are some smb based systems we haven't tested it with yet…

Mhomar
Contributor

Hi All, I too am seeing this behavior on 2 updated 10.12.4 -> 10.12.5 Unit test computers. The workaround (smb://username:@server.domain.name/sharename) is working for my account on both test computers. I am reluctant to push this out to anything more than 1 or 2 pilot computers. I will be keeping an eye on this thread to see what may come of it. in the mean time I will try to research it further.

brettml
New Contributor

We are seeing this issue too in 10.12.5 and in the 10.12.6 beta 1. I've opened a bug report with Apple and am waiting to hear back. The workaround presented above is helping in the meantime.

RedWings
Contributor

We have this issue on 4 Macs running 10.12.5. It is very sporadic as we have 30+ Macs running 10.12.5. I've opened a bug report with Apple as well. We are using the aforementioned workaround until we hear back from Apple Hopefully this is addressed in 10.12.6 before it ships.

KSchroeder
Contributor

We did hear back on our case that Engineering is working on a fix; hopefully we'll see it in 10.12.6 Beta 2.

annamentzer
New Contributor II
New Contributor II

We are having this issue on 10.12.5 and the (smb://username:@server.domain.name/sharename) workaround functions intermittently. I have found, however, that killing the AppleIDAuthAgent process will allow connections when the workaround will not. If you are scripting this, you will need to run it with the -9 flag ( for a non-catchable, non-ignorable kill):

pkill -9 AppleIDAuthAgent

To see if this is your issue, try to mount the server, then take a look in Activity Monitor and see if this process is running. Force quit it and the mount should occur instantly.

bmack99
Contributor III

I too am seeing this SMB bug(albeit sporadic) on a couple of our systems. Other machines are working fine after updating to 10.12.5. Thanks for the info, will be testing workaround(s) today.

theelysium
New Contributor III

You saved my butt, thanks! smb://username:@server.domain.name/sharename

Kallendal
New Contributor III

This worked well in testing. pkill -9 AppleIDAuthAgent

However, after ~ 3 minute, needed to run it again.

... didn't matter if it was printing, or SMB connection the command worked.

So now, need to figure out a long term implementation of the command, when where and how.

jkarpenske
New Contributor III

We'd been having zero problems with SMB on our 10.12.5 machines until yesterday, when I couldn't install software via policy because the target machine couldn't mount the share. This morning, my primary workstation just stopped talking to SMB shares about an hour ago. Checked to make sure the shares weren't still connected, rebooted, etc...no joy. However, the "pkill -9 AppleIDAuthAgent" command as suggested by @annamentzer has allowed me to get reconnected. THANK YOU!

RedWings
Contributor

Anyone know of macOS 10.12.6 beta 2 (released yesterday) resolves this issue?

tnielsen
Valued Contributor

Heard back from Apple. This is apparently going to be a future feature update. iSMB will retail for about 5k for the company in order to allow for SMB connections again.

KSchroeder
Contributor

What is iSMB? ANd does "future featuer update" mean 10.12.6 for example?

KSchroeder
Contributor

What is iSMB? And does "future feature update" mean 10.12.6 for example?

tnielsen
Valued Contributor

I'm just fucking around. I wouldn't be surprised if they pulled some shit like that though.

dstranathan
Valued Contributor II

Starting in 10.12.5, I have seen this Finder dilog box appearing before any SMB volumes are mounted from scripts (including a Jamf login script). It appears to be intermittent. Definitely not consistent.

Is this new behavior in 10.12.5? I dont recall seeing it before...

a9c322e2b14b428b8432cada74d229af

Dinnerticketboy
New Contributor III

Edit /etc/nsmb.conf
and add
signing_required=no

AVmcclint
Honored Contributor

@dstranathan I've been seeing that randomly since 10.12.4. It doesn't happen every time and it doesn't happen to every server or even every user. It's very inconsistent. It doesn't stop users, but it does slow them down a little when they have to process this unexpected message.

Dinnerticketboy
New Contributor III

Edit /etc/nsmb.conf
and add
signing_required=no

KSchroeder
Contributor

Should the /etc/nsmb.conf file exist by default? I don't see it on my 10.12.5 Mac...does this also help with the hangs while mounting SMB shares and/or printing to Windows-based printers?

dstranathan
Valued Contributor II

Thank you @CasperSally - Not sure how I could have possibly missed this behavior since 10.12.2! Weird...

@KSchroeder No, the /etc/nsmb.conf file doesnt not exisit unless something (or someone) generates it. I belive it's a FreeBSD config file specific to SMB/CIFS clients (i.e.; not servers).

My nsmb.conf file is failry simple:

[default]
streams=yes
file_ids_off=yes
signing_required=no

(I manage it with an Jamf extension attribute along with a policy/script that generates the config file on newly-deployed systems (and any system that is missing the file for some reason)

There a a lot of switches that can be tweaked to optimize SMB sessions/mounts in the nsmb.conf file. Failry granular.

I have used /etc/nsmb.conf hand-in-hand with /etc/sysctl.conf to fine-tune my Macs for my EMC/Isilon file servers.

type man nsmb.conf and man sysctl.conf for the juicy details.

olejkodf
New Contributor

Editing nsmb.conf worked perfectly for me. Thanks!

Key1
New Contributor III

Anyone getting account lockout with this issue also?

MaryDuffy
New Contributor

@redwings, the 10.12.6 Beta (16G23a) update appears to have fixed the problem for us.

RedWings
Contributor

@MaryDuffy Thanks! I'll give it a go!

RedWings
Contributor

@MaryDuffy Thanks! I'll give it a go!

CullenO
New Contributor

Took me forever to find a solution(strangely Google/searching JAMF did not bring this back as a result... but plenty of results from 2012...)

thanks for the info

chmeisch
New Contributor III

@Key1 We've been having some issues with login times after sleep/re-opening the macbook lid.. Unsure if it's related. I can't consistently recreate the issue, on my mac minimally. However we have some VIPs that are complaining and swearing it's happening to them consistently..

gkotlinski
New Contributor

As of today's release of the 10.12.6 update. I downloaded and upgraded my first test machine. My machine that has been plagued by not being able to mount SMB shares. It seems to be working normally again with the 10.12.6 update.

Thanks to annamentzer. Her work around helped me get by till today.

Just thought I'd share.

merc_support
New Contributor III

@annamentzer - running the command worked for a couple of users we've tested so far.
@dstranathan - unfortunately creating that file didn't work initially, had to run the suggested command to get the SMB shares to mount.

pkill -9 AppleIDAuthAgent

Seems to be limited to pre-existing 10.12.5 user profiles as well. New users did not appear to be affected with mounting SMB shares or connecting to network printers.

One client also isn't executing any login / logout hooks, in fact no Casper policies set to run at logon, with any frequency (e.g. Ongoing). We can manually get the policies to run though (e.g. sudo jamf recon, or sudo jamf policy -event login). Not sure if this is related at this stage. Looking at a re-image for this particular iMac.

A complete image with 10.12.5 also did not present the problem for us (obviously not an ideal with active clients).

We use AD in our environment - curious to note that on local user profiles the "OUR-DOMAIN/Domain Users" Network Group has read permission. Is this also new?

Using a Casper policy to execute the script on login as a temporary band-aid. Watching with interest for the final release of 10.12.6!

kyleblanc
New Contributor III

@dstranathan

Would you be willing to share some of your process of using sysctl.conf for managing EMC/Isilon shares? I have been running into some real headaches with our Isilon shares here and would love to give this a try.

Thanks!

dstranathan
Valued Contributor II

I think currently we are setting this on 10.12 Sierra clients:

net.inet.tcp.delayed_ack=0

But our settings have changed over the years based on the version/type of EMC/Isilon gear we were running as well as the version of MacOS (and version of SMB/NFS too, of course). EMC publishes client recomendations in a best practice PDF guide from time to time. Example: "Using Mac OS X with Isilon OneFS Sept 2014"). Your EMC rep/support team should be able to make recomendations and send you the PDF.

cpmac
New Contributor

sudo sh -c "echo '[default]' >> /etc/nsmb.conf; echo 'protocol_vers_map=1' >> /etc/nsmb.conf"

This worked for us.