Folder copy on Windows 7 vm fails for "not enough space", but there is.

[laxdude75]

I'm on Fusion 5.0.3, running on a Mac Retina with a Windows 7 vm.  I have two external drives connected (1 Thunderport, 1 USB3.0) and for each of them, I created Shared Folders on the drive root folder.  For simplicity, I'll say the Drives/Folders are named "Thunderport" and "USB3".

I had a folder of iso files about 10G in size that I wanted to copy from my C: drive on Windows7 to the Thunderport drive.  However, upon starting the copy, I got an error message that there wasn't enough room--I'd need free 5.6G of space on "Shared Folders (\\vmware-host)".  Inspecting the available room on the 3TB Thunderport drive, I found there was ample room with over 700GB of free space.  It didn't make sense why I was getting a "not enough space" error.  I took a look at the USB3 drive-- ah hah!  It was down to only 4.5GB of free space.  Thing is, this isn't the drive I'm copying to--so why is it even being considered? 

Any ideas?

Thanks.. Michael

[changhai]

laxdude75,

I am very curious  at how did you use your USB 3.0 device. as of this moment, on window 7 GOS, by default, USB 3.0 is not supported, did you install USB 3.0 driver by yourself within window 7 GOS? alternatively, did you configure USB Compatibility as "USB 2.0" in order to use USB 3.0 device?

Unfortunately, I did not reproduce this issue locally with the following steps.

1. Insert one USB 3.0 disk and present it to Window 7 GOS.

2. Configure setttings==>sharing  to enable one external device with Thunderport interface.

3. Power on window 7 GOS and copy one  4G big ISO file to "Thunderport"  Drivers/Folders without any issue while USB 3.0 has 200M diskspace only.

Based on current information, you supplied, root cause can not be determined. please help answer the  following questions and implement the following Action plan.

Questions

========

1.  only see this issue on one Window 7 GOS or all of GOS.

2.  If you remove/unpresent the USB 3.0 Device, coping file sucess?

3.  If you remove/unpresent the Thunderport disk, could you copy file to USB 3.0 disk?

Action plan

=========

1. describe the detailed steps, preferred with one video/screenshot  

2. upload support information through  Help==>Collect Support Information

Best Regards,

changhai

[ColoradoMarmot]

What format are your drives?  FAT32, exFAT, Mac, NTFS?

If the latter, it's likely an issue with the third-party NTFS drivers.

You can try deleting and re-creating the shares, and it might also be worth emptying the trash and verifying the thunderbolt drive.

[laxdude75]

Changhai,

I have both drives (each is a Seagate GoFlex NTFS formatted--using Paragon NTFS for Mac OSX driver) connected to the native Mac OS.  Yes, I'm aware USB 3.0 isn't supported by Windows 7 GOSes.  The actual drive names (to correlate to screenshots) are Developer1 (connected via Thunderport) and B&T 2 (connected via USB 3.0)  For each drive, I created a shared folder on their TLD.  Thus, the label of the drive as it appears under the Mac OS "Devices" (i.e. "Developer1") appears on Windows as a folder under the shared folders drive

    Shared Folders (\\vmware-host) (Z:)

        > Developer1

Developer1 has approx 565GB free space, while B&T 2 has approx 6.5GB of free space.

When I attempt to copy a folder from the Windows GOS thats approx 12.5GB to rge Developer1 drive (which has ample space), I get the results seen on the attached screenshot.  If I eject the B&T 2 drive, the copy is performed without any problems.

I switched the drives to use the other's connection (put B&T 2 on Thunderport and Developer1 on USB 3.0)--it had no impact.  The copy failed when both drives were mounted, but had no problem is the nearly full drive was ejected.

I tried the same test on Windows 8--exactly the same thing occured.

I created a support file--does this require I open a support request?  It's the first issue I've come across I couldn't find an answer within the Community boards.

Thanks for your help,

Michael

