Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

BIG SUR problems with SMB

lwilliams

lwilliams

macrumors 6502
Original poster
Nov 27, 2012
470
246
Athens, GA
After upgrading to Big Sur, SMB is not working as before.

I have a Windows machine with about 20 shared folders. In the past, I simply used Control-K, then SMB://192.168.50.228 (windows IP)

AFter that it would reach that machine. I would be presented with all of the shared folders available. I would highlight any or all of them and hit Connect. Then they would all appear for use.

Now, if I try this, it eventually times out. I must connect to each folder individually. Example: SMB://192.168.50.228/Work Documents

Then it will connect to that folder.

I want it to work the way it was before. What is going on here?
 
Hmm. It seems to work for me. I used control-K, then smb://10.0.0.28. I was presented with a list of 9 shares from my Windows machine.
 
Are you using the same windows credentials that you used in the past when it was working? Could it be that permission to list shares requires different permissions that the permission to use a particular share?
 
I have the same issue with one of my Macs after upgrading to Big Sur, on one mac SMB is working well but on the other it doesn't connect at all although the server I am trying to connect to is pingable on the same Mac. Any advice?
 
@Fcis, can you confirm you are having the same problem as the OP? On the failing Mac, are you still able to mount the individual shares by name? Confirm that in the command-K dialog, "smb://badmac" fails, but "smb://badmac/sharename" works.
 
Regarding the ability to list shares, I found this reference on Microsoft's website.

When I query the shares and monitor network traffic, it's pretty easy to see how it's being used. (It appears to be superficially the same on Catalina and Big Sur.) The most significant thing is that it is opening the "srvsvc" named pipe and using it to send the "NetShareEnumAll" request (which lists the shares).

The IPC$ share can always be accessed anonymously, but the srvsvc not so much (according to that link). I see that when I list shares, I am NOT connecting anonymously; I see my user id being presented for authentication.

I wonder if your keychain has stored credentials for the individual shares, but you're trying to list shares anonymously. I'm really just grasping at straws.

Perhaps the fact that my user id is the same on my mac as on my Windows machine is helping me out some.
 
I have the same issue with 2 MacBook Pro. Can't open shared folders (smb) on a virtual windows server 2016.
 
The problem persists.

I have never before had to access shares individually. However, I can SMB to them one at a time. Same Windows username and password for all.

I have rolled back Windows updates that were done over the last two weeks - just in case. No help.


I need this to work.
 
I have the same problem with my samba server. Share listing was working with
Catalina and does not work with Big Sur. Direct mount of shares is still working.
 
Share listing is using the IPC$ share. It's trivial to watch the smb negotiation in Wireshark which would give a hint what is wrong. Do you have experience with that? Have you checked the Mac console or the Windows event viewer?

When you are attempting to list the shares are you including the user id using the syntax smb://user@server? Try that if not.

I'm hesitant to recommend this, but if I were having the issue, I would delete my keychain entries for that samba server and force re-authentication. I'm sure I don't need to say this, but if you do this, make sure you record the passwords in case you've been depending on Keychain to remember them.

I have now tested with a Windows machine and a Synology NAS; I can't reproduce the problem. My Windows machine is running Windows 10 professional. Are you also running professional?

Rambling thoughts...trying to help...probably not.
 
lwilliams said:
Yes, Win 10 Pro.

Tried including the user ID in the smb sytax. Result is the saame.
Click to expand...
Well then, try smb://user:password@server If that doesn't work, then I'm probably full of it being an authentication problem.

Let's assume I am full of it, then I might suggest using the console to monitor the NetAuthSysAgent process. It might give us a hint. I'll have to switch over to my Big Sur machine a bit later to make sure my instructions for how to do that aren't slightly off.
 
Thanks @svenmany for all the helping. Sadly there is no change it still hangs for ever and does not list any shares... probably we have to wait until Apple will fix this. On my server there are 71 shares... has anybody open a ticket by Apple support?
 
moetiker said:
Thanks @svenmany for all the helping. Sadly there is no change it still hangs for ever and does not list any shares... probably we have to wait until Apple will fix this. On my server there are 71 shares... has anybody open a ticket by Apple support?
Click to expand...

Happy to try to help. I only have general knowledge about things. It could be that someone with more detailed knowledge will chime in.
 
I found a man page that says NetAuthSysAgent delegates to NetAuthAgent. I started thinking - maybe the popup window which allows you to select a share is appearing on a different monitor or otherwise off the screen. Obviously working through the logs will show some things; I see the activity of NetAuthSysAgent followed by NetAuthAgent opening a windows. But, maybe a simpler test first makes sense.

Try smbutil view //user:password@server to see if that lists the available shares.
 
svenmany said:
I found a man page that says NetAuthSysAgent delegates to NetAuthAgent. I started thinking - maybe the popup window which allows you to select a share is appearing on a different monitor or otherwise off the screen. Obviously working through the logs will show some things; I see the activity of NetAuthSysAgent followed by NetAuthAgent opening a windows. But, maybe a simpler test first makes sense.

Try smbutil view //user:password@server to see if that lists the available shares.
Click to expand...
I'm so sorry. I forgot to mention that you have to type that command in Terminal.
 
I just tried that in Terminal. All I got was:

Share Type Comments
------------------------------------------------------


I finally had to kill Terminal. It said the process was still running and asked if I was sure. Nothing further returned.
 
