Yosemite does not fix the file sharing problem with SMB between Mac OS and Windows. I have had to disable SMB2/3 in Windows in order to get reliable file sharing between the two OS'. Apple is doing great with new GUI usability features but has fallen seriously behind on the fundamental back-end tech like networking and file systems.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
SMB Networking with Windows Still Broken
- Thread starter msh
- Start date
- Sort by reaction score
What's the problem, exactly?
I had endless issues with SMB in Mavericks, but it seems to be working fine in Yosemite. It's super stable/responsive and the transfer speed has also improved slightly.
On the Mac, I'm using the hostname to connect to the PC, and on the PC, I'm using the IP address to connect to the mac. No issues so far, knock on wood.
I share out a 5 TB media library from my MacPro to JRiver on Windows 7 over ethernet. Windows frequently loses the share connection or JRiver crashes and freezes. This was true under Mavericks and Mountain Lion but not Snow Leopard.
The network configuration is: on the Mac side, file sharing on, media volume shared out with read/write permissions set, SMB on. On the Windows machine, no special configuration as the NETBIOS name of the Mac (from the WINS configuration settings in the Mac network settings) just appear in the Windows network with the shared media volume.
So how are you doing it? Are you mapping a network drive in Windows using the Mac IP address and assigning a drive letter?
If you are using Windows 7 or better then to easily for SMB1 is to use the cifs string instead of the traditional smb code. This will force a SMB1 connection.
I have now changed how I mount the Mac Share from the PC using the ip address method as Nope7308 suggested. And I am getting a trouble free connection so far. Maybe there is something problematical with that NETBIOS connection method from the Mac. We'll see.
Yep, that's my config on the PC side and everything is smooth as butter. I used the hostname to connect on the Mac side, and then I created an alias of the mounted drive/shared folder and put the shortcut in the dock. It now functions like a native folder so as soon as I click it, the drive/shared folder is mounted and we're good to go. Everything is instantaneous with no lag and the connection never drops -- a big improvement over Mavericks.
I am now getting the same performance from the Win-->Mac connection via direct IP address mapping. However, I still have SMB2/3 disabled in Win7 because that was the only way I could somewhat reliably connect using the Mac assigned NETBIOS name. I will re-enable SMB2/3 on Windows and see what happens. I hope all this works because I have been going down a rathole the last few days trying to configure NFS (without success) as an alternative to SMB.
UPDATE: I re-enabled SMB2/3 on Win7 and immediately get errors that Mac share not recognized, followed by showing the share directory but no access to the files within the directory tree. So for my machine, Apple's smb on Yosemite does not work with Microsoft's smb/2/3 - same as Mavericks.
Last edited:
SMB in Yosemite is broken on authentication level. It provides no compatibility with SMB1 and SMB2, it will only accept strict NLMv2 level, to any other client the server will respond with:
digest-service[45647]: digest-request: kdc failed with -1561745600 proto=ntlmv1
digest-service[45647]: digest-request: guest failed with -1561745590 proto=ntlmv1-with-v2-session
usually resulting in client app repeatedly asking for password.
You can work around it by enabling "Send NTLMv2 response only" option on Windows clients, but outside of home environment this is unworkable - nobody is going to go around the office, changing registry settings in hundreds of Windows machines just so they can connect to a single Mac share. It also doesn't resolve issues for Linux, Android, embedded or mobile platform clients and tablets trying to use smb share from Yosemite computer.
In fact I am shocked and surprised that a month after launch, we are still sitting here and talking about it and Apple didn't fix it, while hundreds of offices and studios around the world shuffle around with USB drives cause their network shares stopped working. It's just complete lack of corporate responsibility.
digest-service[45647]: digest-request: kdc failed with -1561745600 proto=ntlmv1
digest-service[45647]: digest-request: guest failed with -1561745590 proto=ntlmv1-with-v2-session
usually resulting in client app repeatedly asking for password.
You can work around it by enabling "Send NTLMv2 response only" option on Windows clients, but outside of home environment this is unworkable - nobody is going to go around the office, changing registry settings in hundreds of Windows machines just so they can connect to a single Mac share. It also doesn't resolve issues for Linux, Android, embedded or mobile platform clients and tablets trying to use smb share from Yosemite computer.
In fact I am shocked and surprised that a month after launch, we are still sitting here and talking about it and Apple didn't fix it, while hundreds of offices and studios around the world shuffle around with USB drives cause their network shares stopped working. It's just complete lack of corporate responsibility.
That doesn't even work in a home environment with a single share. I have repurposed an old Mac Mini running Snow Leopard as a simple file server to Windows - works like a charm. Snow Leopard was the last time Apple used Samba. Since then (2-3 years right?) it has been Apple's own smb implementation. With all the resources they have they can't get simple *#$king networking right?
Except that such a setup is not found outside of home environments/very small businesses. Any business that uses more than 1 client usually uses 1 central place where they store stuff such as a server or a NAS. In that case there is no need to change this option on the client side. Also, in case of a rather large network, chances are that there will be a domain controller of some sort. It is quite common to use a GPO to rollout such changes.
You are using cases where it is highly unlikely this will ever be a problem.
Perspective of a user of OpenZFS on OS X
For what it's worth, at https://openzfsonosx.org/forum/viewtopic.php?p=4760#p4760:
For what it's worth, at https://openzfsonosx.org/forum/viewtopic.php?p=4760#p4760:
It's unsurprising that sharing a volume in an unsupported format, with an unsupported-by-Apple driver should cause unreliable operation.
So a third party product doesn't work and it is apples fault. I just don't get people's logic at times.
I use zfs at home for the last 3 years. My mini connects to the iscsi instances and happily shares out using afp and smb. Sure I need to wait for updated iscsi drivers when a new OS comes out but hey ho why wouldn't i?
I use zfs at home for the last 3 years. My mini connects to the iscsi instances and happily shares out using afp and smb. Sure I need to wait for updated iscsi drivers when a new OS comes out but hey ho why wouldn't i?