I have some folders on the vm Windows 10 guest that are shared.
On my previous version of VMware Fusion I could just use MacOS -> Finder -> Go -> Connect To Server -> and use "smb;//[WindowsMachineName]/[sharedFolderName] -> Connect
And then I would be able to see that Windows shared folder on my MacOS host, as /Volumes/[sharedFolderName]
Since upgrading to macOS Catalina, and to VMware Fusion 11.5, I haven't been able to connect to the shared folders from MacOS (even though I can see they're setup ok within Windows)
I have tried reinstalling VMware Tools, rebooting the host (MacOS), rebooting the guest (Win10), disabling firewalls, and granting "Full Disk Access" to VMware Fusion (MacOS -> System Preferences -> Security & Privacy -> 'Accessibility' / 'Full Disk Access' / 'Files & Folders' / 'Automation' all granted to VMware Fusion
I really need to get this working again, as I relied on this setup for my day-to-day workflow checking in source code. Any help appreciated.
Can you try to connect with VM ip? It works for me without giving Full Disk Access and Files and Folders permission to Fusion
Can you try to connect with VM ip? It works for me without giving Full Disk Access and Files and Folders permission to Fusion
Thank you. Using the VM's IP enabled me to connect to the Win10-guest shared folder from MacOS-host.
I've marked this as the correct answer, because it solved the issue, although I hope very much that VMWare reads this, and includes a fix in a VMWare Fusion 11.5.x update so the PC name can be used too, as it was before (especially if the VM's IP changes from time to time after reboots, etc.).
Hi,
PMJI, user bfan who gave you this workaround works for vmware you can see that as the user has the little "vm" icon by their name.
FWIW, accessing a smb share by IP instead of by DNS name means that NTLM is used. If accessing via DNS then kerberos gets used instead.
Yet another reason for wanting to access the share by DNS name.
If name resolution works, then another thing to check is if the clock in the guest is the same as your host (too large of a clock skew and kerberos won't like it)
--
Wil