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

Tried to reproduce this under 10.13.2/Build 17C88 (we use a lot of SMB here) but I was unable to. Copying and moving a file appeared to work as expected...

Try installing the 10.13.2 combo update, see if that helps.

Combo

@SGill Thanks for testing it out for me :)
@mvu will try, thanks!

Adjust SMB browsing behavior in macOS High Sierra 10.13

@donmontalvo Thank you for posting the helpful article, tested this out on some devices but no succes till now.
Will dive deeper!

Thanks
Cheers,
Thijs bol.com

Same issue here, running 10.13.2 with smb share. Create new folder works... the finder crashes when: copy, rename a folder

Same issue here, running 10.13.2 with smb share. Create new folder works... the finder crashes when: copy, rename a folder

We have this issue. Pretty sure related to APFS. None of the suggestions worked in our environment. We have Windows Servers using SMB3 which seems to be the issue. On Servers using SMB2, we didn't see this problem. Only options was to connect with SMB1/cifs

cifs://servername rather then SMB. I would do a check in terminal with the drives mounted to see how your connected and then see if there is an option on the server to switch it off. Though from what I understand SMB2 and SMB3 piggy back off one another so you can't just turn one off or on.

@goose11 @Jae Thank you for helping me out, good to hear (lucky) i am not the only one in this. Fact is, we have over 1500+ Windows machines that is functioning properly on SMBv3 so we cant turn it off.

I will check if we can find a workaround, hopefully Apple is quickly fixing this issue!

Cheers,
Thijs bol.com

Hi,

We are not alone, seems to be..

https://discussions.apple.com/thread/8191222

Cheers,
Thijs - bol.com

I've replicated and tested this all afternoon, and it looks like the only workaround I can find is switching from smb:// to cifs:// - none of the other tweaks to SMB sharing I've found online made any difference.

Watching the console for log messages while invoking the bug by changing the name of a file on the server, I see the following messages on SMB connection:

default 15:25:19.151066 -0500 Finder Write options: 2 -- URL: <private> -- purposeID: com.apple.desktopservices.copyengine -- claimID: 414B91F0-D637-42BA-AAAA-D0643F98A239 default 15:25:19.151538 -0500 filecoordinationd Received claim 414B91F0-D637-42BA-AAAA-D0643F98A239 default 15:25:19.151628 -0500 filecoordinationd Claim 414B91F0-D637-42BA-AAAA-D0643F98A239 granted in server default 15:25:19.151682 -0500 filecoordinationd Claim 414B91F0-D637-42BA-AAAA-D0643F98A239 invoked in server default 15:25:19.151857 -0500 Finder Claim 414B91F0-D637-42BA-AAAA-D0643F98A239 granted in client default 15:25:19.151882 -0500 Finder Claim 414B91F0-D637-42BA-AAAA-D0643F98A239 invoked in client

And this while connected as CIFS:

default 15:36:16.636776 -0500 Finder Write options: 2 -- URL: <private> -- purposeID: com.apple.desktopservices.copyengine -- claimID: DA242FF2-84E3-4A4C-AC08-DFA75F9749B5 default 15:36:16.637052 -0500 filecoordinationd Received claim DA242FF2-84E3-4A4C-AC08-DFA75F9749B5 default 15:36:16.637140 -0500 filecoordinationd Claim DA242FF2-84E3-4A4C-AC08-DFA75F9749B5 granted in server default 15:36:16.637185 -0500 filecoordinationd Claim DA242FF2-84E3-4A4C-AC08-DFA75F9749B5 invoked in server default 15:36:16.637346 -0500 Finder Claim DA242FF2-84E3-4A4C-AC08-DFA75F9749B5 granted in client default 15:36:16.637371 -0500 Finder Claim DA242FF2-84E3-4A4C-AC08-DFA75F9749B5 invoked in client default 15:36:16.663322 -0500 filecoordinationd Claim DA242FF2-84E3-4A4C-AC08-DFA75F9749B5 was revoked

