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.
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:
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’
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.
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.
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!
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:
(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.
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.
@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!
I think currently we are setting this on 10.12 Sierra clients:
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.