[laxdude75]

As I mentioned in my reply to Changhai, the drives are formatted NTFS and I use the Paragon NTFS driver to allow write access.  I did try what you suggested--deleting the shares, turned Sharing OFF/ON etc.  It had no impact.

Thanks for trying to help me out.

[ColoradoMarmot]

It's the NTFS drivers, almost guarenteed.  Some here have had good luck, but others (myself included) have had nothing but problems.

Since Thunderbolt isn't supported on Windows machines anyway, why not just reformat the drive as a Native Mac partition?

[WoodyZ]

dlhotka wrote:  Since Thunderbolt isn't supported on Windows machines anyway

Really?  How about the Acer Aspire S5 Ultrabook, it has Windows 7 and Thunderbolt.

[steve_goddard]

This a general issue that we see with our VMware shared folders and is a consequence of exporting the shares under "\\vmware-host\Shared Folders".

Windows explorer will often ask for the for the volume size attributes of this folder, which is virtual and can contain shares of multiple drives, as in this case.

I suspect your second share has less than 5.6GB free which is the issue here.

So we have a choice do we return the size of the biggest or smallest volume of the host drives the shares map to.the default setting is to return the size of the smallest drive that is mounted under the shared folders. Hence why Explorer will say out of space when there is for that particular volume.

There are two workarounds here one temporary and one more permanent.

The temporary one is to go into the  virtual machine sharing settings and disable the other share and then do your copy and then go back and enable it once more.

The second one is to suspend the virtual machine and stop Fusion. Then edit the VMX file and add/change a setting for the volume size calculation on the

"\\vmware-host\Shared Folders" virtual folder from the smallest to the largest drive. When you restart Fusion and the virtual machine you should find the copy will succeed.

I don't have access to get you the setting right now but will do later today.

i will update here again later with that information.

Please let me know if this helps, at least either or both workarounds.

[steve_goddard]

Michael,

see my other response too here for some more details of the explanation of why your workaround succeeded.

I have suggested that using the UI to temporarily disable a share to the second drive that is the smaller volume and not the target of the copy is simple and reasonably quick to implement.

I am in the process of waiting to get access to my work desktop machine to complete the more permanent workaround to complete the answer.

(Editing the VMX file for the virtual machine in question.)

The reason the default setting for a query of the volume space on the "Shared Folders" virtual folder returns the minimum drive space is to prevent the following issue: if you did perform a large file copy to shares of drives that were really not big enough, but you did export a share on a drive that did contain large enough space, the copy would fail but only when you have run down the disk space competely on the smaller target drive. That could lead to other issues depending on what the drive contained e.g. the OS X operating system.

The volume space check would not catch it.

The downside is the issue you and others are having here.

Please watch here for my follow up update on the VMX setting to return the maximum drive space available on the shares for the volume query instead of the minimum and you won't run into this issue again.

[steve_goddard]

Stop the virtual machine either power down or suspend.

Quit Fusion.

Edit the VMX file for the Windows virtual machine you are using and either edit the following existing setting for the file or add a new line - but check first before adding:

tools.hgfs.volumeInfoType = "max"

Save and close the VMX file.

Restart Fusion and restart the Windows virtual machine.

This will cause volume space information to look for the largest disk space across all shares and return that for the volume query for "\\vmware-host\Shared Folders" virtual folder.

This will allow your failing file copy to not get the out of disk space, unless your file is truly larger than any drive on all the shares.

[laxdude75]

Steve,

Thanks so much for the info! 

My paranoia when it comes to hard drive backups has me to where I make sure anything important is backed up redundantly, so I'm usually well aware of the amount of space the particular drive I'm using has remaining.  While the workaround of ejecting the nearly full drive worked in this case and would in most cases, there are times I could be using it at the same time doing a copy.  I appreciate you sharing the logic behind why this problem exists--makes perfect sense.

Regards,

Michael

[steve_goddard]

