WordPress › Support » File Upload Error After Upgrading to 3.3

[resolved] [closed] File Upload Error After Upgrading to 3.3 (42 posts)

RTK
Member
Posted 5 months ago #

Hello,

I am receiving the following error while trying to add a featured image after upgrading to 3.3:

"pic1.jpg" has failed to upload due to an error
The uploaded file could not be moved to C:\inetpub\wwwroot\blog/wp-content/uploads/2011/12.

I'm running Windows Server 2008 R2. Normally I understand that this message tends to be related to permission issues on the PHP temp folder or the wp-content/uploads folder. I have not changed permissions on either of these folders in a long time, and it has been working fine up until the upgrade.

Any thoughts or ideas I might be able to try? I'm baffled since no user permissions changed on the folders.

Thanks!
keesiemeijer
moderator
Posted 5 months ago #

Did you do a manual or automatic upgrade?
Check if the permissions are correct on your server: http://codex.wordpress.org/Changing_File_Permissions

http://codex.wordpress.org/Changing_File_Permissions#Using_an_FTP_Client
madvibes
Member
Posted 5 months ago #

i'm having the same issue. i did a manual update and since the update, i can no longer upload media. i didn't change any of the folder permissions!
Ipstenu
Half-Elf Support Rogue & Mod
Posted 5 months ago #

Is this the first time you've tried to upload a file in December?
madvibes
Member
Posted 5 months ago #

nope, there are plenty of files in 2011/12/
RTK
Member
Posted 5 months ago #

@keesiemeijer - I performed a manual update just like I normally do for all releases. I was updating from the latest 3.2.x version. I triple checked file permissions to verify that they were correct, and as I said before I haven't changed them since I setup the blog.

@Ipstenu - like madvibes, I also have plenty of files in my wp-content/uploads/2011/12 folder, and file uploading was working fine the day before I performed the upgrade to 3.3.

I fired up Procmon to take a look at what might be happening when I do a file upload and I'm seeing some references to a possible buffer overflow:

Procmon Screen Capture

That is what Procmon shows while I'm trying to upload a featured image. This is after I give full permissions to the Everyone user on both the PHP temp folder and the /wp-content/uploads folder.

I've double checked the php.ini file to ensure larger files are allowed to be uploaded, and I have upload_max_filesize = 2M. I've also checked the web.config that IIS is using and it has maxRequestLength configured to 4096 (4 MB). The file I'm uploading is somewhere in the 70 KB range, so I know that's not the issue.

I've also tried the standard file upload as opposed to the new fancy upload and I get the same result.

Any help is appreciated! I have to think it's a problem with the new code since nothing has changed on my end, but I guess that is yet to be determined.

Thanks!
madvibes
Member
Posted 5 months ago #

i had my network admin check that my user has all the permissions from the root level to write to folders. i should be able to do anything at this point, but still can't upload files.

@rkrause - have you been able to make anything work?
RTK
Member
Posted 5 months ago #

@madvibes - Nope, I still have not been able to get it working. I've tried disabling all of my plugins and still have the same error. The only thing I have not tried is applying the standard Twenty Eleven theme to see if it could be a theme incompatability. Beyond that, I don't know where to go from there.

Anyone else have any trouble with this? Or any other suggestions?

Thanks!
madvibes
Member
Posted 5 months ago #

i'm pretty sure it has to do with wordpress changing group and user permissions when it's installed.
RTK
Member
Posted 5 months ago #

How does WordPress change permissions when it is installed? Doing the manual installation, I just copy files from one directory to another...there is no installer or anything like that which would modify directory permissions. Also, since I checked the permissions on both of the upload folders in question, I'm not convinced that the web server and PHP processes do not have appropriate access to the resources they need.
derek.tonkin
Member
Posted 5 months ago #

I had the same problems and ended up rolling back to the version I was on before, 3.2.1. I'm not sure what the deal was because I had full privileges. I think it has something to do with the new uploader code in this release.
kokkoras@csd.auth.gr
Member
Posted 5 months ago #

I had the same problems and ended up rolling back to 3.2.1. It happened on a WP istallation running on Win2003 server (IIS with latest php) as well as on a dev installation running on Win7Pro (with the latest php, as well).

The win2003 server installation had also problems giving me a working upload button - I had to use the alternative provided although at the end it also failed to upload the file.

To make thinks worst, another WP installation running on win7/IIS/latest php works fine with 3.3.

