Download failed. Could not create Temporary file
Last week I posted that I was having problems upgrading or updating WordPress core and plugins. Every attempt resulted in the message – “Download failed. Could not create Temporary file”. The only solution at the time was to change permissions on wp-content to 0777 and then to revert to 0755 after.
I have finally found a definitive answer that does not require changing permissions or ownerships. or does it compromise the security of the server.
The solution is quite simple. All that is required is to add the following two lines to the wp-config.php file.
define('WP_TEMP_DIR', ini_get('upload_tmp_dir'));
putenv('TMPDIR=' . ini_get('upload_tmp_dir'));
As I said, I run several sites, so it was a matter of updating each config file. I then attempted a core upgrade and a plugin upgrade on each. Success! No more meddling with directory permissions.
So, if anyone out there is having the same problem – there is the answer.
Now that’s peculiar. My “wp-content” directory’s permission has always been 755 and I’ve had no problem with auto-updating the WP core. No idea what the difference might be though.
You’re not using Bad Behavior are you?
I ditched Bad Behaviour a long time ago in favour of Akismet and WS-Spam Free.
I found a lot of people suffering from the same problem and most were suggesting the change/change back of permissions which is not what I wanted. I am 99% positive it’s a problem with ownership rather than permissions.
Hi Richard, thanks so much for posting this. It’s been bugging me for a long while too. Does that have to go in a specific place in the file or just anywhere?
Can you explain exactly what it does? How does that manage to override the permissions?
Hi Dónal, and welcome.
I inserted the lines at the bottom of the file (just before the final ?> )
The problem is one of ownership rather than permissions. Those lines set up a temporary location that is owned by the user, rather than the server. The user (the blog itself) is therefore able to write to it.
Hey there Richard,
I’ve tried without success to get this working. I’ve tried inserting the lines in various places in the file to no avail. When I upload the new file my site does not work at all.
?> does not appear anywhere in my wp-config.php file.
By any chance could you either post here or email to me an example of a wp-config.php file that works containing your two additional lines.
Thanks a lot,
Dónal
OK. I think I may have been at fault here, and you too. My fault for not enclosing the code above properly in the post, and your fault for being lazy and doing a cut and paste! 😉
I have changed the code above (the single quotes were corrupted) so if you cut and paste it into your Config file, it should work now.
Let me know how you get on.
Great stuff! We are all guilty of the ‘cut and paste’ syndrome.
I just hope it helps anyone else with the same problem.
Thanks a lot Richard, it’s working now!
Never even thought of typing it manually, I really am that lazy!
Hi Tom,
It can be edited in at any time. Just add those lines within wp-config.php and away you go.
I installed it on several existing sites with no problem at all.
I am still having trouble with this. Do I need to make this edit before installing WP for the first time, or can it be done on an existing installation?
Ouch! I’m afraid I can’t help you on that one. I checked, and there is no ‘file.php’ in my installations in wp-includes.
I think you may have a different problem here, unrelated to the config file.
Now I get the following error. Have you ever seen this?
Warning: touch() [function.touch]: Unable to create file C:PHP5uploadtemp/emerald-stretch.tmp because No such file or directory in D:Inetpubmissiontravelassocwordpresswp-adminincludesfile.php on line 184
Only came across this once and that was this morning.
This has saved my life. Well not mine, the poor lady who was going to go through hell upgrading her site.
I am totally baffled as to why it happens at all. Like I say, I’d never encountered it before.
Thank you very many and all.
Welcome, Jim! I’m delighted that it worked. It irritated me for a long time, so having found the solution, I hoped I could help others.
It really ought to be included in the WordPress core releases.
Hi Richard.
Sorry to bring this up again but this still doesn’t seem to be working for me. When I said it was working, I think I meant that the site was loading with the 2 new lines added to the wp-config. It hadn’t been before because they weren’t formatted right in your original post.
However, being the eejit that I am, I never actually tried to upload something to test the code. Until now that is. Have you any other ideas as to how I can fix it?
I’m on Linux hosting with Blacknight if that helps?
Also, have you any idea why this problem only affects some installations? I’m running a WordPress site hosted with LetsHost, and have no problems even though permissions are set to 755.
Dónal – Just a thought out of the blue plus the fact that I’d had the same thing happen to me. It turned out to be a problem with a plugin (can’t recall which one at the moment) causing the problem so if you’re running a few plugins, deactivate them (except Akismet if you wish) and check again. If everything works okay then it’s just matter of isolating the offending plugin. I know it sounds like a redundancy check but it’s worth trying.
Oh, and strange as it might seem, there’s not supposed to be a “?>” tag at the end of the “wp-config.php” file according to the WP developers. It’s purposely left out in order to keep users leaving any white spaces below it as any white space below the “?>” tag can end up causing problems:
“PHP does not require a closing tag (?>) at the end of a script. Actually it’s safer this way, as you are less likely to break your site. You see, blank lines after the closing tag cause PHP to send the headers. It has to send them before the first byte of the response can be sent. Later, WordPress tries to send headers and PHP throws a warning. So the omitted “?>” is not a bug”
Just FYI.
I don’t know what’s changed, but it seems to be working now (I didn’t remove any plugins or edit wp-config.php).
Only little niggle is that I still can’t upload zipped plugins from my computer via the WordPress interface (not a problem as I have full FTP access).
Thanks for your help Kirk!
@Kirk. Thanks for that. Glad to see you’re keeping an eye on this to make sure I don’t lead people astray. 😉
@Dónal. I’m with Blacknight myself (and wouldn’t be with anyone else).
One thing I have learned from my experience with computers is that they can be frustratingly illogical at times. It is a mystery why sometimes things don’t work, and other times they do. Probably something to do with caching somewhere? Anyway, I’m glad it’s working now.
It worked! Have multiple blogs though and updating all the wp-configs will be very time consuming, does anybody know what’s causing this at server level?
As far as I am aware, it is an ownership issue, rather than plain permissions.
Have you considered using the Multi-User feature of WordPress 3?
YOU! You are a Great find!!!!! I have been trying to fix this issue for the last 48 hours and have tried EVERYTHING (ok so only, the first few pages worth of possibilities) that was suggested in the WordPress Codex Forum to fix this issue. I have called Godaddy three times looking for some kind of help. I’ve been all though youtube, yahoo answers…and I thought google…but here you are. Thank YOU so much for posting this fix! Now if I could just figure out why it won’t let me upload an image, I could be well on my way to a fairly headache free day.
Hi Elisabeth and welcome! The reason I posted this was because the solution seemed to be so hard to find, despite it apparently being a very common problem. I’m just glad it can help others out.
While this upload problem seems to be down to ownership, the image problem could be down to permissions. I have had this problem in the past as I use the “‘Organize my uploads into month- and year-based folders” option selected. My solution is a bit basic but it works. I created a folder called “newyear” on my hard drive. Within that I created twelve empty folders “01”, “02” etc up to “12”. In December I then FTP into the site, create a new folder in Uploads corresponding to the new year (i.e. /2011) and then just FTP into it the contents of my newyear folder. Bingo – twelve folders all set to receive the next years images.
i installed the 2 lines of code but it doesnt seem to be working. i’m still getting the original “Download failed. Could not create Temporary file.” message.
do i need to create a upload_tmp_dir folder for this trick to work??? please advise. thanks in advance.
@Jay. Apologies for the slow response… No. You don’t need to create anything. The two lines of code should work. As far as I am aware, this will only work on a Linux server, so maybe yours is Windows based?
a simple solution that worked for me… just crate a folder and call it "tmp". create this folder in the wordpress root directory. that solved it for me 🙂
OMG ! U r a geek !!! Thanks a lot !
Heh! First time I’ve been called a geek!
I’ve been struggling with this error for months, thank you for posting it!