Yes. Sorry for the confusion. In my first line I said that I had issues with windows machines unable to see SMB shares on the Big Sur mac. I did not realize the issue was the other way.
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.
BIG SUR problems with SMB
- Thread starter lwilliams
- Start date
- Sort by reaction score
My Synology NAS supports afp. I've not heard anywhere that Windows supports afp? This thread is about the inability to list shares on Windows machines.
Apple Engeneers are working on the issue. I send them logs and thir response was
Thank you for uploading EDC file and packet trace today.
I have analysed the logs and packet traces, and saw that in packet trace we have the proper NetShareEnumAll response from the server in order to list the shares, also saw 101 shares is listed in 621 packet. However, we are getting timeout error in sysdiagnose which is unexpected:
default 2020-12-16 10:43:24.745649+0100 kernel smbfs smb_iod_sendall: Timed out waiting on the response for 0x0 message_id = 10 state 0x1
default 2020-12-16 10:43:24.777740+0100 kernel smbfs smb_iod_recvall: drop resp: message_id 10, cmd 8 status 0xc000014b
error
I have filed this issue to Product Engineering, currently the team is working on the issue. Could you please let me know how many devices are experiencing this issue in your organisation? I will add this information to our ticket, and will let you know once I have any update from Product Engineering.
Thank you for uploading EDC file and packet trace today.
I have analysed the logs and packet traces, and saw that in packet trace we have the proper NetShareEnumAll response from the server in order to list the shares, also saw 101 shares is listed in 621 packet. However, we are getting timeout error in sysdiagnose which is unexpected:
default 2020-12-16 10:43:24.745649+0100 kernel smbfs smb_iod_sendall: Timed out waiting on the response for 0x0 message_id = 10 state 0x1
default 2020-12-16 10:43:24.777740+0100 kernel smbfs smb_iod_recvall: drop resp: message_id 10, cmd 8 status 0xc000014b
error
I have filed this issue to Product Engineering, currently the team is working on the issue. Could you please let me know how many devices are experiencing this issue in your organisation? I will add this information to our ticket, and will let you know once I have any update from Product Engineering.
1. On upgrading to Big Sur 11.1 from 11.0.1, in sharing, shared folders and users that were set up had been blanked
2. On attempting fin finder to "Connect to" any other server, although I select "Registered User" I am connected with apple id to a sharepoint. Luckily I can still connect to the other servers via finder "connect to server" and smb:[server ip address]"
3. On installing the latest security update on another server running Catalina 10.15.7, "connect to" also will only connect to a sharepoint, though I select registered user.
I suggest the original poster's problem is with the Mac, not Windows.
2. On attempting fin finder to "Connect to" any other server, although I select "Registered User" I am connected with apple id to a sharepoint. Luckily I can still connect to the other servers via finder "connect to server" and smb:[server ip address]"
3. On installing the latest security update on another server running Catalina 10.15.7, "connect to" also will only connect to a sharepoint, though I select registered user.
I suggest the original poster's problem is with the Mac, not Windows.
Why do you think this problem which started in 11.1 is related to the one discussed on this thread?
Hi everyone, i think i found the solution!
- I login to windows 2016 server that hold the shares.
- go to control panel > uninstall program > turn windows features on or off > start the remove roles and features wizard
- under features, uncheck SMB 1.0/CIFS File Sharing Suport > restart server
- once the server back online, I can successfully access shared drive
- I reinstall SMB 1.0/CIFS File Sharing Suport > restart server
- tested again and I still can access shared drive
Hope this helps.
- I login to windows 2016 server that hold the shares.
- go to control panel > uninstall program > turn windows features on or off > start the remove roles and features wizard
- under features, uncheck SMB 1.0/CIFS File Sharing Suport > restart server
- once the server back online, I can successfully access shared drive
- I reinstall SMB 1.0/CIFS File Sharing Suport > restart server
- tested again and I still can access shared drive
Hope this helps.
I think I have already tried that, but I will do it again now and see what happens.
got some more updates. i tried on couple servers and it works. i tried on more servers but it did not work.
i compare Windows update on all servers and it looks the same. on other servers that don't work, one is domain controller and other is regular server so server role is not the issue.
so back to square one...
i compare Windows update on all servers and it looks the same. on other servers that don't work, one is domain controller and other is regular server so server role is not the issue.
so back to square one...
This is a tough one.
Can you confirm we are talking about the exact same problem? For a server that wasn't working, were you able to use a share that you knew the name of? That is, were you able to browse files on the servers before the fix?
Remember that the bug this thread is about is only the inability to list available shares, not the inability to use them if you already know their names.
That's correct. for the server that not working, I am ABLE to map the server with share name. I am NOT ABLE to browse all share names by only put in the server name or server IP address.
I rebuild MAC with latest BIG SUR 11.1 but that did not make difference.
I rebuild MAC with latest BIG SUR 11.1 but that did not make difference.
I have learned a lot by participating, even though I haven't managed to add any value. But, from what I saw in the couple of logs people sent me, the SMB dialect was not the problem. I never got my hands on anyone's packet trace, but I was able to figure something out by comparing to provided logs with my own logs and my own packet traces.
In both problem logs the error happened after SMB negotiation (choosing the SMB dialect) and after the security negotiation. After all that was done, the Mac requested the Windows machine to list its shares. And then the world stopped.
One of us did get a response from support who looked at a packet trace and it revealed that Windows was successfully returning the list of shares but then the Mac failed to process them in a timely manner. So it seems like it's a Mac bug. It's very strange that manipulating dialect support on Windows would have any influence over this problem. But, bugs can't be reasoned with, they often behave irrationally.
In both problem logs the error happened after SMB negotiation (choosing the SMB dialect) and after the security negotiation. After all that was done, the Mac requested the Windows machine to list its shares. And then the world stopped.
One of us did get a response from support who looked at a packet trace and it revealed that Windows was successfully returning the list of shares but then the Mac failed to process them in a timely manner. So it seems like it's a Mac bug. It's very strange that manipulating dialect support on Windows would have any influence over this problem. But, bugs can't be reasoned with, they often behave irrationally.
Yes...... it seems to be a bug in MacOS in Big Sur......but specifically when "talking" to Windows. Again, when I use SMB to reach a QNAP NAS, there is no problem. I am presented with the list of all shares and can choose any or all and connect. SMB just times out when connecting to Windows shares unless I request a single named share at the command.
I have not had time to try the Windows Feature "on/off" thing yet. I will get to that, maybe, tonight.
Any Response from the Apple Engineers? This is a major Bug, I still can't believe Apple has no fix for this.
I just tried the Terminal code offered on this Reddit link and it finally allowed my M1 MacBook running 11.1 to access a Windows Server 2019 physical server. Before I could not get the login prompt while setting up this new laptop.
[ Type sudo /usr/libexec/configureLocalKDC and press Return ]
[ Type sudo /usr/libexec/configureLocalKDC and press Return ]
This could help if there was an authentication issue related to Kerberos, which I believe would only come up if the Windows machine ran the Windows Server operating system.
The two logs I reviewed showed no problem with authentication. Only one of the two logs used Kerberos at all.
Is it possible to share via NFS in Windows? Or is it client only?
Could one use the Linux subsystem to use BSD (or Linux) and run the server software from there?
My Mac mini is connecting to a couple of BSD boxes via SMB. I don't run Windows so I can't check this out myself.
On BSD you can set up shares using AFP (netatalk3), NFS and SMB (samba413) and the Mac can use either. (I use all three for various purposes.)
Could one use the Linux subsystem to use BSD (or Linux) and run the server software from there?
My Mac mini is connecting to a couple of BSD boxes via SMB. I don't run Windows so I can't check this out myself.
On BSD you can set up shares using AFP (netatalk3), NFS and SMB (samba413) and the Mac can use either. (I use all three for various purposes.)