macOS High Sierra 10.13.2 - Finder issues when copying files in mounted shares

[ThijsX]

Hi,

Currently we are experiencing below issue since 10.13.2, this issue is not active on 10.13.1 / 10.12.6.

The finder crashes when; Copying a single file from a lower folder niveau to a higher folder niveau on a mounted network file share.

The finder does not crash when; Copying a single file from a higher folder niveau to a lower folder niveau on a mounted network share.

Mounted share as SMB or CIFS.

Is anyone experiencing the same issue?

Cheers,
Thijs - bol.com

[cbrewer]

@mantos nsmb.conf doesn't exist until you create it with the script above.

10.13.3 Beta 4 is supposed to fix these SMB3 problems.

[ThijsX]

@Tekniqueman Hmm can you verify the nsmb.conf file is created in /etc/ with its variables in it? screenshot oi.

@mantos No Problems! just remind your self when upgrading to 10.13.3 the fix will applied by Apple and you can remove that specific file on all your clients.

Cheers,
Thijs - bol.com

[mantos]

@cbrewer & @txhaflaire Thank you, sorry for having to ask again: I pasted the code

!/bin/sh

echo "[default]" >> /etc/nsmb.conf
echo "protocol_vers_map=2" >> /etc/nsmb.conf

exit 0

in the terminal and this is what I get:

Last login: Mon Jan 15 15:47:46 on console
MacBook-Pro2:~ manu$ !/bin/sh
-bash: !/bin/sh: event not found
MacBook-Pro2:~ manu$ MacBook-Pro2:~ manu$ echo "[default]" >> /etc/nsmb.conf
-bash: /etc/nsmb.conf: Permission denied
MacBook-Pro2:~ manu$ echo "protocol_vers_map=2" >> /etc/nsmb.conf
-bash: /etc/nsmb.conf: Permission denied
MacBook-Pro2:~ manu$ MacBook-Pro2:~ manu$ exit 0

No file has been created. Seems like I have no permission even though I have admin rights.

[ThijsX]

@mantos No worries, we will help you out.
Currently you are trying to throw a complete shell script into the terminal.

If you want to do it directly via terminal do the following each line at a time.

sudo -s
echo "[default]" >> /etc/nsmb.conf
echo "protocol_vers_map=2" >> /etc/nsmb.conf
exit

If you want to create a script use a texteditor like TextMate / Textwranger and you can drag and drop it into the terminal.
First a sudo, than throw in in the terminal.

Cheers,
Thijs - bol.com

[anth0nys]

10.13.3 beta 4 seems to have resolved the issue for me, anyone else? I don't know if I am jumping the gun and just got lucky that Finder didn't freak out.

[mantos]

@txhaflaire you are fabulous, thank you! I did it and it created the nsmb.conf file which I then opened with text editor and pasted in it:

!/bin/sh

echo "[default]" >> /etc/nsmb.conf
echo "protocol_vers_map=2" >> /etc/nsmb.conf

exit 0

[mhastsum]

@jakobstockman - we had the same issue: the protocol_vers_map=2 workaround was effective for some users but not others. Got exactly the same authentication failure you did, once set. Having removed the affected macs from the domain and readded them (and reset the user's password) the authentication failure went away and he could successfully connect to the share using SMB2.1 (confirmed with smbutil).

[mhastsum]

@jakobstockman - We observed the same behaviour: forcing SMB2 on the client side sometimes works but sometimes produces the described authentication issue. (We're on Server 2012r2 for the domain controller and file servers.) We found you can fix the authentication issue by re-binding the affected machine to the domain (from Directory Utility, remember to reboot between unbinding and re-binding).

[ChrisRybin]

Has anyone tried deleting the nsmb.conf file in /etc/ ? I've done this and then created a new one with the instructions from this somewhat old Apple support doc where it says 'If your macOS computer doesn’t have an /etc/nsmb.conf file'.

https://support.apple.com/en-us/HT205926

So far this seems to fix issues in my environment, but still to soon to say for sure. Still testing, but thought I would put this up.

[wpeacock]

@txhaflaire

Just wanted to say thanks for being so dillegent about posting your findings and workarounds. Saved having to re-image some machines.

I hope that Apple puts out a fix soon that will address the problem, AND will let us know -- more worried about the second part than the first.

[ThijsX]

@all macOS High Sierra 10.13.3 just released, they mentioned the finder issue should be resolved.
If any outcomes, great to hear!

Cheers,
Thijs - bol.com

[rluksiarto]

Hi guys,

I've done all the steps above and now I'm having problem even just saving things on my desktop. Anyone can help?

Thanks.

[bentoms]

@rluksiarto did you try with 10.13.3?

[ch3valier]

10.13.3 According to the release notes from Apple:

Resolves an issue that could cause your Mac to stop responding when connected to an SMB server

[Antti_Heiskanen]

10.13.3 solved this problem. Thank you txhaflaire.

[mvincenti]

It seems that I'm experiencing the same problem but 10.13.3 did not fix the problem for me. However, I also have about 10 machines that are on Mavericks or prior! Only 2 clients are on 10.13.3 along with the server (also running the latest Server app). This problem definitely started when I upgraded the server to 10.13 in anticipation to accommodate the new machines that I'm installing tomorrow. I also forced everyone to use SMB instead of AFP because I thought AFP was going away. Tomorrow, I'll install the new machines and everyone will be on 10.13.3 and everyone will be using AFP again. After reading this thread, I feel confident that this will fix this issue. But on a side note... if Apple is going to be deprecating AFP, they really should have a smoother road map towards SMB.

[johnsonua]

unfortunately on one client 10.13.3 seemed to make things worse, if anything. Now she'll get errors like this attempting to connect to shares...sometimes. This is on a mac bound to AD, with the user logging onto the system with her AD credentials. Sometimes it's thrown while connecting to her network home, sometimes it it happens while connecting to our shared workgroups fileshare. Stangely we have another fileshare on the same server as the workgroups and she CAN connect to it. We're using DFS to connect, but the same error gets through trying to connect to the underlying server share.

Her permissions are correct, and because it's intermittent I'm fairly certain it's her machine.

I've tried removing nsmb.conf and resetting it to what worked in 10.13.2 but no dice. I get the same error on her machine as myself or a test user, and that same test user has no issues logging on to my test machine.

Looking through a packet capture of an attempted connection I keep seeing Kerberos errors like this (from wireshark):

1163 17.300179 10.128.206.125 10.128.211.158 KRB5 173 KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG

10.128.211.158 is the end user's machine, the source is one of our domain controllers.

Even tried removing it from our domain and setting her account as local...

looks for all the world like a bug, but I can't reproduce it; this is not a weirdly configured system, either, and it was just recently rebuilt from scratch.

[ThijsX]

@johnsonua Ouch! currently we are having like 80 devices already on 10.13.3 and havent heard this issue yet.. fingers crossed.
Keep us posted!

Cheers,
Thijs - bol.com

[johnsonua]

What worked, in this case, was replacing the existing /etc/nsmb.conf with:

[default]
signing_required=no

I'm still not sure why it fixed it, though, which bothers me.

[ThijsX]

@johnsonua keep in mind that

If you turn off packet signing, you lower the security of the SMB connection. Turn off packet signing only if both the client and server are on a secure network.

Cheers,
Thijs - bol.com

[traposama]

Hi!!!

I have a similar problem!!! When find a file into DFS (2012R2) search showme files with date from 1969 and dont opened.

Have a tips for that?

Thx

[rakino]

Quick question here in the ACL context: which app is the above screenshot from?

I will try and attach it to this post.

Thanks!

Robin