The uploaded file could not be moved to E:\sitesroot\0/...

Mar 22, 2012 at 10:10 PM
Edited Mar 22, 2012 at 10:10 PM

I've seen discussions around this but I haven't seen any solution that has worked for me.  I also have the Windows Azure Storage for WordPress  plugin configured properly with my account name, key, and default container.

Here is the error I get when trying to install a plugin, or upload an image for a new post:

The uploaded file could not be moved to E:\sitesroot\0/wp-content/uploads/2012/03.

I also tried adding this to my wp-config.php

/** Set UPLOADS path **/

define('BLOGUPLOADDIR', azure_getlocalresourcepath('the_name_of_my_storage_account'));  //not the container, is that correct?




Any ideas?

Mar 31, 2012 at 6:06 AM

Did you ever figure this out? I'm having the same problem right now.

Mar 31, 2012 at 2:34 PM

No, not yet.  I was hoping someone would have solved this by now.  I'm not sure it can even be done at this point.  I will have some more time to work on it next week and will be sure to post a solution if I come across one.

Mar 31, 2012 at 4:11 PM

Are you running this in the emulator when you get the error or in Windows Azure?

Mar 31, 2012 at 4:55 PM

For me it was in azure itself. I get that error whenever I try to do anything that writes.  Media upload, import from another blog (plug-in installed in package), etc.

Mar 31, 2012 at 7:10 PM

I am guessing that setting the WP_TEMP_DIR to the storage container will fail because WordPress uses normal file system calls to get the files up. So let the files upload to the regular temp space and then the storage plugin will take over and move the file to Windows Azure storage.

If after putting back the normal upload you are still having issues you may want to enable remote desktop and check on the file system permissions. The startup scripts are supposed to take care of setting the permissions for you, but it is possible that it is failing for some reason.

There is a pretty good article on setting up remote desktop at

Mar 31, 2012 at 10:26 PM

I'll take a look soon. What permissions should I be looking for?

Mar 31, 2012 at 11:01 PM

Welp. There is no E drive on mine. There is a F drive with the correct path.

So, how do I change the WordPress install to set that path to the F drive instead of the E drive?

Apr 1, 2012 at 4:27 AM

@blobaugh I'm running it in Windows Azure.

Apr 1, 2012 at 4:30 AM

It also doesn't work when I leave out the WP_TEMP_DIR setting as well.  I get the same error.

Apr 1, 2012 at 5:55 PM

@robert_g setup RDP and check your permissions, or you could alter the startup script to set the correct permissions for you


@KenStone Using drive F should not be a problem. All the scripts that do the setup should be using the local environment variables to map to the correct drive. This line

CALL icacls ..\wp-content /grant "NETWORK SERVICE":F /T

Should be in your bin/install-azure-impl.cmd file. It may be wiser to change it to use the %RoleRoot% variable to give everything there permissions. If you cannot see any other issue when you RDP in maybe try setting everything to have permissions. If that works then you know that you should update that line in the startup script

Apr 4, 2012 at 8:16 PM

@blobaugh solution worked: I added this line to the bin/install-azure-impl.cmd file:

CALL icacls %RoleRoot% /grant "NETWORK SERVICE":F /T

This resolved the issue and I was able to write to blob storage after deployment. Now I can't add new posts, but that's another problem...

Apr 20, 2012 at 9:04 AM
Edited Apr 20, 2012 at 9:05 AM

I solved this issue doing just this 2 modifications : 


1. MyWordpressFolder/ServiceDefinition.csef : 
   I added this node for the webrole :
        <LocalStorage name="<choose a name for your storage>" cleanOnRoleRecycle="false" sizeInMB="500" />


2. MyWordpressFolder/wp-config.php : 

In case deployement (after the "else"), I added 2 lines

/* *******************************

/** Set UPLOADS path **/ 
define('BLOGUPLOADDIR', azure_getlocalresourcepath('<the name you have chosen previously for your storage')); 

Ater that, it works.... But now I have the same problem as @tonyw54 !

I guess this modification should be made before the WP DB is generated.