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

ThijsX
Valued Contributor
Valued Contributor

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

1 ACCEPTED SOLUTION

ThijsX
Valued Contributor
Valued Contributor

Got a workaround that worked in our organization.

This changes for macOS the SMB behavior to v2
Changed beneath setting in the /etc/nsmb.con file.

#!/bin/sh echo "[default]" >> /etc/nsmb.conf echo "protocol_vers_map=2" >> /etc/nsmb.conf exit 0

For now, no more finder crashes.

Cheers,
Thijs - bol.com

View solution in original post

61 REPLIES 61

cbrewer
Valued Contributor II

@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
Valued Contributor
Valued Contributor

@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
New Contributor

@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
Valued Contributor
Valued Contributor

@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
New Contributor

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
New Contributor

@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
New Contributor

@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
New Contributor

@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
New Contributor II

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
New Contributor

@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
Valued Contributor
Valued Contributor

@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
New Contributor

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
Release Candidate Programs Tester

@rluksiarto did you try with 10.13.3?

ch3valier
New Contributor

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
New Contributor

10.13.3 solved this problem. Thank you txhaflaire.

mvincenti
New Contributor

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
New Contributor

unfortunately on one client 10.13.3 seemed to make things worse, if anything. Now she'll get errors like this 3f864a6c8c2d4214a5b33a503f0913e5 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
Valued Contributor
Valued Contributor

@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
New Contributor

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
Valued Contributor
Valued Contributor

@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
New Contributor

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
New Contributor

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

I will try and attach it to this post.

Thanks!

Robind899cdcae1e0480d9e1517a08ea278c3