Note, the last line, where the claim is revoked. That seems to be missing in a SMB connection, and I suspect is the step that's causing the Finder to lock up, waiting.

Maybe someone who knows what filecoordinationd is actually doing can clear things up, but I suspect it's to do with locking the file to changes while the Finder renames it, then releasing the lock. On an SMB2/3 connection the lock never releases, while on SMB1/CIFS, it does.

Anyhoo, I'm trying to install the 10.13.2 combo update on an effected machine, and I'll follow up if it makes any difference.

Seeing this also.

When Finder crashes, are you able to relaunch? I'm having to force power off .

Has anyone raised a ticket with Apple that can be duped?

@option8 T.hanks for the great logging and troubleshooting, will also investigate this.

@andysemak We also have to force power off.
Did not raise a ticket with Apple, is there a process for that?

I am seeing identical issues to those expressed and have opened a ticket with apple. I encourage everyone to do so; generally speaking the more tickets the higher priority a patch becomes.

To wit:
Temporary fix is to use CIFS until this is patched.
Only occurs with workstations running 10.13.2 (with 10.13.1 this is not an issue)
I even formatted and did a clean install; issues remains
Appears to be only occurring when connecting to SMB3 shares
When this happens the Mac must be powered down; finder cannot be restarted or killed even via terminal with sudo privilages
I attempted some steps in this KB https://support.apple.com/en-us/HT208209 to see if it helped; it did not resolve this issue.

We had the same thing happen here as well. I was able to fix it by creating an nsmb.conf file to disable packet signing. Once I created the file and rebooted it was no longer an issue. Hope this helps until there is a fix.
https://support.apple.com/en-ca/HT205926

I'm having precisely the same issue after upgrading macOS Server to 10.13.x

client machine finder crash on file move; must hard reboot.

thankful to have found this thread. reverting to AFP connections resolves problem which is less than ideal.

I can reproduce the Finder crash.

Server: macOS High Sierra 10.13.2 with Fusion Drive and HFS+ Filesystem
Standard macOS SMB file sharing

Client System: macOS High Sierra 10.13.2
User has full file permissions via an ACL permissions group except „change permissions“ and „change owner“.

It happens when I move a file (drag'n drop) from one folder (same level) to another on the network drive. Finder can only be forced to quit and doesn't restart afterwards. System can only be shut down via holding the power button.

Reached out to Apple Enterprise support, they created a ticket and will come back to me soon.
If i have any intel on this, i keep ya posted.

Cheers,
Thijs - bol.com

Glad to know I'm not the only one having there issue.

Created a big log file with the Enterprise Data Capture tool from Apple Enterprise support, just submitted it an they created an escalation.

Cheers,
Thijs - bol.com

All of this is very familiar: moving a file on a shared volume leads to Bad Things which only a hard reboot fixes.

Thanks everyone for the work here.

Having what sounds like the same problem in at least one of our branches. Nobody here has reported it, but then, not everyone is on 10.13.x. FWIW, 10.13.1 will lock up the Finder the same way if we push it hard enough (typically, this doesn't happen on the first(or even the second or third necessarily) operation (drag and drops), but it will happen. Not sure about 10.12.x as we haven't pushed it hard enough to see if we can lock up the Finder.

Hope to hear something good from Apple Enterprise via Thijs. FWIW, we've disabled SMBv1 on all our Windows servers due to vulnerabilities in the protocol.

Wondering if this just started back in December? When I asked a user with the issue, they said it happened some time after an update to MS OneDrive for Business. Not sure if there is a real connection there or not.

Experiencing the same issue here with 10.3.2. Coworkers have not had any problems with 10.3.1. Have worked closely with my IT department and no solutions as of yet.

Any time I'm moving a file, finder locks up (I have found that CTRL+C and CTRL+V'ing a file is a work around for the time being). Any time I'm renaming a file, finder locks up. And on and on. A hard reboot is the only solution I have to get things back up and running.

Looking forward to getting things back to norm.

@murphycoverdot It started happening since 10.13.2, We currently do not have MS OneDrive in our organization.