Well, OK then... If I'm to continue investigating, I would need to see some logging output. Here are the caveats:

- Someone having the problem is going to have to make a bit more effort following some instructions. And, this won't be the last time following instructions unless we're very lucky. Please don't hesitate to say "I've had enough; it's just not that important".

- The logs are supposed to free of sensitive information, but I can't promise something won't be exposed; see this information about <private>. It would be best to PM me the output from the logs. I absolutely see my user name in the logs and I've never attempted to override the private setting. I don't see anything else personal, but the output I'm going to ask for is enormous.

- I'm not a Mac developer so the odds of me seeing something useful and making some progress is around 25% (but I'm an optimist). I'll certainly see a difference between your logging output and my logging output and I suspect very strongly that we'll have some information to facilitate more successful web searches for other people having similar issues.

Here are the instructions:

- Run

Code: 
log stream --predicate='(process contains "NetAuth") || (eventMessage contains "NetAuth")' --debug > ~/Desktop/netAuth.log

in Terminal. It will not immediately complete. Just let it run.

- Attempt the command-K "Connect to Server" which attempts to list the available shares. Wait until it times out.

- Go back to Terminal and type control-C.

At this point there will be a file on your desktop called "netAuth.log". That's one file I would need to get.

I also will need to see how things look when you successfully mount a share. So, repeat the entire process replacing "netAuth.log" with "netAuthSuccess.log" and include a particular share name when doing the command-K "Connect to Server".

Well, Mr. Phelps?
 
Hi all,
Created an account to help, as I had the same problem.

My situation - after upgrading to Big Sur, I was unable to get to SMB shares on the Mac from Windows Vm's and physical machines. For some reason, when looking at "More info" on the shared folder/drives, permissions on an "unknown" user were in limbo. Could be an old account I had, but I blew it away, and applied to all enclosed items. After that I went into my user account (my main profile on the Mac), disabled SMB sharing, waited for it to take, and then enabled it again. Suddenly all the shares work. I mentioned the "unknown" account only because I am not sure if it had to do with anything that was "weirding out" SMB sharing.

I hope this helps.
 
slowmacpro said:
Hi all,
Created an account to help, as I had the same problem.

My situation - after upgrading to Big Sur, I was unable to get to SMB shares on the Mac from Windows Vm's and physical machines. For some reason, when looking at "More info" on the shared folder/drives, permissions on an "unknown" user were in limbo. Could be an old account I had, but I blew it away, and applied to all enclosed items. After that I went into my user account (my main profile on the Mac), disabled SMB sharing, waited for it to take, and then enabled it again. Suddenly all the shares work. I mentioned the "unknown" account only because I am not sure if it had to do with anything that was "weirding out" SMB sharing.

I hope this helps.
Click to expand...

I think you're saying that shares that are on your Mac were not visible to some Windows machines. Is that right? This thread is about problems in the other direction - shares on the Windows machine not browsable by the Mac.
 
I had two people send me logs, but I've yet to get any takers on providing a Wireshark trace. Here's what I see in Wireshark when I successfully list shares

Screen Shot 2020-12-10 at 16.32.27.png


Each entry can be expanded to reveal a ton of info. There might be private information there that I shouldn't see.

One person's logs clearly showed "Looking up shares with RPC failed api_status = 1728". (That's the DCE RPC over the srvsvc named pipe using the IPC$ share.) Microsoft identifies 1728 as a "RPC_S_PROTOCOL_ERROR". I suspect the entry in a Wireshark trace where Windows returns the 1728 has more information than the console log is showing.

The other person's logs seemed to just get no response from the NetShareEnumAll (well, at least the Mac logs show nothing). It would be good to know if Windows did or did not respond in a network trace. If it really didn't respond, then a trace on Windows and inspection of the Event Viewer there are probably good next steps.

I think that just by looking at the console logs, I've hit a dead end. Sorry. I hope someone with more specific knowledge chimes in with a solution.
 
Stupid question, but are you connecting to SMB 3.0 shares? Or earlier? I know that SMB 1 is definitely deprecated and shouldn't be used unless absolutely necessary. SMB 2 ought to still work, but Apple may have deprecated support for it early.
 
Yebubbleman said:
Stupid question, but are you connecting to SMB 3.0 shares? Or earlier? I know that SMB 1 is definitely deprecated and shouldn't be used unless absolutely necessary. SMB 2 ought to still work, but Apple may have deprecated support for it early.
Click to expand...

Thanks for that. It could be something related to versions. One person is having an issue connecting to Windows Server 2012 but not 2008. 2012 was the first version of Windows which used SMB 3.0.2 and could prevent SMB 1.0. I found that on Wikipedia.

SMB 3.0.2 (known as 3.02 at the time) was introduced with Windows 8.1 and Windows Server 2012 R2;[36][37] in those and later releases, the earlier SMB version 1 can be optionally disabled to increase security.[38][39]
Click to expand...

You can see the SMB dialect negotiation in the Wireshark trace but I'm not quite sure how to find that in the Mac's console log. Perhaps someone having the problem will run Wireshark and report that.

Big Sur offered my Windows machine 2.0.2, 2.1, 3.0, and 3.0.2. Here's what that looks like in Wireshark:

Screen Shot 2020-12-12 at 16.36.52 .png


Windows chose SMB 3.0.2. And, here's what that looks like:


Screen Shot 2020-12-12 at 16.20.21 .png
 
  • Like
Reactions: moetiker
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back