Skip to main content

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

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.


@rluksiarto did you try with 10.13.3?


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

10.13.3 solved this problem. Thank you txhaflaire.


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.


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.


@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


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.


@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


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


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