locked
WHS cannot copy large files (0x8007046A error) RRS feed

  • Question

  • I'm trying to copy a big file (320GB) to a non-duplicated share on my new Acer H340, which has the stock 1TB and an additional 2TB drive installed.  Currently there is 2.2TB free in the storage pool.

    The copy proceeds to about the 150GB point and then fails with a 0x8007046A error, "Not enough server storage is available to process this command".

    I've done some research on the issue, and there is talk that the WHS 'landing zone' isn't big enough to accept the transfer.

    ref: http://social.microsoft.com/Forums/en-US/whssoftware/thread/600a16a9-074e-441a-84ea-a60599e08c84

    But from what I understand, this landing zone approach was removed in PP1 (or was it PP2?).

    Other information (mainly MSKB articles like this http://support.microsoft.com/default.aspx?scid=kb;en-us;177078 ) go into how to tune esoteric server networking parameters but seem focused on older software platforms.

    So, how should I go about resolving this issue?  I'd rather not hack on my new system, guessing at correct parameters as is suggested in the KB.  Or if this is instead a landing zone issue, is there a resolution?  If so, what is it?

    Would it be possible to 'sneaker net' the files onto the server by copying the files onto a hard disk, plugging the disk into the WHS, and somehow copying the files from the non-storage pool disk into the storage pool?  If so, how?

    Any help would be greatly appreciated.

    • Edited by 3Dad Sunday, August 16, 2009 6:54 PM accuracy
    • Edited by Ken WarrenModerator Tuesday, August 18, 2009 6:18 PM linkage
    Sunday, August 16, 2009 5:07 PM

All replies

  • Regarding the 0x8007046A error according to this TechNet article the error can occur when "your file server is set to use too much nonpaged system memory". From the looks of it seems like the problem may be your WHS running out of physical memory midtransfer rather than a WHS landing zone issue.

    Your best bet might be as you suggested, just using the sneaker net approach to copy the file to WHS. To do this copy the file to a hard drive and connect that drive to WHS. Make sure you don’t add it to the drive pool or else WHS will automatically format it. Then you would remote in to WHS with Remote Desktop using the Administrator credentials for your WHS ( User: Administrator, Password: [your WHS Password] ). Then just copy over the file from the hard drive to the network share. Make sure that you use UNC paths (i.e.
    \\Server\Share) to copy the files to the share not directly to the D: drive where the SMB shares are physically stored otherwise bad stuff may happen since WHS was not designed to be used in that manner.

    You may also want to try the PP3 beta from Microsoft Connect to see if that helps but I doubt that it would since it was mainly
    focused on Win 7 integration. Also, you may want to consider filing a Connect bug regarding this issue if feel so inclined to do so in order to bring the issue to the attention of the WHS development team.

    Lastly, you might want to follow resolution steps listed in the TechNet article though I would hesitate to use them since it is unknown whether these steps would even be advisable for WHS as they assume a regular Server 2003 install. Also in order to perform those steps you would need to use that really complicated looking formula in order to readjust the SMB connection parameters correctly through the registry. Even using that formula correctly would require a deep understanding of both Server 2003 and WHS specific internals (i.e. number of distinct physical folders to be monitored, number of concurrent file IOs, etc) in order use it. Needless to say that would be no fun at all.

    Of course you could always try and see if going the cheap and easy route of installing more memory would help :)

    Hope this helps.

    • Edited by emed795 Sunday, August 16, 2009 7:27 PM
    Sunday, August 16, 2009 7:22 PM
  • Hi emed,

    Thanks for responding.  Sorry about the delay in my response- RL issues and stuff.

    Unfortunately, due to various restrictions, namely that the big files currently reside on a raid array, I can't just unplug the drive and sneakernet it into the WHS machine.  But I do have another drive on order.  Once it arrives I'll try out the sneakernet approach.

    I did file a bug on connect.  Bug ID 483235.  Just basically a copy/paste of my initial post here.

    Thanks for warning me about the potential issues with copying directly into the D:/DATA/shares/sharename folder.  It should be interesting to see whether copying onto a UNC shared folder instead, which I assume routes the copy through SMB code, works or results in the same error.

    But regardless, this is something of a blocking issue for me.  I'd like to be able to move really big files onto the WHS machine on a regular basis, so sneakernet isn't really a practical approach.  My latest idea is to try to use FTP to copy the files across.  I won't be able to kick that off until later this week, though.

    Any thoughts on this approach or any other workarounds or fixes by you or anyone else are always welcome.

    Again, thanks again for taking the time to take a look at the problem.
    Tuesday, August 18, 2009 5:25 PM
  • Sure no problem.

    Just a quick note regarding your connect bug report, the dev team will most likely request talq logs before they continue investigating your bug report so you should get around to it when you have a moment to spare. Since this bug seems to revolve around the server itself you will need to include talq for the server which can be done by downloading and installing the WHS toolkit add-in to WHS from the WHS toolkit.

    Also, another option you may want to try before FTP is the robocopy utility (Robust File Copy for Windows) . It is Microsoft command line tool that is included with Win 7 and Vista and can be downloaded for XP. As its name implies it is designed robustly copy files from one place to another either locally or over the network even in the presence of adverse network conditions (i.e. network errors or complete loss of connectivity). It is able to do this as it supports resuming where it left off copying (and it really does try, the default retry count is one million with 30 seconds between each retry). Just make sure to specify the /Z flag to copy in restartable mode (this flag is important - otherwise it will restart from the beginning each retry) and the /MIR flag if you are copying a folder to include subfolders (note: this option will destory any files in the destination folder that are not in the source folder use the /E flag if you just want to copy the subfolders).

    Hope this helps.

    • Edited by emed795 Wednesday, August 19, 2009 8:35 AM added warning about /MIR flag
    Wednesday, August 19, 2009 8:23 AM