I have a probable explanation: Time Machine local snapshots on an APFS volume (High Sierra or later).
I can repeat similar "not enough space" errors from VMware Fusion if I attempt to clone an existing VM or create a VHD which is larger than the actual free space on the disk (as reported by df in Terminal, which is less than that reported by Finder). I don't have anything I could try to import but that is likely to be running into the same issue.
Explanation
(Note that the term "snapshot" here has nothing to do with the VMware feature of the same name.)
APFS snapshots are used by Time Machine to support several features of the backup mechanism:
- A new APFS snapshot is created on the source drive when a backup is started. That snapshot is used to copy files to the backup in a consistent state.
- After a backup is complete, the snapshot on the source drive is retained as a reference which gets used to work out differences for the next backup. If you have configured Time Machine to use multiple backup drives, a reference snapshot is retained for each backup drive.
- Local snapshots are created when a backup drive is not available at the regular backup time, to give the user a chance to recover recently deleted or changed files.
- Old snapshots (for local or external backups) are retained on the source drive as long as there is plenty of free disk space, to extend the utility of local snapshots and to allow restoring recent backups even if the backup drive is not connected, or to allow rolling the system back to a recent state (a new feature in Catalina).
APFS snapshots retain the state of the entire volume at a point in time. If you delete a file, the disk space occupied by that file is not freed if there is an existing snapshot in which that file existed. To get that free space back, all snapshots containing that file also need to be deleted.
macOS automatically deletes old snapshots as disk space starts to get low, with a priority system: reference snapshots for external backups are retained as long as possible, because if they get deleted, the next backup may require a deep scan of the entire volume, resulting in a much slower backup. Other old snapshots are deleted first in the hope that will free up enough space.
Because snapshots get deleted automatically, the free space reported by Finder includes the total size of the snapshots, which are actually used space according to the file system. You can see the actual free space (not including the snapshots) by using the "df -h /" command in Terminal (-h gives human readable output rather than block counts; note that it reports power-of-two mega/giga/terabytes whereas Finder uses power-of-ten; to convert the df numbers to Finder equivalents, add 4% for megabytes, 7% for gigabytes or 10% for terabytes).
System Information in Mojave and later reports free space in the same way as Finder. From articles I've seen online it appears that early versions of High Sierra treated snapshots as used space in System Information, but I don't have a High Sierra system handy on which to check if this still applies as late as macOS 10.13.6.
The underlying problem is that the system's automatic deletion of snapshots doesn't kick in until actual free space is getting down to something in the ballpark of 20 GB, so the system doesn't cope well with attempts to create massive files in the order of tens of gigabytes where there may be a similar amount of space tied up in local snapshots. It works well if creating a lot of smaller files, as the system can see the declining free space and start cleaning up the snapshots.
VMware Fusion is checking free space, getting the actual figure (like df, not like Finder) and is refusing to proceed. I haven't investigated whether macOS provides APIs to help applications manage this better.
Specific details in this case
In the case reported here, Fusion is reporting about 49 GB of free space, but Finder and System Information are claiming 161 GB free. Use this command in Terminal to find actual free space:
df -h /
I expect it will show the actual free space is about 49 GB (shown as about "46 Gi"). That means the system has about 112 GB of snapshots (161 minus 49).
The following command in Terminal lists the snapshots:
tmutil listlocalsnapshots /
The snapshots have names in the general form com.apple.TimeMachine.YYYY-MM-DD-HHMMSS. There is no detail about the size of each snapshot, nor which ones are the reference snapshots for external backups. You can find the reference snapshots by comparing with the last backup information in System Preferences > Time Machine, noting that System Preferences shows the end time of the backup, whereas the local snapshot timestamp is the start of the backup, so they don't match exactly.
The problem is likely to be that danielmgi has made a major change such as deleting files in the order of 100 GB or more, but there is still an older snapshot in which those files exist. The space won't actually be freed until the correct older snapshots are deleted.
Some ways in which that can be achieved:
1. If you haven't done a Time Machine backup since the major change, do one now. This shifts the reference snapshot to the new one, and will allow the system to reduce the importance of an older snapshot so it can be deleted more easily. If you have multiple TM backup drives you may need to do backups to all of them to reduce the importance of all the oldest snapshots.
2. You can use the "tmutil thinlocalsnapshots" command to ask TM to delete old snapshots immediately, rather than having to force low free space to trigger the same mechanism. It has parameters for the amount of space to purge and an urgency level. See "man tmutil" for details. Urgency is not well documented: 1 appears to delete only unimportant snapshots, 4 stops a backup in progress and can delete reference snapshots.
This example would ask to purge 40 GB of unimportant snapshots (which would get you from 49 GB to at least 89 GB free, as long as that much space is retained in unimportant snapshots).
tmutil thinlocalsnapshots / 40000000000 1
It lists which snapshots were deleted. Use "df -h /" to check the end result, and if that now shows at least 77 Gi free (preferably a bit more) you should be able to proceed with the Fusion VM import.