Yes, it is one of the issues of having the extra virtual folder. Normally for UNC format that would be the real share but we added the virtual folder to allow all the shares to be under a single drive letter mapping.

One convenience but it does lead to issues like this and there are others too unfortunately. Some we can deal with others are harder as it depends on the application and how it handles the unexpected behavior.

Please continue to report any issues.

[barryschaeffer]

Steve,

Wanted to thank you for this posting back in 2007.  I just had the same problem, copying a large 100GB folder from a guest (Win Server 2012) to the shared folders.  Your suggestion to disable the 2nd and 3rd shares solved the problem.

Thanks,

Barry

[steve_goddard]

Hi Barry,

Thanks I am glad I could help.

The other workaround is to stop the VM, edit the VM's .vmx file and add the following setting:

tools.hgfs.volumeInfoType = "max"

Then start the VM again, and this time you will not need to disable the other shares which are on smaller sized volumes.

The default setting causes the shares to be aggregated to the smallest volume size that a share resides on when our file system is queried for size and free space.

The above setting overrides this to pick the largest volume size. The downside is that you can start a copy to a share on volume with a smaller amount of free space and it will only fail when it actually fails to write when the free space is exhausted.

If you know you are not going to run into that type of scenario yourself or you verify prior to starting the copy operation then you will be fine.

Note, the above can only be set to "min" or "max" and if not set at all, then "min" is the default.

Steve

[d3spinoz4]

Hi,

I have a question about an issue I'm experiencing with a windows 7 virtual machine that has shared folders mounted from a linux nfs export -- The NFS exports are also NIS maps to the clients hosting the VMs and one of the maps (15TB total, 8TB free) has 2 top level directories for example folder1 and folder2, the second map (4TB total, 3TB free) contains the home directory of the linux server.

If I add folder 1 and/or 2 off the first map everything works fine but when i add the home directory off the second map and I try to copy any file let's assume 72.1 MB in size to any of the shared folders whether it is folder1, folder2 or one of the home directories I get the following error:

"There is not enough disk space on shared folders (\\vmware-host). You need an additional 72.1 MB to copy files"

"Shared folders (\\vmware-host)

Space free: 0 bytes

Total size: 0 bytes"

Any help would be appreciated!

thanks

[steve_goddard]

So it seems that the second map when the query for the volume disk size and space is returning zero for free space and size.

Maybe the query is failing due to permissions or NFS is not returning the correct information.

Since the default for volume query for sizes and space that the server will use is to pick the minimum across all the shares, then it will return zero free space.

This will cause the file copy to fail thinking the target volume is full.

So as I stated in a previous post try setting the Shared Folders to use the maximum disk size and space

which is set by shutting down the VM or suspending it, edit the VM's VMX file. It is the only file in the VM
folder which has the ".vmx" extension.

In that file add the following line:

tools.hgfs.volumeInfoType = "max"

Save the file and restart the VM.

Try the copy again.

The real issue here is why does the volume space query get zero back when you said it is 4TB total, 3TB free.

I guess I will try with NFS exports mapped as Shared Folders.

Try the above workaround I think it should get you by this issue for now.

Thanks

Steve

[virtual_M]

This happened to me on VMWare Workstation on Windows 7 host,  Windows 10 guest (I also thing Windows 7 guest too).

I wanted to copy files from the guest OS to the host OS, a non read-only Shared folder on the host. I had enough free space on the C: (in case a Temp folder on C: would be used for the copy) drive of the guest OS (the source for the copy), and I had enough free space on the host OS, and write permissions were not a problem.

When I wanted to copy a folder with files, I got the error "that there is not enough space on shared folders".

To fix this, I used "Directory Opus" to copy the files and I turned Network discovery On , on the guest OS - i.e. from the OS that was hosted, and was the source of the copy/ transfer.

Disabling the other shared folders on VMWare and only leaving one Shared folder, worked for Windows Explorer, too.