OS X Finder error -36 while copying from SMB share via Thunderbolt Bridge and running VMware Fusion 8.1.1

[mammeta]

Hello, I'm trying Fusion and I got a nasty problem (maybe: bug?) in these scenarios:

Mac Mini late 2012 running 10.11.6 attached via thunderbolt bridge (0.5 meters cable) to a Macbook Pro early 2013 running 10.11.6

1) VMware Fusion Pro 8.1.1 running on Mac Mini, no virtual machine running:

• using a SMB share, copying from Mini to Macbook via Finder fails with error -36 (permission problems)
• copying from Macbook to Mini goes ok

2) VMware Fusion Pro 8.1.1 not running on Mac Mini:

• copying the same files as scenario 1 from Mini to Macbook via Finder goes ok
• copying from Macbook to Mini goes ok

Did someone had my same problem? I didn't find any workaround.

[nancyz]

Hi mammeta,

Are you copying the file to a specific folder on your Mac. I could copy file between two shared 'Desktop' successfully.

[Mikero]

Error -36 isn't a permissions issue, it's an I/O issue. I used to see this a lot in support with spinning hard disks that had bad sectors where important bits of the VM's disk reside.

Typically it implies there's corruption in the file somewhere, so if you check the logs you might see Input/Output errors

The scenario you describe doesn't make sense to me tho... If you're not running a file-copy via SMB to your VM, then I don't see how Fusion could be getting in the way, tho stranger things have happened.

Does it error with -36 as well if you connect to SMB directly inside your Windows VM?

Could you make the problem happen, and then generate a support bundle? (help > Collect support information)

We can try and see if there's a correlation.

[mammeta]

Sorry for the mistake in the error description, thanks for the reply.

I did more tests, here the evidences:

• it only happens copying with Finder (cp from Terminal is ok and also midnight commander)
• it only happens when copying files with certain dimensions, tried with 1K, 10K, 100K, 1M random files and went ok, 10M fails
• grabbed from syslog:

          17/08/16 09:44:02,000 kernel[0]: nbssn_recv: Breaking connection, sock_receivembuf blocked for 20

          17/08/16 09:44:02,000 kernel[0]: smb2_smb_parse_change_notify: smb_rq_reply failed 60

          17/08/16 09:44:02,000 kernel[0]: smb2_smb_parse_change_notify: smb_rq_reply failed 60

          17/08/16 09:44:02,000 kernel[0]: smb2_smb_read_write_async: smb_rq_reply failed 60

• did the dot_clean procedure, it fails though
• tried copying with Finder a file 100M large from a smb share within a Windows 7 virtual machine, it fails with the same error, with cp by terminal it goes OK

Based upon these evidences, it is a Finder problem: it seems that while copying Finder does something "around and other" than just copying the file, but it fails only when Fusion is running

I want to try with a clean system

[ColoradoMarmot]

It's also possible that Finder is doing more error detection/correction than terminal - have you tried with a different hard drive?

[mammeta]

yes, I tried from three different hd, same scenario: if Fusion is running, the copy fails; if Fusion is NOT running the copy completes.

At the moment I have these possible scenarios (using Thunderbolt Bridge and native SMB2 OSX implementation):

• Fusion not running, copy OK via Finder
• Fusion running, small file (<10MB) copy OK via Finder
• Fusion running, big file (>=10MB) copy -36 error via Finder, copy OK using cp via terminal, or midnight commander