MS Office fails to save to shared folder using ExFat external drive (APFS works)

[antize1]

Hi, I have the following environment:

- MacBook Pro 16 inch 2019
- macOS Catalina 10.15.7
- VMware Fusion 12.1.2
- Windows Server 2019 1809 (17763.2565) VM
- VMware tools VMware-tools-11.3.5-18557794-x86_64.exe
- Microsoft World/PowerPoint/Excel for Microsoft 365 MSO (Version 2201 Build 16.0.14827.20198) 64-bit

I've tried multiple external drives formatted with ExFat and configured in VMware Fusion with:

- Enable Shared Folders: Enabled
- Permissions: Read & Write

In the VM it is mapped as Z:\ and I can read and write to it with most things however MS Office fails to save files to it with various errors:

- Word: There has been a network or file permission error. The network connection may be lost.
- Excel: Document not saved
- PowerPoint: An error occurred while PowerPoint was saving the file

I've seen this type of issue reported online in multiple places on both Microsoft and VMware forums. The main resolution most have reached in those threads involves updating VMware tools on the VM. I've removed and installed various versions of VMware tools 10.x and 11.x but so far I've found no version of VMware tools that has resolved the issue.

I've tried to enable VMware tools debug logging in tools.conf but I don't see anything that seems relevant in the debug logs.

So far the only thing that seems to work is formatting the external drive with APFS (I've only tried ExFat and APFS). I prefer to have the external drive formatted with a file system that works on multiple OS' and supports large files so using APFS isn't really a good solution.

[Technogeezer]

Immediate guess is the Office apps are trying to issue an API call to the shared folder subsystem, and that operation isn't supported on ExFAT. For example, I've just tried to change the ownership of a file through the shell on a ExFAT file system. macOS returns a "operation not permitted" even though I have permissions (or so an ls -al says). To me that says that ExFAT isn't POSIX compatible and it may very well be that the VMware shared folder implementation depends on a POSIX-compatible file system.

Why not mount that external USB drive directly to the Windows VM and bypass the shared folder? You don't have access to it on macOS while you are using in in Windows, but Office apps in the VM will work with it. 

I'd be cautious about ExFAT on a drive of any considerable size and if you care about the data. ExFAT only has 1 file allocation table and is not journaled. This makes it more susceptible to damage and may not be able to be recovered should something go wonky.

[antize1]

Hi, thanks for replying! Not being able to set permissions on ExFAT appears nominal since it doesn't support DACLs (https://superuser.com/questions/468291/chmoding-file-on-exfat). The main reason to attach to the MacBook and share to the Windows VM is speed. I use it to share/transfer files back and forth with the host and since it's a SanDisk USB-C external SSD with up to 1000MB/s throughput, using shared folders provides the fastest performance since it doesn't actually hit the LAN.

Since some of the other threads I have encountered reference a specific fix for MS Office writing to shared folders with the same error (https://docs.vmware.com/en/VMware-Tools/10.2/rn/vmware-tools-1021-release-notes.html) so I figured it might still be an issue, perhaps only specifically with ExFAT. I've run a few more tests to try to draw some conclusions -

• Fusion Windows 2019 VM w/ Office save -> local VMDK formatted as ExFAT: SUCCESS
• Fusion Windows 2019 VM w/ Office save -> SanDisk USB-C SSD shared from fusion host with macOS sharing (SMB): FAIL
• Fusion Windows 2019 VM w/ Office save -> esxi ubuntu VM with Samba sharing ExFAT volume: SUCCESS

So based on the above it appears there may not be an issue with ExFAT in particular but perhaps something with being shared from macOS, either via Fusion shared folders or the built-in SMB sharing... Not sure, need to investigate further...

[Technogeezer]

My guess / bet is that none of those reports involved a shared folder on ExFAT. As you say, things work OK if the shared folder is on APFS and I bet on HFS+ as well.

Sounds like an ioctl/API sequence that Office on Windows is issuing isn’t liked by Apple’s ExFAT file system. Given the messages in Word, I’m spit balling that it might be something with trying to manipulate permissions. I noticed that while a macOS chown CLI command failed on ExFAT with an error, chmod did not. It was silently ignored. Wondering if something like this is at the bottom of the issues, where other implementations simply ignore permissions changes but macOS does not. 

[ColoradoMarmot]

I recall MS Office having issues with some shared drives in Windows as well.  There were two work arounds - save locally, then move in explorer, or change the share type.

exFAT really has very limited capabilities, and I strongly suspect that while windows itself may have workarounds, those workaround probably are different than MacOS does, so it's incompatible.