All PCs have WP on IIS/php, all have the upload folder on the same settings, all worked fine with WP 3.2.1.

The only difference worth mentioned in these 3 WP installations is that for some uknown reason the working WP 3.3 is also capable on doing automatic updates. I am manually updating the other two.
Ipstenu
Half-Elf Support Rogue & Mod
Posted 5 months ago #

Well. You could always try manually updating the broken site.

Did anyone try changing the file permissions on the 12 folder, just for a lark?
kokkoras@csd.auth.gr
Member
Posted 5 months ago #

Guys, I think I have the solution (or at least a workaround).

I gave write and modify permissions to the Users user over the wp-content folder (I had done it on the uploads folder - as I usualy do). The prob was magicaly solved (I upgrated one win7 installation already).
RTK
Member
Posted 5 months ago #

Unfortunately, giving the Users group modify permissions on the entire wp-content folder is not an acceptable workaround unless you're willing to compromise the security of your blog. The worker process for your web server should not have modify permission on any directory except where absolutely necessary. If you grant this permission, you open yourself up to people potentially being able to alter your content, deface your blog or host malicious files if they find vulnerabilies in WordPress or any plugin you're using. Granting full permission to the Everyone group (as a test) on the /wp-content/uploads folder should be more than enough for WordPress to upload files to it. Since this test failed, and since I've never had any issues prior to upgrading to 3.3, I can only assume something was changed in the uploader code that is now having a negative impact on Windows/IIS based WordPress installations.

Still looking for a solution, but haven't found one yet.
kokkoras@csd.auth.gr
Member
Posted 5 months ago #

How is it possible for someone outside the users list of my win PC to get access to the folders below the contents folder as long as he doesn't have access to my PC? Am I missing something? (I am on IIS).

I agree that the folder under consideration should be (and was, on v.3.2.1 and older) the uploads folder but then the problem is on the WP 3.3 and not our settings. We all had the ability to upload until we moved to v.3.3. Any official WP position on this?
RTK
Member
Posted 5 months ago #

If you grant Modify access to the Users group on the entire /wp-content folder, you're granting read/write/delete access to any low-privileged authenticated user account on the system. Members of the Users group cannot, by default, write to the inetpub\wwwroot directory being hosted by a Windows IIS server. So for example, if I were running the MySQL service as a standard user and an attacker exploited a vulnerability in the software that allowed them to gain control of that process, they could potentially write to my blog content folders now that I've granted Modify permissions to the Users group. They could host malicious contnet, they could overwrite my theme files with their own, etc. Generally speaking you will only want to give Read access to processes that serve internet content anonymously, with exceptions being made for special folders like the wp-content/uploads folder when needed.

You're right though, the main point at hand is that we had the ability to upload prior to 3.3 and now for whatever reason, something has changed in the code or function calls that doesn't seem to allow us to do that anymore.
kokkoras@csd.auth.gr
Member
Posted 5 months ago #

Since the uploads folder does not exist on a fresh WP install, it seems logical for the system (WP) to ask for write permission on the wp-content folder. How else is it possible to create this folder? If memory serves, I did actually got such a message when I tried to upload a file on a fresh install. The system was not able to create the upload folder because of low priviledges over the wp-content folder.
RTK
Member
Posted 5 months ago #

I set this up a while ago, so I'm trying to recall...I think I manually created the uploads folder and granted permissions to it when I installed WordPress.

The weirdest part is exactly what you said though, if I grant the IUSR user explicit Modify permissions on the wp-content folder rather than just on the wp-content/uploads folder where it current has Modify permissions, this error goes away and I'm able to upload featured images again. Even though WordPress states that the wp-content folder is meant to be writeable by the public, I really don't trust giving the public internet user write permissions to my theme and plugin directories. Not sure why the new code for 3.3 seems to require that the parent wp-content directory is writable rather than just the wp-content/uploads directory. Any info from the WordPress gurus on this? Thanks!
kokkoras@csd.auth.gr
Member
Posted 5 months ago #

I used to play with the permissions of the IUSR in the past, because that was what I was doind in the old days, in simple ASP web apps.

In WP and other similar apps, PHP is the one that actually writes into these folders and only setting up the users account the way I described does the job. Giving write/modify to the IUSR doesn't solve the problem.

Now, back to the issue... I was as well creating the uploads folder namually and setting it up the way required - and that was all - no issues!
RTK
Member
Posted 5 months ago #

