Posted on 05-24-2017 06:47 AM
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.
Posted on 05-24-2017 06:59 AM
Thank you for the heads up, this is helpful information.
Posted on 05-24-2017 07:19 AM
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.
Posted on 05-24-2017 08:31 AM
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:
Posted on 05-24-2017 08:55 AM
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’
Posted on 05-24-2017 09:35 AM
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…
Posted on 05-25-2017 04:05 PM
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.
Posted on 05-30-2017 12:54 AM
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.
Posted on 05-30-2017 07:44 AM
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.
Posted on 05-30-2017 08:18 AM
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.
Posted on 05-30-2017 01:44 PM
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.
Posted on 06-01-2017 05:58 AM
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.
Posted on 06-02-2017 10:53 AM
You saved my butt, thanks! smb://username:@server.domain.name/sharename
Posted on 06-02-2017 01:43 PM
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.
Posted on 06-06-2017 06:59 AM
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!
Posted on 06-06-2017 07:42 AM
Anyone know of macOS 10.12.6 beta 2 (released yesterday) resolves this issue?
Posted on 06-06-2017 10:12 AM
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.
Posted on 06-06-2017 12:56 PM
What is iSMB? ANd does "future featuer update" mean 10.12.6 for example?
Posted on 06-06-2017 12:56 PM
What is iSMB? And does "future feature update" mean 10.12.6 for example?
Posted on 06-07-2017 12:09 PM
I'm just fucking around. I wouldn't be surprised if they pulled some shit like that though.
Posted on 06-09-2017 07:53 AM
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...
Posted on 06-09-2017 08:00 AM
Edit /etc/nsmb.conf
and add
signing_required=no
Posted on 06-09-2017 08:01 AM
@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.
Posted on 06-09-2017 08:02 AM
Edit /etc/nsmb.conf
and add
signing_required=no
Posted on 06-09-2017 08:05 AM
Posted on 06-09-2017 11:43 AM
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?
Posted on 06-09-2017 11:57 AM
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.
Posted on 06-29-2017 05:18 AM
Editing nsmb.conf worked perfectly for me. Thanks!
Posted on 07-06-2017 02:55 AM
Anyone getting account lockout with this issue also?
Posted on 07-06-2017 02:00 PM
@redwings, the 10.12.6 Beta (16G23a) update appears to have fixed the problem for us.
Posted on 07-06-2017 02:04 PM
@MaryDuffy Thanks! I'll give it a go!
Posted on 07-06-2017 02:04 PM
@MaryDuffy Thanks! I'll give it a go!
Posted on 07-07-2017 07:29 AM
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
Posted on 07-12-2017 01:06 PM
@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..
Posted on 07-19-2017 02:29 PM
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.
Posted on 07-19-2017 09:36 PM
@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!
Posted on 07-27-2017 06:50 AM
@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!
Posted on 07-27-2017 07:08 AM
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.
Posted on 10-06-2017 08:20 AM
sudo sh -c "echo '[default]' >> /etc/nsmb.conf; echo 'protocol_vers_map=1' >> /etc/nsmb.conf"
This worked for us.