Skip to main content

Has anyone experienced difficulty mounting a Windows 2012 R2 Server SMB distribution point on a Yosemite (10.10.1-10.10.3) Mac?



If so, what solution was found?



We are experiencing a Yosemite SMB3 connectivity problem with Windows Server 2012 R2 after a physical server move. Our JSS and Master distribution point were up and running with no issues, then our server was shut down and moved to a datacenter. Now we are unable to consistantly mount the share on Yosemite Machines using SMB3. Most of the time receive an error message "You do not have permission to access this server" . We CAN mount the share on WIN7, OS 10.9.5 and earlier with no issues. We also can map the distribution point as a share in the Yosemite finder by forcing the SMB1 stack using the CIFS (<server name>/caspershare) protocol instead of SMB (smb://<server name>/caspershare). This is OK for mapping a share for file access for an end user, even though it is slower, but it we need to resolve the SMB3 connectivity issue between the Casper Client on Yosemite machines and the Windows 2012 R2 Server where the JSS and Master Distribution point resides. We checked with our Server team and ports 139 (SMB) and 548 (AFP) are open from the client to the server; they also say that everything is working as it should and no settings were changed on the server prior to the move. However, the fact remains that Yosemite Macs can no longer mount the SMB distribution point with any consistancy I believe this may be a Windows 2012 R2 Server configuration issue, but I am unsure as I am not Win Server Admin.



We looked at this Microsoft KB document regarding SMB Stacks



http://support.microsoft.com/en-us/kb/2696547



and we disabled SMB2&3 on the server. The distribution point worked on Yosemite after that. However, Microsoft says you can't leave the server that way "Warning: We do not recommend that you disable SMBv2 or SMBv3. Disable SMBv2 or SMBv3 only as a temporarytroubleshooting measure. Do not leave SMBv2 or SMBv3 disabled.”



So, we are still looking for a solution.

Are your MAC's are on the domain? If they were able to connect before and they cant now can you look in the key chain and delete any entries they might have and try connecting to the share again. I haven't experienced any issues in my environment.

you also might want to try kdestroy -A and see if kerberos is causing the issue. I have not gotten around to testing SMB mounts as I am traveling right now. Maybe in the morning.

@asegura We have a blend of Macs both bound to AD, and stand alone. The SMB share problem only seems to be happening for Yosemite Macs regardless of whether they are on AD or not, including out of the box Yosemite Macs. When we disable SMB2 & 3 on the Windows 2012 R2 server the Yosemite Macs can connect via SMB1, but this is not a solution as per Microsoft's KB doc in the first post. The problem occurred only afterwhen the server was moved.



@nessts We will give "kdestroy -A" a try, thx.

You can force connections to default to SMB1 via an nsmb.conf file placed in /etc



sudo echo "[default]" >> /etc/nsmb.conf
sudo echo "smb_neg=smb1_only" >> /etc/nsmb.conf



Probably need a restart in order for this to take effect.

Out of curiosity are ports 137, 138, and 445 open for SMB traffic on the Server/DC Firewall? Also the AFP port should not be necessary to a Windows server unless you are using a third party product like ExtremeZ-IP to create an AFP protocol on your Windows server.

@RobertHammen Thanks. That worked, but we are still trying to get SMB 2 and 3 to work. We will keep this as a solid plan "B" . Thx.



@tjwolfui Ports 139 and 445 are open. Ports 137 and 138 are closed. Do we need 137 and 138 open? Please let me know your thoughts.



They are not listed in the knowledge base article "Network Ports Used by the Casper Suite", but they are listed in the "Service overview and network port requirements for Windows" https://support.microsoft.com/en-us/kb/832017#method67. for the below services.



137 UDP NetBIOS Name Resolution Computer Browser
137 UDP NetBIOS Name Resolution Server
137 UDP NetBIOS Name Resolution Windows Internet Name Service
137 UDP NetBIOS Name Resolution Net Logon
137 UDP NetBIOS Name Resolution Systems Management Server 2.0
138 UDP NetBIOS Datagram Service Computer Browser
138 UDP NetBIOS Datagram Service Messenger
138 UDP NetBIOS Datagram Service Server
138 UDP NetBIOS Datagram Service Net Logon
138 UDP NetBIOS Datagram Service Distributed File System
138 UDP NetBIOS Datagram Service Systems Management Server 2.0
138 UDP NetBIOS Datagram Service License Logging Service

Technically 137 and 138 are not needed if you are directly hosting SMB over TCP. See https://support.microsoft.com/en-us/kb/204279 Having said if your client OS X systems or Windows systems attempt to use NetBIOS to find the share they will fail to connect to the SMB share with ports 137 and 138 closed. Best practice in my opinion would be to open 137 and 138 when creating an SMB share to ensure that all types of SMB client request to the server can be successfully processed.

@rirwin1



Please check out this jamf thread and scroll to the very end



Please try using my configuration settings and let us know if you can get smb3 to work.

I am also having this problem I can not get an smb share to mount through casper admin on a 10.10.3 or 10.10.4 beta

run df in a terminal to see if the share is mounted still. I just had issues that were caused by the smb share not unmounting when closing casper admin. Once I manually unmounted the share I was able to reliably connect again.

Reply


Terms & ConditionsCookie settings