Hmm, yeah this definitely seems like some sort of weird permission issue with Windows-based setups that are running PHP via FastCGI I guess. For me, I ended up doing this get it working:

1) Granted IUSR Modify permission on the entire wp-content directory, allowing permissions to propagate down to its children
2) Broke inheritance and copied parent permissions to the wp-content/plugins folder, removing inherited IUSR permissions in the process
3) Broke inheritance and copied parent permissions to the wp-content/themes directory, removing inherited IUSR permissions in the process

So essentially what I'm left with is IUSR having write access to the wp-content root directory, the wp-content/uploads directory and subfolders, and that is all. The IUSR user cannot write to my plugins or themes directories, which is what I was aiming for.

Guess that works for now, but I'm still interested to know why the PHP user process seems to need write access to the entire wp-content directory when running WordPress 3.3. Maybe the code that was added for uploading in 3.3 makes use of different calls or checks and somwhere along the line fails if it can't write to that directory for some reason?
kokkoras@csd.auth.gr
Member
Posted 5 months ago #

I was too lazy (or run non critical sites) to think of these extra steps #2 and #3 you mentioned. That;s great!

So, you say that Users is not required to get involved because IUSR can handle the entire job, right?
RTK
Member
Posted 5 months ago #

Correct, that seems to be the case for me. Since IUSR is the one actually being used for access requests to the file system by PHP based on my server's configuration, as long as I grant the permissions I outlined above to my server's WordPress installation, everything seems to work like it did before 3.3.
cshaffstall
Member
Posted 5 months ago #

It's not just a Windows issue. I'm having the same issue with a Unix server and, having just spent the last week eradicating a malware virus from our server of 40 sites, I'm in no hurry to be granting any type of global write permissions for any reason.

The upload worked fine for two images and then stopped. That it is working in some cases and not others leads me to believe it is not a permissions issue, else how would I have been able to get the first two images imported?
kokkoras@csd.auth.gr
Member
Posted 5 months ago #

BTW, working with IUSR instead of the Users account doesn't work for me.
RTK
Member
Posted 5 months ago #

It just depends on how you have your server configured. By default IIS 7 has anonymous authentication enabled with the user account IUSR as the identity being used. If your server is configured differently, you may not be using IUSR as the default anonymous identity, in which case it would not matter if you granted rights to IUSR.

Since you're running IIS 6 (Windows Server 2003), your default anonymous authentication account, and thus the account that PHP scripts would be executing under, is IUSR_computername, where <computername> is the name of your machine. This IUSR_computername user is a member of the Users group, so that is probably why when you grant more privileges to the Users group you're able to upload. Try only adding extra permissions to the IUSR_computername user and see if that works for you.
rsgrone
Member
Posted 5 months ago #

Regarding the Windows Server issues (to which I rolled back my installation as it is not working either) it depends on whether you are using the Windows "Web Server" or the full blown release of the server. That is, a regular Windows server works with additional account privileges based on Active directory rights and the Web Server addition does not.

Hope that makes sense, I am very ill at the moment and not thinking clearly but, granting privileges as you stated above, "modify" instead of write leaves your files wide open to malicious attack...

I am guessing it has something to do with the code since; I have never had this issue through the 3.x.x process...

I opened a new thread hoping for an answer... I have a dedicated serve so; I am not fighting with the hosting company regarding rights, privileges, etc...
cshaffstall
Member
Posted 5 months ago #

I am using GoDaddy as my host on a Unix server. All of my issues were resolved by disabling four PHP extensions.

Launch your hosting account, go to Settings > File Extensions Management and there are four PHP extensions (that were at the bottom of my list). I had to edit each one and change them from running under fastPHP 4.x or 5.X to running under just PHP 4.X or 5.X.

Hope this is helpful to someone else.

I was warned that some WordPress plug-ins require these extensions, but until I come across one that does, I'm simply happy that all 40 of my client blogs are up and running.
rsgrone
Member
Posted 5 months ago #

Any idea what the four extensions were?

I am not on godaddy but would like a look see into the issue...

Is the "Drag and Drop" feature appearing now as well? I have attempted to use the default WP theme, and had to make some rather unusual permissions changes however, that did not fix the drag and drop issue (which is not working regardless of the upload issue)...

Thanks
rsgrone
Member
Posted 5 months ago #

@RTK - are you able to write to the Plugins folder now? That is, have you attempted to place or replace/update plugins to that folder yet? I was given a denied error even login as administrator...

Had to give the folder write privileges to all again to correct the error...